- Highest Weight
- Highest Local preference
- Locally originated
- Shortest AS_Path
- Origin; prefer IGP, before EGP, before Incomplete
- Lowest MED
- eBGP paths over iBGP paths
- Lowest IGP metric to the next hop
- For eBGP prefixes prefer first received route
- Lowest router ID
- Shortest cluster list length
- Lowest neighbor address
The BGP Best path
selection algorithm for BGP looks at several path attributes and evaluates
them in the following order of preference:
Topology
GNS3 files: Link
Solution
This lab touches on
the next as-path attribute in the best path selecting process which is the
router-id. When evaluating equal paths and when all other higher priority
attributes are equal the BGP algorithm compares the router-id of the
advertising peer and selects the lower router-id as the preferred path.
In this lab we are
initially asked to create loopback interfaces on R2 and R3 with identical IP
address to simulate a dual path scenario.
R2(config)#interface
loopback 10
R2(config-if)#ip
add 192.1.1.1 255.255.255.255
R3(config)#int lo
10
R3(config-if)#ip
add 192.1.1.1 255.255.255.255
With the loopback
interfaces created we are then asked to establish iBGP peering between R1, R2,
and R3.
R1(config)#router
bgp 100
R1(config-router)#neighbor
192.168.21.2 remote-as 100
R1(config-router)#neighbor
192.168.13.3 remote-as 100
R2(config)#router
bgp 100
R2(config-router)#neighbor
192.168.21.1 remote-as 100
R2(config-router)#neighbor
192.168.23.3 remote-as 100
R3(config)#router
bgp 100
R3(config-router)#neighbor
192.168.13.1 remote-as 100
R3(config-router)#neighbor
192.168.23.2 remote-as 100
At this point if
you have configure things in the order ask for in the lab you may find
yourself faced with the following error message being logged on both R2 and
R3.
%BGP-3-NOTIFICATION: sent to neighbor
192.168.23.3 passive 2/3 (BGP identifier wrong)
In addition you
will note that the BGP peering has not been established between these two
neighbors.
R2(config-router)#do
sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.21.1 4
100 8 9
1 0 0 00:05:02 0
192.168.23.3 4
100 0 0
1 0 0 never
Idle
R3(config-router)#do
sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.13.1 4
100 9 10
2 0 0 00:05:07 0
192.168.23.2 4
100 0 0
1 0 0 never
Idle
So what is going on
here you might ask. The problem is twofold and based on the order of operation
in which you entered your commands. BGP when initially configured will look
and assign a router-id if one is not explicitly configured under the BGP
router process. It will use loopbacks first and choose the loopback with the
highest IP address. In our case we had only the one loopback on R2 and R3 and
each configured with the same IP address. This caused the BGP processes on R2
and R3 to choose the same router-id for which is the root cause of our error.
Both routers see their own router-id (BGP Identifier) in the exchange BGP open
messages. This is not allowed and the peering is not established.
The solution is
relatively simple and is also the means by which we solve the final
requirement of the lab which Is to ensure R2 is the preferred path to
192.1.1.1/32 from R1. Since all other attributes are equal it falls the
router-id to determine the best path. Setting R2 with a higher router-id and
then clearing the BGP process to reset BGP to use its new router-id the issue
should now be resolved.
R2(config)#bgp
router 100
R2(config-router)#bgp
router-id 2.2.2.2
R3(config)#router
bgp 100
R3(config-router)#bgp
router-id 3.3.3.3
R1#do clear ip bgp
*
R1#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
* i 192.1.1.1/32 192.168.13.3 0 100
0 i
*>i 192.168.21.2 0 100
0 i
Sources
No comments:
Post a Comment