BGP needs the full mesh of iBGP peers inside an AS because BGP does not advertise iBGP routes (routes learned from one iBGP peer) to another iBGP peer. This additional restriction helps prevent routing loops, but it then requires a full mesh of iBGP peers.
BGP offers two tools (confederations and route reflectors) that reduce the number of peer connections inside an AS, prevent loops, and allow all routers to learn about all prefixes.
An AS using BGP confederations, as defined in RFC 3065, separates each router in the AS into one of several confederation sub-autonomous systems. Peers inside the same sub-AS are considered to be confederation iBGP peers, and routers in different sub-autonomous systems are considered to be confederation eBGP peers.
Confederation eBGP peer connections act like true eBGP peers in some respects.
In a single sub-AS, the confederation iBGP peers must be fully meshed, because they act exactly like normal iBGP peers—in other words, they do not advertise iBGP routes to each other.
However, confederation eBGP peers act like eBGP peers in that they can advertise iBGP routes learned inside their confederation sub-AS into another confederation sub-AS.
Confederations prevent loops inside a confederation AS by using the AS_PATH PA. BGP routers in a confederation add the sub-autonomous systems into the AS_PATH as part of an AS_PATH segment called the AS_CONFED _SEQ.
AS_CONFED_SEQ and AS_CONFED_SET help prevent loops within confederation autonomous systems.
Before confederation eBGP peers can advertise an iBGP route into another sub-AS, the router must make sure the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment.
Note: The choice of values for sub-ASNs is not coincidental in this case. ASNs 64512 through 65535 are private ASNs, meant for use in cases where the ASN will not be advertised to the Internet or other autonomous systems.
The following list summarizes the key topics regarding confederations:
- Inside a sub-AS, full mesh is required, because full iBGP rules are in effect.
- The confederation eBGP connections act like normal eBGP connections in that iBGP routes are advertised—as long as the AS_PATH implies that such an advertisement would not cause a loop.
- Confederation eBGP connections also act like normal eBGP connections regarding Time to Live (TTL), because all packets use a TTL of 1 by default. (TTL can be changed with the neighbor ebgp-multihop command.)
- Confederation eBGP connections act like iBGP connections in every other regard — for example, the NEXT_HOP is not changed by default.
- Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best routes based on the shortest AS_PATH.
- Confederation routers remove the confederation ASNs from the AS_PATH in Updates sent outside the confederation; therefore, other routers do not know that a confederation was used.
Configuring Confederations
BGP Subcommands Used for Confederations:
router bgp sub-as - Define a router’s sub-AS
bgp confederation identifier asn - Define the true AS
bgp confederation peers sub-asn - To identify a neighboring AS as another sub-AS
For this lab, we should first shutdown routers R4 and R5. R1 and R3 will be part of a BGP confederation (BGP sub-AS 65013) and R2 will be the other BGP confederation router (BGP sub-AS 65002).
Also, we will shutdown the R1-R2, R1-R102 and R2-R101 links, so that we'll have two non-redundant exit points from the enterprise, each to a different ISP.
This way, we will not have full link redundancy inside the Enterprise (which is actually our goal when using BGP Confederations): the only active links are R1-R3 and R3-R2.
R1(config)#interface serial 0/1
R1(config-if)#shutdown
R1(config)#interface fastEthernet 0/0
R1(config-if)#shutdown
R2(config)#interface serial 0/1
R2(config-if)#shutdown
R2(config)#interface fastEthernet 0/0
R2(config-if)#shutdown
The initial router configs:
R1:
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 101.101.101.101 remote-as 101
neighbor 101.101.101.101 password ccnp
neighbor 101.101.101.101 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback1
no auto-summary
!
ip forward-protocol nd
ip route 3.3.3.3 255.255.255.255 10.1.0.13
ip route 101.101.101.101 255.255.255.255 201.1.1.2
!
R2:
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 102.102.102.102 remote-as 102
neighbor 102.102.102.102 ebgp-multihop 2
neighbor 102.102.102.102 update-source Loopback2
no auto-summary
!
ip forward-protocol nd
ip route 3.3.3.3 255.255.255.255 10.1.0.21
ip route 102.102.102.102 255.255.255.255 202.2.2.6
!
R3:
!
interface Loopback3
ip address 3.3.3.3 255.255.255.255
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 10.1.0.14
ip route 2.2.2.2 255.255.255.255 10.1.0.22
!
R101:
!
interface Loopback101
ip address 101.101.101.101 255.255.255.255
!
router bgp 101
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 password ccnp
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback101
neighbor 104.104.104.104 remote-as 104
neighbor 104.104.104.104 password ccnp
neighbor 104.104.104.104 ebgp-multihop 2
neighbor 104.104.104.104 update-source Loopback101
no auto-summary
!
ip forward-protocol nd
ip route 1.1.1.1 255.255.255.255 201.1.1.1
ip route 104.104.104.104 255.255.255.255 114.1.1.2
!
R102:
!
interface Loopback102
ip address 102.102.102.102 255.255.255.255
!
router bgp 102
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback102
neighbor 103.103.103.103 remote-as 103
neighbor 103.103.103.103 ebgp-multihop 2
neighbor 103.103.103.103 update-source Loopback102
no auto-summary
!
ip forward-protocol nd
ip route 2.2.2.2 255.255.255.255 202.2.2.5
ip route 103.103.103.103 255.255.255.255 123.1.1.2
!
R103:
!
interface Loopback103
ip address 103.103.103.103 255.255.255.255
!
router bgp 103
no synchronization
bgp log-neighbor-changes
neighbor 102.102.102.102 remote-as 102
neighbor 102.102.102.102 ebgp-multihop 2
neighbor 102.102.102.102 update-source Loopback103
neighbor 104.104.104.104 remote-as 104
neighbor 104.104.104.104 ebgp-multihop 2
neighbor 104.104.104.104 update-source Loopback103
no auto-summary
!
ip route 102.102.102.102 255.255.255.255 123.1.1.1
ip route 104.104.104.104 255.255.255.255 134.1.1.2
!
R104:
!
interface Loopback40
ip address 192.168.40.40 255.255.255.255
!
interface Loopback41
ip address 192.168.41.41 255.255.255.255
!
interface Loopback42
ip address 192.168.42.42 255.255.255.255
!
interface Loopback43
ip address 192.168.43.43 255.255.255.255
!
interface Loopback44
ip address 192.168.44.44 255.255.255.255
!
interface Loopback104
ip address 104.104.104.104 255.255.255.255
!
router bgp 104
no synchronization
bgp log-neighbor-changes
network 192.168.40.40 mask 255.255.255.255
network 192.168.41.41 mask 255.255.255.255
network 192.168.42.42 mask 255.255.255.255
network 192.168.43.43 mask 255.255.255.255
network 192.168.44.44 mask 255.255.255.255
neighbor 101.101.101.101 remote-as 101
neighbor 101.101.101.101 password ccnp
neighbor 101.101.101.101 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback104
neighbor 103.103.103.103 remote-as 103
neighbor 103.103.103.103 ebgp-multihop 2
neighbor 103.103.103.103 update-source Loopback104
no auto-summary
!
ip route 101.101.101.101 255.255.255.255 114.1.1.1
ip route 103.103.103.103 255.255.255.255 134.1.1.1
!
The results of the above configurations:
R1#show ip bgp summary | b Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 6 5 6 0 0 00:02:00 5
R2#show ip bgp summary | b Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
102.102.102.102 4 102 6 5 6 0 0 00:02:30 5
R1#show ip bgp
BGP table version is 6, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.40.40/32 101.101.101.101 0 101 104 i
*> 192.168.41.41/32 101.101.101.101 0 101 104 i
*> 192.168.42.42/32 101.101.101.101 0 101 104 i
*> 192.168.43.43/32 101.101.101.101 0 101 104 i
*> 192.168.44.44/32 101.101.101.101 0 101 104 i
R2#show ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 192.168.44.44/32 102.102.102.102 0 102 103 104 i
The following list outlines the sequence of events to propagate a prefix:
1. R1 will learn prefix 192.168.40.40/32 via eBGP from AS 101 (R101).
2. R1 will advertise the prefix via iBGP to R3.
3. R3 will advertise the prefix via confederation eBGP to R1.
First, we have to delete the former BGP process configured on R1 and R2.
R1(config)#no router bgp 100
R1#sh run | s bgp
R1#
R2(config)#no router bgp 100
R2#sh run | s bgp
R2#
BGP Confederation configurations:
R2(config)#router bgp 65002
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#bgp confederation identifier 100
R2(config-router)#bgp confederation peers 65013
R2(config-router)#neighbor 102.102.102.102 remote-as 102
R2(config-router)#neighbor 102.102.102.102 ebgp-multihop 2
R2(config-router)#neighbor 102.102.102.102 update-source loopback 2
R2(config-router)#neighbor 3.3.3.3 remote-as 65013
R2(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
R2(config-router)#neighbor 3.3.3.3 update-source loopback 2
R2(config-router)#neighbor 3.3.3.3 next-hop-self
R3(config)#router bgp 65013
R3(config-router)#bgp confederation identifier 100
R3(config-router)#bgp confederation peers 65002
R3(config-router)#neighbor 2.2.2.2 remote-as 65002
R3(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R3(config-router)#neighbor 2.2.2.2 update-source loopback 3
R3(config-router)#neighbor 1.1.1.1 remote-as 65013
R3(config-router)#neighbor 1.1.1.1 update-source loopback 3
R1(config)#router bgp 65013
R1(config-router)#bgp confederation identifier 100
R1(config-router)#neighbor 101.101.101.101 remote-as 101
R1(config-router)#neighbor 101.101.101.101 password ccnp
R1(config-router)#neighbor 101.101.101.101 ebgp-multihop 2
R1(config-router)#neighbor 101.101.101.101 update-source loopback 1
R1(config-router)#neighbor 3.3.3.3 remote-as 65013
R1(config-router)#neighbor 3.3.3.3 update-source loopback 1
R1(config-router)#neighbor 3.3.3.3 next-hop-self
Note: R1 does not need a bgp confederation peers command, as it does not have any confederation eBGP peers. Only R2 and R3 are confederation eBGP peers.
R2#show ip bgp | b Network
Network Next Hop Metric LocPrf Weight Path
* 192.168.40.40/32 1.1.1.1 0 100 0 (65013) 101 104 i
*> 102.102.102.102 0 102 103 104 i
* 192.168.41.41/32 1.1.1.1 0 100 0 (65013) 101 104 i
*> 102.102.102.102 0 102 103 104 i
* 192.168.42.42/32 1.1.1.1 0 100 0 (65013) 101 104 i
*> 102.102.102.102 0 102 103 104 i
* 192.168.43.43/32 1.1.1.1 0 100 0 (65013) 101 104 i
*> 102.102.102.102 0 102 103 104 i
* 192.168.44.44/32 1.1.1.1 0 100 0 (65013) 101 104 i
*> 102.102.102.102 0 102 103 104 i
R2 has received the 192.168.40.40/32 prefix, with sub-AS 65013 shown in parentheses, and true ASs 101 and 104 shown outside the parentheses. R2 has also learned the same prefix via AS 102 and R102. The route through AS 102 is best because it is the shortest AS_PATH (The shortest AS_PATH logic ignores the confederation sub-autonmous systems).
Note: For more details about this topic, check out CCIE Routing and Switching Certification Guide, Fourth Edition, Wendell Odom, Rus Healy, Denise Donohue, Cisco Press.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment