I ran into an issue while doing BGP confederations today. In the topology below, I was seeing sub-AS 65013 in the AS PATH on R5 for routes to VLAN4. I found out the problem but I decided to post this so if you ever see this issue, you can tell what it looks like.
VLAN4--R4---[[R1---R3]---[R2]]---R5--VLAN5 and 58
R4 = AS 3
R1,R3 = sub-AS 65013, AS 2
R2 = sub-AS 65002, AS 2
R5 = AS 1
VLAN4 = 204.1.12.0
VLAN5 = 155.1.5.0
VLAN58 = 155.1.58.0
Study the outputs below. Notice that R5 still sees sub-AS 65013 in it's routes to R4. The AS PATH should be: 2 3. What is the error I made?
-------------------------------------------------------------------------------
In the below output, R4 sees R5's VLAN coming from AS 1 and AS 2. There is no way of telling these come from condeferations.
R4#show ip bgp
BGP table version is 20, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.146.1 0 2 1 i
*> 155.1.58.0/24 155.1.146.1 0 2 1 i
*> 204.12.1.0 0.0.0.0 0 32768 i
R4#
-------------------------------------------------------------------------------
R1 sees both of R5's VLANS as coming from AS 1 and sub-AS 65002. R1 is confederation peer with sub-AS 65002.
R1#show ip bgp
BGP table version is 8, local router ID is 155.1.146.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i
*>i155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i
*> 204.12.1.0 155.1.146.4 0 0 3 i
R1#
-------------------------------------------------------------------------------
R3 sees the same thing as R1.
R3#show ip bgp
BGP table version is 8, local router ID is 155.1.37.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i
*> 155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i
*>i204.12.1.0 155.1.13.1 0 100 0 3 i
R3#
-------------------------------------------------------------------------------
R2 sees R5's vlan as originating from AS 1. It also sees R4's VLAN as coming from AS 3 and AS 65013 - not sure why there isn't parenthesis around 65013 in this case...
R2#sho ip bgp
BGP table version is 4, local router ID is 155.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.0.5 0 0 1 i
*> 155.1.58.0/24 155.1.0.5 0 0 1 i
*> 204.12.1.0 155.1.13.1 0 100 0 65013 3 i
R2#
-------------------------------------------------------------------------------
Here are R5 sees R4's VLAN as coming throigh AS 3 65013 and then from AS 2. Why is 65013 appearing?
R5#show ip bgp
BGP table version is 22, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 0.0.0.0 0 32768 i
*> 155.1.58.0/24 0.0.0.0 0 32768 i
*> 204.12.1.0 155.1.0.2 0 2 65013 3 i
R5#
-------------------------------------------------------------------------------
It turns out the error was on R3:
router bgp 65013
no synchronization
bgp log-neighbor-changes
bgp confederation peers 65002
neighbor 155.1.13.1 remote-as 65013
neighbor 155.1.23.2 remote-as 65002
I dont have a bgp confederation identifier!
Let's fix it:
R3(config)#router bgp 65013
R3(config-router)#bgp confederation identifier 2
That's much better:
R5#show ip bg
BGP table version is 24, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 0.0.0.0 0 32768 i
*> 155.1.58.0/24 0.0.0.0 0 32768 i
*> 204.12.1.0 155.1.0.2 0 2 3 i
Showing posts with label bgp confederation. Show all posts
Showing posts with label bgp confederation. Show all posts
Monday, July 7, 2008
BGP - External confedration peers
It is important to remember when doing confederations that although external confederation peers behave like EBGP peers in several ways, they do NOT modify the next hop without manual configuration.
Example:
R4 --- [[R1---R3]---[R2]]---R5
R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.
Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).
Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 5
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
(65002) 1
155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external
And after the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
155.1.13.1
(65002) 1
155.1.23.2 from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external, best
Example:
R4 --- [[R1---R3]---[R2]]---R5
R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.
Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).
Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 5
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
(65002) 1
155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external
And after the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
155.1.13.1
(65002) 1
155.1.23.2 from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external, best
Subscribe to:
Posts (Atom)
Posts
