Basic Configuration:
R1:
int fa0/0
ipv6 address 2001:1111::1/64
no shutdown
!
int s1/0
ipv6 address 2013:13:13::1/64
no shutdown
!
int s1/1
ipv6 address 2012:12:12::1/64
no shutdown
R2:
int fa0/0
ipv6 address 2001:2222::2/64
no shutdown
!
int s1/1
ipv6 address 2012:12:12::2/64
no shutdown
!
int s1/0
ipv6 address 2023:23:23::2/64
no shutdown
R3:
int fa0/0
ipv6 address 2001:3333::3/64
no shutdown
!
int s1/0
ipv6 address 2013:13:13::3/64
no shutdown
!
int s1/1
ipv6 address 2023:23:23::3/64
no shutdown
!
int s1/2
ipv6 address 2034:34:34::3/64
no shutdown
R4:
int fa0/0
ipv6 address 2001:4444::4/64
no shutdown
!
int s1/1
ipv6 address 2034:34:34::4/64
no shutdown
Configure MP-BGP on R1. This router will reside in AS 1 and will peer with R2 and R3. Use the global Unicast IPv6 addresses for peering.
R1:
router bgp 1
bgp router-id 1.1.1.1
address-family ipv6 unicast
neighbor 2012:12:12::2 remote-as 234
neighbor 2013:13:13::3 remote-as 234
Configure MP-BGP on R2, R3, and R4 in AS 234. R2 and R3 will peer with R1. R2 will peer with R1 and R3. R3 will peer with R1, R2, and R4. R4 will peer only with R3. Use the global Unicast IPv6 addresses for peering. Verify your configuration.
R2:
router bgp 234
bgp router-id 2.2.2.2
address-family ipv6 unicast
neighbor 2012:12:12::1 remote-as 1
neighbor 2023:23:23::3 remote-as 234
R3 :
router bgp 234
bgp router-id 3.3.3.3
address-family ipv6 unicast
neighbor 2013:13:13::1 remote-as 1
neighbor 2023:23:23::2 remote-as 234
neighbor 2034:34:34::4 remote-as 234
R4 :
router bgp 234
bgp router-id 4.4.4.4
address-family ipv6 unicast
neighbor 2034:34:34::3 remote-as 234
Verify the configuration using the show bgp ipv6 unicast summary command on all MP-BGP routers.
R1#show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2012:12:12::2 4 234 2 2 1 0 0 00:00:45 0
2013:13:13::3 4 234 2 2 1 0 0 00:00:25 0
R1#
R2#show bgp ipv6 unicast summary
BGP router identifier 2.2.2.2, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2012:12:12::1 4 1 4 5 1 0 0 00:02:03 0
2023:23:23::3 4 234 4 4 1 0 0 00:01:44 0
R2#
R3#show bgp ipv6 unicast summary
BGP router identifier 3.3.3.3, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2013:13:13::1 4 1 6 6 1 0 0 00:03:05 0
2023:23:23::2 4 234 6 6 1 0 0 00:03:05 0
2034:34:34::4 4 234 5 6 1 0 0 00:02:52 0
R3#
R4#show bgp ipv6 unicast summary
BGP router identifier 4.4.4.4, local AS number 234
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2034:34:34::3 4 234 7 7 1 0 0 00:04:03 0
R4#
Now the purpose is to advertise the prefix 2001:1111::/64 connected to R1 using MP-BGP. And assign the community value 1:100.
Advertise the 2001:1111::/64 prefix connected to R1 using MP-BGP. This prefix should have an ORIGIN code of IGP and should be assigned the community 1:100.
By default, all prefixes injected into MP-BGP using the network statement will be assigned an ORIGIN code of IGP. To complete the second requirement of this task, we need to use a route-map to assign this prefix the specified COMMUNITY attribute. In addition to this, we need to configure MP-BGP so that this attribute is included in updates to peers:
The ip bgp-community new-format command changes the community format to be AA:NN as specified.
R1:
route-map COMMUNITY permit 10
set community 1:100
!
ip bgp-community new-format
!
router bgp 1
address-family ipv6 unicast
network 2001:1111::/64 route-map COMMUNITY
neighbor 2012:12:12::2 send-community standard
neighbor 2013:13:13::3 send-community standard
The community value is 1:100:
R1#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
Local
:: from 0.0.0.0 (1.1.1.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Community: 1:100
rx pathid: 0, tx pathid: 0x0
R1#
Notice below that if we remove the ip bgp-community new-format command the default community value will be 65636:
R1(config)#no ip bgp-community new-format
R1#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
Local
:: from 0.0.0.0 (1.1.1.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Community: 65636
rx pathid: 0, tx pathid: 0x0
R1#
The same value of community is displayed on R2 and R3 in the updates sent by R1. Notice also that the community attribute is not sent to all internal MP-BGP peers this attribute is not included in updates from R2 to R3, and in updates from R3 to R2 and R4 as shown by the show bgp ipv6 unicast 2001:1111::/64 on R2 R3 an R4:
R2#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 3
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
Refresh Epoch 1
1
2013:13:13::1 (inaccessible) from 2023:23:23::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1
2012:12:12::1 (FE80::C800:1BFF:FE7C:8) from 2012:12:12::1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 65636
rx pathid: 0, tx pathid: 0x0
R2#
R3#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 3
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1
Refresh Epoch 1
1
2012:12:12::1 (inaccessible) from 2023:23:23::2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
1
2013:13:13::1 (FE80::C800:1BFF:FE7C:8) from 2013:13:13::1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 65636
rx pathid: 0, tx pathid: 0x0
R3#
R4 does not receive the community value because R3 does not include by default this attribute in their updates:
R4#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
1
2013:13:13::1 (inaccessible) from 2034:34:34::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
R4#
To complete this task, we also therefore need to issue this command on R2, R3, and R4. Also, we need to ensure that the COMMUNITY attribute is sent to all internal MP-BGP peers. In other words, this attribute should be included in updates from R2 to R3, and in updates from R3 to R2 and R4. Since R4 is not receiving and advertising any prefixes with this attribute, it does not need to include it in updates sent to R3. This part of the task is completed as follows:
R2(config)#router bgp 234
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#neighbor 2023:23:23::3 send-community standard
R2(config-router-af)#exit
R2(config-router)#exit
R2(config)#ip bgp-community new-format
R3(config)#router bgp 234
R3(config-router)#address-family ipv6 unicast
R3(config-router-af)#neighbor 2023:23:23::2 send-community standard
R3(config-router-af)#neighbor 2034:34:34::4 send-community standard
R3(config-router-af)#exit
R3(config-router)#exit
R3(config)#ip bgp-community new-format
R4(config)#ip bgp-community new-format
The Community Attribute is now displayed in the BGP RIB on all routers:
R2#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 3
Paths: (2 available, best #2, table default)
Advertised to update-groups:
3
Refresh Epoch 1
1
2013:13:13::1 (inaccessible) from 2023:23:23::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 1:100
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1
2012:12:12::1 (FE80::C800:1BFF:FE7C:8) from 2012:12:12::1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 1:100
rx pathid: 0, tx pathid: 0x0
R2#
R3#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 3
Paths: (2 available, best #2, table default)
Advertised to update-groups:
3
Refresh Epoch 1
1
2012:12:12::1 (inaccessible) from 2023:23:23::2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 1:100
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
1
2013:13:13::1 (FE80::C800:1BFF:FE7C:8) from 2013:13:13::1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 1:100
rx pathid: 0, tx pathid: 0x0
R3#
R4#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 0
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
Refresh Epoch 1
1
2013:13:13::1 (inaccessible) from 2034:34:34::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 1:100
rx pathid: 0, tx pathid: 0
R4#
Advertise the 2001:2222::/64 prefix as well as the 2000:4444::/64 prefix connected to the LAN interfaces of R2 and R4, respectively, via MP-BGP. Ensure that R2 and R4 can ping each other LAN to LAN following this configuration. You are NOT allowed to configure R3 as a route-reflector, or use confederations. Instead, use BGP default routing. However, ensure that a default route is NEVER advertised to AS 234. Do NOT use any type of filters to complete this task.
First, we need to advertise the LAN subnets that are connected to R2 and R4 via MP-BGP:
R2:
router bgp 234
address-family ipv6 unicast
network 2001:2222::/64
R4:
router bgp 234
address-family ipv6 unicast
network 2001:4444::/64
Verify your configuration using the show bgp ipv6 unicast command on R2 and R4:
R2#show bgp ipv6 unicast 2001:2222::/64
BGP routing table entry for 2001:2222::/64, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 1
Local
:: from 0.0.0.0 (2.2.2.2)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
rx pathid: 0, tx pathid: 0x0
R4#show bgp ipv6 unicast 2001:4444::/64
BGP routing table entry for 2001:4444::/64, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
Local
:: from 0.0.0.0 (4.4.4.4)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
rx pathid: 0, tx pathid: 0x0
To avoid the IBGP Rule which states that when an IBGP router receives a BGP update from an IBGP peer ,it does not sent this update to another IBGP peer,we can use a route reflector on R3 allowing these prefixes 2001:2222::/64 and 2001:4444::/64 to be advertised to its peers R4 and R2 respectively.
However the task states that this is forbidden. To complete this task, we need to use BGP default routing as stated. However, to ensure that the default route is not advertised to AS 234, we need to use the COMMUNITY attribute (LOCAL_AS or NO_EXPORT).
R3:
route-map LOCAL-AS permit 10
set community local-AS
!
router bgp 234
address-family ipv6 unicast
neighbor 2023:23:23::2 default-originate route-map LOCAL-AS
neighbor 2034:34:34::4 default-originate
Now R2 and R4 receive a default route, only R2 is receiving this default route with the community: local-AS therefore it is not advertised outside AS 234:
R2#show bgp ipv6 unicast ::/0
BGP routing table entry for ::/0, version 4
Paths: (1 available, best #1, table default, not advertised outside local AS)
Not advertised to any peer
Refresh Epoch 1
Local
2023:23:23::3 from 2023:23:23::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: local-AS
rx pathid: 0, tx pathid: 0x0
R4#show bgp ipv6 unicast ::/0
BGP routing table entry for ::/0, version 3
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
2034:34:34::3 from 2034:34:34::3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Finally R2 and R4 can ping the LAN of each router:
R2#ping 2001:4444::4 source fastethernet 0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4444::4, timeout is 2 seconds:
Packet sent with a source address of 2001:2222::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/44/80 ms
R2#
R4#ping 2001:2222::2 source fastethernet 0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:2222::2, timeout is 2 seconds:
Packet sent with a source address of 2001:4444::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/112 ms
R4#
Now the purpose is that R2 prefers the path via R3 to reach all prefixes originated from BGP AS 1 only. The direct path to AS 1 via R2 should only be used as a backup if the link R2-R3 is down.
AS 1 should also prefer the R1-R3 for all traffic destined to AS 234.
We can use the Local Preference attributes on R3 so that it sends updates for prefixes originated in AS 1 with a higher value than the default Local Preference value 100. Now if there are a lot of prefixes from AS 1,it is fastidious, so it is better to use AS_PATH filter on R3.
Let's explore the AS_PATH filter:
R3:
ip as-path access-list 1 permit ^1$
!
route-map PREF permit 10
match as-path 1
set local-preference 200
!
route-map PREF permit 20
!
router bgp 234
address-family ipv6
neighbor 2023:23:23::2 route-map PREF out
Now R2 prefers to reach the LAN subnet of R1 through the Internal route through R3 (through AS 234) as shown by the the MP-BGP RIB of R2 because R3 is advertising a higher (better) Local Preference 200 than the Local Preference of R1 100:
R2#show bgp ipv6 unicast 2001:1111::/64
BGP routing table entry for 2001:1111::/64, version 9
Paths: (2 available, best #1, table default)
Flag: 0x800
Not advertised to any peer
Refresh Epoch 1
1
2013:13:13::1 from 2023:23:23::3 (3.3.3.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
Community: 1:100
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
1
2012:12:12::1 (FE80::C800:22FF:FE0C:8) from 2012:12:12::1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external
Community: 1:100
rx pathid: 0, tx pathid: 0
To ensure that R1 prefers the path via R3 for all prefixes originated from AS 234, we will use the WEIGHT Attribute as follow:
R1:
ip as-path access-list 1 permit ^234$
route-map WEIGHT permit 10
match as-path 1
set weight 1
!
route-map WEIGHT permit 20
!
router bgp 1
address-family ipv6
neighbor 2013:13:13::3 route-map WEIGHT in
R1 prefers the path through R3 to reach the LAN subnet of R2 as shown by the MP-BGP RIB of R1 because the better weight value:
R1#show bgp ipv6 unicast 2001:2222::/64
BGP routing table entry for 2001:2222::/64, version 2
Paths: (2 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
234
2013:13:13::3 (FE80::C803:21FF:FE68:8) from 2013:13:13::3 (3.3.3.3)
Origin IGP, localpref 100, weight 1, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
234
2012:12:12::2 (FE80::C801:22FF:FE0C:8) from 2012:12:12::2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Verification of the LAN-to-LAN connectivity:
R1#ping 2001:2222::2 source fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:2222::2, timeout is 2 seconds:
Packet sent with a source address of 2001:1111::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/66/132 ms
R1#
R1#ping 2001:4444::4 source fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4444::4, timeout is 2 seconds:
Packet sent with a source address of 2001:1111::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/59/104 ms
R1#
R2#ping 2001:1111::1 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1111::1, timeout is 2 seconds:
Packet sent with a source address of 2001:2222::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/60 ms
R2#
R2#ping 2001:3333::3 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3333::3, timeout is 2 seconds:
Packet sent with a source address of 2001:2222::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/60/100 ms
R2#
R2#ping 2001:4444::4 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4444::4, timeout is 2 seconds:
Packet sent with a source address of 2001:2222::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/64/120 ms
R2#
R4#ping 2001:1111::1 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1111::1, timeout is 2 seconds:
Packet sent with a source address of 2001:4444::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/42/56 ms
R4#
R4#ping 2001:2222::2 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:2222::2, timeout is 2 seconds:
Packet sent with a source address of 2001:4444::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/104 ms
R4#
R4#ping 2001:3333::3 sou fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3333::3, timeout is 2 seconds:
Packet sent with a source address of 2001:4444::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/44/104 ms
R4#
