6. Configuring iBGP
The configuration does not explicitly identify an eBGP versus an iBGP peer.
Instead, for iBGP, the neighbor’s ASN listed on the neighbor... remote-as neighbor-asn command lists the same ASN as the local router’s router bgp command. eBGP neighbor remote-as commands list a different ASN.
When two iBGP peers share a common physical link, such as R1 and R2, the iBGP configuration simply requires a single neighbor remote-as command on each router.
Let's configure an iBGP neighborship between R1 and R2 (and use the interface IDs, not the BGP router IDs).
First, we should shutdown the Fa0/0 interfaces on both R1 and R2, so that each of them has a single link to the ISP (to R101 and R102 respectively) and the FastEthernet interfaces on R103:
R1(config)#int fa 0/0
R1(config-if)#shutdown
R2(config)#int fa0/0
R2(config-if)#shutdown
R103(config)#int fa 0/0
R103(config-if)#shutdown
R103(config-if)#int fa 0/1
R103(config-if)#shutdown
Starting with the below configurations loaded on the routers, we are going to build the iBGP lab:
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 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 route 102.102.102.102 255.255.255.255 202.2.2.6
!
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 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
!
Now, R1 and R2 have a single neighbor each:
R1#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 2812 2818 40 0 0 1d22h 5
R2#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
102.102.102.102 4 102 2720 2715 24 0 0 1d21h 5
We can configure the iBGP neighborship between R1 and R2 using the interface IP addresses:
R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.0.30 remote-as 100
R2(config)#router bgp 100
R2(config-router)#neighbor 10.1.0.29 remote-as 100
*Mar 2 23:03:14.516: %BGP-5-ADJCHANGE: neighbor 10.1.0.30 Up
*Mar 2 23:02:02.872: %BGP-5-ADJCHANGE: neighbor 10.1.0.29 Up
R1 and R2 are now iBGP neighbors:
R1#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.30 4 100 5 7 40 0 0 00:00:34 5
101.101.101.101 4 101 2828 2834 40 0 0 1d22h 5
R2#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.29 4 100 83 78 24 0 0 00:51:05 7
102.102.102.102 4 102 2720 2715 24 0 0 1d21h 5
Note: Often the Internet-connected routers in an Enterprise do not share a common subnet. The two routers may be in separate buildings in a campus for the sake of redundancy.
In such cases, it makes sense to configure the iBGP peers using a loopback IP address for the TCP connection so that a single link failure does not cause the iBGP peer connection to fail.
The configuration to use loopback interfaces as the update source mirrors that same configuration for eBGP peers, except that iBGP peers do not need to configure the neighbor... ebgp-multihop command.
One difference between iBGP and eBGP is that IOS uses the low TTL of 1 for eBGP connections by default but does not for iBGP connections.
So, for iBGP connections, only the following steps are required to make two iBGP peers use a loopback interface:
Step 1. Configure an IP address on a loopback interface on each router.
Step 2. Configure each router to use the loopback IP address as the source IP address, for the neighborship with the other router, using the neighbor... update-source ip-address command.
Step 3. Configure the BGP neighbor command on each router to refer to the other router’s loopback IP address as the neighbor IP address in the neighbor neighbor-ip remote-as command.
Step 4. Make sure each router has IP routes so that they can forward packets to the loopback interface IP address of the other router.
First, let's check the BGP table and neighborships prior to the iBGP peering:
R1#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 17 16 6 0 0 00:13:07 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 summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
102.102.102.102 4 102 17 16 6 0 0 00:13:14 5
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
If we want to use loopback interfaces on both iBGP neighbors, we should create and include those loopbacks in the OSPF process first, so they both know about each other's BGP router ID:
R1(config)#interface loopback 10
R1(config-if)#ip address 1.1.1.10 255.255.255.255
R2(config)#interface loopback 20
R2(config-if)#ip address 2.2.2.20 255.255.255.255
R1(config)#router ospf 1
R1(config-router)#network 1.1.1.10 0.0.0.0 area 0
R2(config)#router ospf 1
R2(config-router)#network 2.2.2.20 0.0.0.0 area 0
R1(config)#router bgp 100
R1(config-router)#neighbor 2.2.2.20 remote-as 100
R1(config-router)#neighbor 2.2.2.20 update-source loopback 10
R2(config)#router bgp 100
R2(config-router)#neighbor 1.1.1.10 remote-as 100
R2(config-router)#neighbor 1.1.1.10 update-source loopback 20
*Mar 1 00:37:16.819: %BGP-5-ADJCHANGE: neighbor 2.2.2.20 Up
*Mar 1 00:37:05.891: %BGP-5-ADJCHANGE: neighbor 1.1.1.10 Up
Checking the BGP neighbors on both routers:
R1#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.20 4 100 98 98 6 0 0 01:34:00 5
101.101.101.101 4 101 115 114 6 0 0 01:51:30 5
R2#show ip bgp summary
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.10 4 100 99 99 6 0 0 01:34:45 5
102.102.102.102 4 102 115 114 6 0 0 01:51:57 5
The output can distinguish between an iBGP or eBGP neighbor but only by comparing the local router’s ASN (in the first line of output) to the ASN listed in each line at the bottom of the output.
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
* i192.168.40.40/32 102.102.102.102 0 100 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* i192.168.41.41/32 102.102.102.102 0 100 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* i192.168.42.42/32 102.102.102.102 0 100 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* i192.168.43.43/32 102.102.102.102 0 100 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* i192.168.44.44/32 102.102.102.102 0 100 0 102 103 104 i
*> 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
* i192.168.40.40/32 101.101.101.101 0 100 0 101 104 i
*> 102.102.102.102 0 102 103 104 i
* i192.168.41.41/32 101.101.101.101 0 100 0 101 104 i
*> 102.102.102.102 0 102 103 104 i
* i192.168.42.42/32 101.101.101.101 0 100 0 101 104 i
*> 102.102.102.102 0 102 103 104 i
* i192.168.43.43/32 101.101.101.101 0 100 0 101 104 i
*> 102.102.102.102 0 102 103 104 i
* i192.168.44.44/32 101.101.101.101 0 100 0 101 104 i
*> 102.102.102.102 0 102 103 104 i
Note: Code “i” in the third character means iBGP-learned route.
The output identifies external routes by the absence of an “i” in the third character, whereas the output lists an “i” in the third character for internal routes.
Let's check the BGP route to 192.168.40.40/32 on both routers:
R1#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
2
102 103 104
102.102.102.102 (inaccessible) from 2.2.2.20 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
101 104
101.101.101.101 from 101.101.101.101 (101.101.101.101)
Origin IGP, localpref 100, valid, external, best
R2#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
2
101 104
101.101.101.101 (inaccessible) from 1.1.1.10 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal
102 103 104
102.102.102.102 from 102.102.102.102 (102.102.102.102)
Origin IGP, localpref 100, valid, external, best
We notice that both routers list the next hop of one of the routes as "inaccessible". That's because none of them has any connectivity (route) to that next-hop IP.
By default, when a router advertises a route using eBGP, the advertising router lists its own update-source IP address as the next-hop address of the route.
When advertising a route to an iBGP peer, the advertising router (by default) does not change the next-hop address. That's why the router receiving the route should have a valid (reachable) next-hop to use that route.
The IP routing process can use routes whose next-hop addresses are not in connected subnets as long as each router has an IP route that matches the next-hop IP address.
Two main options exist to ensure reachability to these next-hop addresses:
A. Create IP routes so that each router can reach these next-hop addresses that exist in other ASNs (either add static routes or use an IGP between the Enterprise and the ISPs for the sole purpose of advertising these next-hop addresses).
B. Change the default iBGP behavior with the neighbor next-hop-self command (a router with this command configured advertises iBGP routes with its own update-source IP address as the next-hop IP address).
A. Using the first option (with IGP):
R1(config)#router ospf 1
R1(config-router)#network 201.1.1.0 0.0.0.3 area 0
R2(config)#router ospf 1
R2(config-router)#network 202.2.2.4 0.0.0.3 area 0
R101(config)#router ospf 1
R101(config-router)#network 201.1.1.0 0.0.0.3 area 0
R101(config-router)#network 101.101.101.101 0.0.0.0 area 0
R102(config)#router ospf 1
R102(config-router)#network 202.2.2.4 0.0.0.3 area 0
R102(config-router)#network 102.102.102.102 0.0.0.0 area 0
The new states of the same route:
R1#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
101 104
101.101.101.101 from 101.101.101.101 (101.101.101.101)
Origin IGP, localpref 100, valid, external, best
R2#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 17
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
101 104
101.101.101.101 (metric 75) from 1.1.1.10 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
102 103 104
102.102.102.102 from 102.102.102.102 (102.102.102.102)
Origin IGP, localpref 100, valid, external
R1#traceroute 192.168.40.40
Type escape sequence to abort.
Tracing the route to 192.168.40.40
1 201.1.1.2 44 msec 104 msec 56 msec
2 114.1.1.2 108 msec * 16 msec
R2#traceroute 192.168.40.40
Type escape sequence to abort.
Tracing the route to 192.168.40.40
1 10.1.0.29 4 msec 68 msec 12 msec
2 201.1.1.2 28 msec 88 msec 4 msec
3 114.1.1.2 104 msec * 96 msec
B. Now we will use the second option:
R1(config)#router bgp 100
R1(config-router)#neighbor 2.2.2.20 next-hop-self
R2(config)#router bgp 100
R2(config-router)#neighbor 1.1.1.10 next-hop-self
Now, checking the same BGP routes again:
R1#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
101 104
101.101.101.101 from 101.101.101.101 (101.101.101.101)
Origin IGP, localpref 100, valid, external, best
R2#show ip bgp 192.168.40.40/32
BGP routing table entry for 192.168.40.40/32, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1
101 104
1.1.1.10 (metric 65) from 1.1.1.10 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
102 103 104
102.102.102.102 from 102.102.102.102 (102.102.102.102)
Origin IGP, localpref 100, valid, external
Let's see how the BGP tables have changed:
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 11, 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
*>i192.168.40.40/32 1.1.1.10 0 100 0 101 104 i
* 102.102.102.102 0 102 103 104 i
*>i192.168.41.41/32 1.1.1.10 0 100 0 101 104 i
* 102.102.102.102 0 102 103 104 i
*>i192.168.42.42/32 1.1.1.10 0 100 0 101 104 i
* 102.102.102.102 0 102 103 104 i
*>i192.168.43.43/32 1.1.1.10 0 100 0 101 104 i
* 102.102.102.102 0 102 103 104 i
*>i192.168.44.44/32 1.1.1.10 0 100 0 101 104 i
* 102.102.102.102 0 102 103 104 i
The above output confirms that R1 learned the routes for 192.168.x.x via eBGP from R101, advertised them to R2 via iBGP (as denoted by the "i" in R2's output), and R2 chose to use those iBGP learned routes as its best routes to reach the 192.168.x.x subnets on R104.
The path through R1 has been chosen by R2 as best because of the shorter AS Path (all other BGP PAs being at their defaults: equal Weights (0), equal Local Pref (100), not locally injected).
Note: Order of the PAs considered: - 0. Next-hop reachability - should be reachable
- 1. Weight - bigger wins
- 2. Local Preference - bigger wins
- 3. Locally injected routes - locally injected (network command or redistribution better than iBGP and eBGP)
- 4. AS_PATH - smaller wins
- 5. ORIGIN - prefer I over E over ?
- 6. MED - smaller wins
- 7. Neighbor type - prefer eBGP over iBGP
- 8. IGP Metric to next-hop - smaller wins
From the output of show ip bgp we can see that R1 has no alternative routes to the 192.168.x.x subnets.
That's because R2 learned routes to 192.168.x.x from R1, which is its iBGP peer and it wouldn't make sense to advertise routes to the same destinations back to R1.
Note: The rule is "Do not advertise iBGP-learned routes to iBGP peers."
Due to the shortest AS Path through R1-R101-R104 (and after configuring appropriate static routes for IP connectivity):
R1#traceroute 192.168.40.40
Type escape sequence to abort.
Tracing the route to 192.168.40.40
1 201.1.1.2 36 msec 72 msec 44 msec
2 114.1.1.2 24 msec * 104 msec
R2#traceroute 192.168.40.40
Type escape sequence to abort.
Tracing the route to 192.168.40.40
1 10.1.0.29 80 msec 52 msec 12 msec
2 201.1.1.2 44 msec 88 msec 36 msec
3 114.1.1.2 88 msec * 84 msec
Configured static routes were:
R1(config)#ip route 0.0.0.0 0.0.0.0 201.1.1.2
R104(config)#ip route 0.0.0.0 0.0.0.0 114.1.1.1
R2(config)#ip route 201.1.1.0 255.255.255.252 10.1.0.29
R101(config)#ip route 10.1.0.28 255.255.255.252 201.1.1.1
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment