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
Wednesday, April 30, 2014
Thursday, April 24, 2014
CCNP ROUTE: 5. Injecting Routes into BGP for Advertisement to the ISPs
The ISPs need to learn routes for the Enterprise’s public IP address space.
Options for advertising routes to the ISP:
- BGP network command
- Redistribution from an IGP
Adding to configurations made on R1, R101, R102, R103 and R104 in the previous lab, we will first configure R2 to be a part of the eBGP process between the Enterprise (AS 100) and the ISPs.
R2's configuration and R101/R102's updated configurations:
R2:
!
interface Loopback2
ip address 2.2.2.2 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 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback2
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 101.101.101.101 255.255.255.255 201.1.1.6
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 2.2.2.2 remote-as 100
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 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 2.2.2.2 255.255.255.255 201.1.1.5
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 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback102
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 1.1.1.1 255.255.255.255 202.2.2.1
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
!
R2#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 9 9 6 0 0 00:04:40 5
102.102.102.102 4 102 9 9 6 0 0 00:04:01 5
Note: Routers R1 - R5 have OSPF running between them.
Injecting Routes Using the network Command
For OSPF and EIGRP, the network command lists parameters that the router then compares to all its interface IP addresses. If matched, the router enables the IGP routing protocol on those interfaces.
BGP does not use the network command to enable BGP on interfaces - the BGP network command does cause a comparison to occur, but the comparison occurs between the network command’s parameters and the contents of that router’s IP routing table, as follows:
Rule: Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if a route for that exact prefix/length exists, put the equivalent prefix/length into the local BGP table.
Let's assume a subnet with a public prefix is connected to R5 and it is required to be advertised to the ISPs.
R5#show ip route 155.55.0.0
Routing entry for 155.55.0.0/19, 1 known subnets
Attached (1 connections)
C 155.55.32.0 is directly connected, Loopback155
This network is advertised through OSPF to R1:
R5#show run | s ospf
...
network 155.55.32.0 0.0.31.255 area 0
R1#show ip route 155.55.0.0
Routing entry for 155.55.0.0/19, 1 known subnets
O 155.55.32.0 [110/75] via 10.1.0.26, 00:03:37, Serial0/2
[110/75] via 10.1.0.13, 00:03:37, Serial0/0
In order for R1 to advertise Lo10's IP address to the ISPs, we have to configure this using the network command:
R1(config)#router bgp 100
R1(config-router)#network 155.55.32.0 mask 255.255.224.0
R1#show ip bgp
BGP table version is 11, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 i
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
Note: It adds this prefix to the BGP table only if the exact prefix with that same mask exists in Router R1’s routing table.
R1 then advertises the new prefix to the ISPs - let's verify this on R104:
R104#show ip bgp
BGP table version is 13, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Note: In some cases, the Internet-connected router may not have a single route for the entire public prefix.
When a router knows routes only for subsets of the prefix that needs to be advertised, an additional step is needed when using the network command.
Either configure a static route for the entire range, with outgoing interface null0, on the Internet facing router, or use IGP route summarization to create a summary route for the entire prefix with IGP.
The static route to null0 — a discard route — is not meant to be advertised to other routers. It’s only purpose is to enable the operation of the network command.
Note: The network command uses the mask parameter, but if omitted, IOS assumes a classful network mask (/8, /16, /24).
Note: As of Cisco IOS version 12.3 mainline, BGP defaults to a setting of no auto-summary.
Injecting Routes Using Redistribution
Instead of using a BGP network command to add routes to the BGP table, the Enterprise BGP routers can instead redistribute routes from an IGP into BGP.
First, we should delete the network statement configured above.
R1(config)#router bgp 100
R1(config-router)#no network 155.55.32.0 mask 255.255.224.0
R104#show ip bgp
BGP table version is 15, local router ID is 192.168.44.44
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 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Next, if we will going to redistribute the same subnet from OSPF to BGP, we should filter other internal routes from being sent to the ISPs.
R1(config)#ip prefix-list 155subnet permit 155.55.32.0/19 le 32
R1(config)#route-map only155 permit
R1(config-route-map)#match ip address prefix-list 155subnet
R1#show route-map
route-map only155, permit, sequence 10
Match clauses:
ip address prefix-lists: 155subnet
Set clauses:
Policy routing matches: 0 packets, 0 bytes
As a result, the subnet is advertised to the ISPs:
R1#show ip bgp
BGP table version is 29, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
R104#show ip bgp
BGP table version is 40, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
The BGP aggregate-address Command to Advertise the Entire Public IP Address Prefix
We can use BGP route summarization when we have multiple subset routes of the same subnet in the BGP table, but we want to advertise only the summary to the BGP neighbors and none of the subset routes.
Let's include R5's loopback interfaces into OSPF, so that R1 can learn about them and advertise them into BGP.
R5(config)#router ospf 1
R5(config-router)#network 172.16.0.0 0.0.255.255 a 0
R1 learnes about these routes and inserts them into the routing table:
R1#show ip route
...
O 172.16.14.14 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.13.13 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.12.12 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.11.11 [110/75] via 10.1.0.26, 00:00:09, Serial0/2
[110/75] via 10.1.0.13, 00:00:09, Serial0/0
O 172.16.10.10 [110/75] via 10.1.0.26, 00:00:09, Serial0/2
[110/75] via 10.1.0.13, 00:00:09, Serial0/0
...
Now, if we tell R1 to include these routes into the BGP process, they will be added to the BGP table and advertised all the way to R104:
R1(config)#router bgp 100
R1(config-router)#network 172.16.10.10 mask 255.255.255.255
R1(config-router)#network 172.16.11.11 mask 255.255.255.255
R1(config-router)#network 172.16.12.12 mask 255.255.255.255
R1(config-router)#network 172.16.13.13 mask 255.255.255.255
R1(config-router)#network 172.16.14.14 mask 255.255.255.255
R1(config-router)#do show ip bgp
BGP table version is 34, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
*> 172.16.10.10/32 10.1.0.13 75 32768 i
*> 172.16.11.11/32 10.1.0.13 75 32768 i
*> 172.16.12.12/32 10.1.0.13 75 32768 i
*> 172.16.13.13/32 10.1.0.13 75 32768 i
*> 172.16.14.14/32 10.1.0.13 75 32768 i
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
R104#show ip bgp
BGP table version is 45, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
* 172.16.10.10/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.11.11/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.12.12/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.13.13/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.14.14/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Now, if we want to advertise just the summary route and not all its subnets, we can use the aggregate-address command and the summary-only keyword.
R1(config)#router bgp 100
R1(config-router)#aggregate-address 172.16.0.0 255.255.0.0 summary-only
Let's check R1's and R104's BGP tables and see the summary routes instead of the subset routes:
R1(config-router)#do show ip bgp
BGP table version is 40, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
*> 172.16.0.0 0.0.0.0 32768 i
s> 172.16.10.10/32 10.1.0.13 75 32768 i
s> 172.16.11.11/32 10.1.0.13 75 32768 i
s> 172.16.12.12/32 10.1.0.13 75 32768 i
s> 172.16.13.13/32 10.1.0.13 75 32768 i
s> 172.16.14.14/32 10.1.0.13 75 32768 i
...
R104#show ip bgp
BGP table version is 56, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
* 172.16.0.0 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Note: The summary-only keyword in the aggregate-address command tells IOS to suppress the advertisement the subset routes, as noted by the code “s” beside the routes.
Options for advertising routes to the ISP:
- BGP network command
- Redistribution from an IGP
Adding to configurations made on R1, R101, R102, R103 and R104 in the previous lab, we will first configure R2 to be a part of the eBGP process between the Enterprise (AS 100) and the ISPs.
R2's configuration and R101/R102's updated configurations:
R2:
!
interface Loopback2
ip address 2.2.2.2 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 ebgp-multihop 2
neighbor 101.101.101.101 update-source Loopback2
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 101.101.101.101 255.255.255.255 201.1.1.6
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 2.2.2.2 remote-as 100
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 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 2.2.2.2 255.255.255.255 201.1.1.5
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 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback102
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 1.1.1.1 255.255.255.255 202.2.2.1
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
!
R2#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 9 9 6 0 0 00:04:40 5
102.102.102.102 4 102 9 9 6 0 0 00:04:01 5
Note: Routers R1 - R5 have OSPF running between them.
Injecting Routes Using the network Command
For OSPF and EIGRP, the network command lists parameters that the router then compares to all its interface IP addresses. If matched, the router enables the IGP routing protocol on those interfaces.
BGP does not use the network command to enable BGP on interfaces - the BGP network command does cause a comparison to occur, but the comparison occurs between the network command’s parameters and the contents of that router’s IP routing table, as follows:
Rule: Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if a route for that exact prefix/length exists, put the equivalent prefix/length into the local BGP table.
Let's assume a subnet with a public prefix is connected to R5 and it is required to be advertised to the ISPs.
R5#show ip route 155.55.0.0
Routing entry for 155.55.0.0/19, 1 known subnets
Attached (1 connections)
C 155.55.32.0 is directly connected, Loopback155
This network is advertised through OSPF to R1:
R5#show run | s ospf
...
network 155.55.32.0 0.0.31.255 area 0
R1#show ip route 155.55.0.0
Routing entry for 155.55.0.0/19, 1 known subnets
O 155.55.32.0 [110/75] via 10.1.0.26, 00:03:37, Serial0/2
[110/75] via 10.1.0.13, 00:03:37, Serial0/0
In order for R1 to advertise Lo10's IP address to the ISPs, we have to configure this using the network command:
R1(config)#router bgp 100
R1(config-router)#network 155.55.32.0 mask 255.255.224.0
R1#show ip bgp
BGP table version is 11, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 i
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
Note: It adds this prefix to the BGP table only if the exact prefix with that same mask exists in Router R1’s routing table.
R1 then advertises the new prefix to the ISPs - let's verify this on R104:
R104#show ip bgp
BGP table version is 13, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Note: In some cases, the Internet-connected router may not have a single route for the entire public prefix.
When a router knows routes only for subsets of the prefix that needs to be advertised, an additional step is needed when using the network command.
Either configure a static route for the entire range, with outgoing interface null0, on the Internet facing router, or use IGP route summarization to create a summary route for the entire prefix with IGP.
The static route to null0 — a discard route — is not meant to be advertised to other routers. It’s only purpose is to enable the operation of the network command.
Note: The network command uses the mask parameter, but if omitted, IOS assumes a classful network mask (/8, /16, /24).
Note: As of Cisco IOS version 12.3 mainline, BGP defaults to a setting of no auto-summary.
Injecting Routes Using Redistribution
Instead of using a BGP network command to add routes to the BGP table, the Enterprise BGP routers can instead redistribute routes from an IGP into BGP.
First, we should delete the network statement configured above.
R1(config)#router bgp 100
R1(config-router)#no network 155.55.32.0 mask 255.255.224.0
R104#show ip bgp
BGP table version is 15, local router ID is 192.168.44.44
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 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Next, if we will going to redistribute the same subnet from OSPF to BGP, we should filter other internal routes from being sent to the ISPs.
R1(config)#ip prefix-list 155subnet permit 155.55.32.0/19 le 32
R1(config)#route-map only155 permit
R1(config-route-map)#match ip address prefix-list 155subnet
R1#show route-map
route-map only155, permit, sequence 10
Match clauses:
ip address prefix-lists: 155subnet
Set clauses:
Policy routing matches: 0 packets, 0 bytes
As a result, the subnet is advertised to the ISPs:
R1#show ip bgp
BGP table version is 29, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
R104#show ip bgp
BGP table version is 40, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
The BGP aggregate-address Command to Advertise the Entire Public IP Address Prefix
We can use BGP route summarization when we have multiple subset routes of the same subnet in the BGP table, but we want to advertise only the summary to the BGP neighbors and none of the subset routes.
Let's include R5's loopback interfaces into OSPF, so that R1 can learn about them and advertise them into BGP.
R5(config)#router ospf 1
R5(config-router)#network 172.16.0.0 0.0.255.255 a 0
R1 learnes about these routes and inserts them into the routing table:
R1#show ip route
...
O 172.16.14.14 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.13.13 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.12.12 [110/75] via 10.1.0.26, 00:00:07, Serial0/2
[110/75] via 10.1.0.13, 00:00:07, Serial0/0
O 172.16.11.11 [110/75] via 10.1.0.26, 00:00:09, Serial0/2
[110/75] via 10.1.0.13, 00:00:09, Serial0/0
O 172.16.10.10 [110/75] via 10.1.0.26, 00:00:09, Serial0/2
[110/75] via 10.1.0.13, 00:00:09, Serial0/0
...
Now, if we tell R1 to include these routes into the BGP process, they will be added to the BGP table and advertised all the way to R104:
R1(config)#router bgp 100
R1(config-router)#network 172.16.10.10 mask 255.255.255.255
R1(config-router)#network 172.16.11.11 mask 255.255.255.255
R1(config-router)#network 172.16.12.12 mask 255.255.255.255
R1(config-router)#network 172.16.13.13 mask 255.255.255.255
R1(config-router)#network 172.16.14.14 mask 255.255.255.255
R1(config-router)#do show ip bgp
BGP table version is 34, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
*> 172.16.10.10/32 10.1.0.13 75 32768 i
*> 172.16.11.11/32 10.1.0.13 75 32768 i
*> 172.16.12.12/32 10.1.0.13 75 32768 i
*> 172.16.13.13/32 10.1.0.13 75 32768 i
*> 172.16.14.14/32 10.1.0.13 75 32768 i
* 192.168.40.40/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
R104#show ip bgp
BGP table version is 45, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
* 172.16.10.10/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.11.11/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.12.12/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.13.13/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
* 172.16.14.14/32 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Now, if we want to advertise just the summary route and not all its subnets, we can use the aggregate-address command and the summary-only keyword.
R1(config)#router bgp 100
R1(config-router)#aggregate-address 172.16.0.0 255.255.0.0 summary-only
Let's check R1's and R104's BGP tables and see the summary routes instead of the subset routes:
R1(config-router)#do show ip bgp
BGP table version is 40, 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
*> 155.55.32.0/19 10.1.0.13 75 32768 ?
*> 172.16.0.0 0.0.0.0 32768 i
s> 172.16.10.10/32 10.1.0.13 75 32768 i
s> 172.16.11.11/32 10.1.0.13 75 32768 i
s> 172.16.12.12/32 10.1.0.13 75 32768 i
s> 172.16.13.13/32 10.1.0.13 75 32768 i
s> 172.16.14.14/32 10.1.0.13 75 32768 i
...
R104#show ip bgp
BGP table version is 56, local router ID is 192.168.44.44
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
* 155.55.32.0/19 103.103.103.103 0 103 102 100 ?
*> 101.101.101.101 0 101 100 ?
* 172.16.0.0 103.103.103.103 0 103 102 100 i
*> 101.101.101.101 0 101 100 i
*> 192.168.40.40/32 0.0.0.0 0 32768 i
*> 192.168.41.41/32 0.0.0.0 0 32768 i
*> 192.168.42.42/32 0.0.0.0 0 32768 i
*> 192.168.43.43/32 0.0.0.0 0 32768 i
*> 192.168.44.44/32 0.0.0.0 0 32768 i
Note: The summary-only keyword in the aggregate-address command tells IOS to suppress the advertisement the subset routes, as noted by the code “s” beside the routes.
CCNP ROUTE: 4. BGP Table
To advertise routes to eBGP peers, particularly the public IP address prefix(es) used by that Enterprise, the Enterprise BGP router needs some additional configuration, as discussed futher.
A router stores all learned BGP prefixes and PAs in its BGP table. The router can then advertise its BGP table to its neighbors, advertising only the best route for each prefix.
When a BGP neighborship reaches the established state, those neighbors begin sending BGP Update messages to each other.
The router receiving an Update places those learned prefixes into its BGP table, regardless of whether the route appears to be the best route.
Like EIGRP and OSPF, BGP puts all learned routing information into its table, and then BGP processes all such potential routes to choose the best route for each prefix.
BGP uses the Update message to both announce and withdraw routes.
For example, when a router realizes that a route in the router’s BGP table has failed, that router withdraws that route by sending a BGP Update to its neighbors, listing the prefix in the list of withdrawn routes.
When a router receives an Update that lists a prefix as withdrawn, that router knows that the route has failed.
First, we should configure BGP neighborships between R1, R101, R102, R103 and R104:
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
neighbor 102.102.102.102 remote-as 102
neighbor 102.102.102.102 ebgp-multihop 2
neighbor 102.102.102.102 update-source Loopback1
no auto-summary
!
ip route 101.101.101.101 255.255.255.255 201.1.1.2
ip route 102.102.102.102 255.255.255.255 202.2.2.2
!
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 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 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 route 1.1.1.1 255.255.255.255 202.2.2.1
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
!
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
!
Note: R103's FastEthernet interfaces will be shutdown for this lab.
Let's check all the BGP neighborships:
R1#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 132 130 6 0 0 01:38:24 5
102.102.102.102 4 102 19 19 6 0 0 00:14:46 5
R101#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 131 133 6 0 0 01:39:14 0
104.104.104.104 4 104 69 69 6 0 0 01:03:43 5
R102#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 20 20 11 0 0 00:15:40 5
103.103.103.103 4 103 16 17 11 0 0 00:11:17 5
R103#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
102.102.102.102 4 102 17 16 11 0 0 00:11:22 0
104.104.104.104 4 104 12 13 11 0 0 00:07:54 5
R104#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 69 69 6 0 0 01:03:55 0
103.103.103.103 4 103 13 12 6 0 0 00:07:57 0
Let's verify the BGP table on R1 - it shoud contain two routes for each loopback interface on R104 - one is learned from R101 and the other from R102:
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 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
The above output has the following columns:
- The Network heading lists the destination prefix/length (NLRI).
- The Next Hop heading lists the next-hop IP address (BGP router ID address) that would be used for the route.
- The Path heading lists the AS_Path PA (AS list). BGP show commands list the AS_Path with the first-added ASN on the right and the last-added ASN on the left.
- The > denotes the chosen best route. None of the routers inside the various ISPs set PAs for the purpose of influencing the best path choice, so the first used BGP best path decision is the shortest AS_Path.
- We can confirm that all E1’s BGP table entries were learned using eBGP, rather than iBGP, by the absence of the letter “i” in the third column. Immediately after the *>, a space appears in the output. If a route was learned with iBGP, an “i” would appear in this third character position.
Let's check the routing table of R1 - it should contain the routes from the BGP table that were chosen as best routes (>):
R1#show ip route bgp
192.168.44.0/32 is subnetted, 1 subnets
B 192.168.44.44 [20/0] via 101.101.101.101, 01:01:03
192.168.42.0/32 is subnetted, 1 subnets
B 192.168.42.42 [20/0] via 101.101.101.101, 01:01:03
192.168.43.0/32 is subnetted, 1 subnets
B 192.168.43.43 [20/0] via 101.101.101.101, 01:01:03
192.168.40.0/32 is subnetted, 1 subnets
B 192.168.40.40 [20/0] via 101.101.101.101, 01:01:33
192.168.41.0/32 is subnetted, 1 subnets
B 192.168.41.41 [20/0] via 101.101.101.101, 01:01:03
More info about each BGP route can be seen using:
R1#show ip route 192.168.44.44
Routing entry for 192.168.44.44/32
Known via "bgp 100", distance 20, metric 0
Tag 101, type external
Last update from 101.101.101.101 01:01:59 ago
Routing Descriptor Blocks:
* 101.101.101.101, from 101.101.101.101, 01:01:59 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 101
Verification Commands for eBGP-Learned Routes
show ip bgp neighbors ip-address received-routes - List routes learned from one neighbor, before any inbound filtering is applied.
show ip bgp neighbors ip-address routes - List routes learned from a specific neighbor that passed any inbound filters.
show ip bgp neighbors ip-address advertised-routes - Lists routes advertised to a neighbor after applying outbound filtering.
A router stores all learned BGP prefixes and PAs in its BGP table. The router can then advertise its BGP table to its neighbors, advertising only the best route for each prefix.
When a BGP neighborship reaches the established state, those neighbors begin sending BGP Update messages to each other.
The router receiving an Update places those learned prefixes into its BGP table, regardless of whether the route appears to be the best route.
Like EIGRP and OSPF, BGP puts all learned routing information into its table, and then BGP processes all such potential routes to choose the best route for each prefix.
BGP uses the Update message to both announce and withdraw routes.
For example, when a router realizes that a route in the router’s BGP table has failed, that router withdraws that route by sending a BGP Update to its neighbors, listing the prefix in the list of withdrawn routes.
When a router receives an Update that lists a prefix as withdrawn, that router knows that the route has failed.
First, we should configure BGP neighborships between R1, R101, R102, R103 and R104:
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
neighbor 102.102.102.102 remote-as 102
neighbor 102.102.102.102 ebgp-multihop 2
neighbor 102.102.102.102 update-source Loopback1
no auto-summary
!
ip route 101.101.101.101 255.255.255.255 201.1.1.2
ip route 102.102.102.102 255.255.255.255 202.2.2.2
!
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 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 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 route 1.1.1.1 255.255.255.255 202.2.2.1
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
!
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
!
Note: R103's FastEthernet interfaces will be shutdown for this lab.
Let's check all the BGP neighborships:
R1#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 132 130 6 0 0 01:38:24 5
102.102.102.102 4 102 19 19 6 0 0 00:14:46 5
R101#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 131 133 6 0 0 01:39:14 0
104.104.104.104 4 104 69 69 6 0 0 01:03:43 5
R102#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 20 20 11 0 0 00:15:40 5
103.103.103.103 4 103 16 17 11 0 0 00:11:17 5
R103#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
102.102.102.102 4 102 17 16 11 0 0 00:11:22 0
104.104.104.104 4 104 12 13 11 0 0 00:07:54 5
R104#show ip bgp summary | begin Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 69 69 6 0 0 01:03:55 0
103.103.103.103 4 103 13 12 6 0 0 00:07:57 0
Let's verify the BGP table on R1 - it shoud contain two routes for each loopback interface on R104 - one is learned from R101 and the other from R102:
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 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.41.41/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.42.42/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.43.43/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
* 192.168.44.44/32 102.102.102.102 0 102 103 104 i
*> 101.101.101.101 0 101 104 i
The above output has the following columns:
- The Network heading lists the destination prefix/length (NLRI).
- The Next Hop heading lists the next-hop IP address (BGP router ID address) that would be used for the route.
- The Path heading lists the AS_Path PA (AS list). BGP show commands list the AS_Path with the first-added ASN on the right and the last-added ASN on the left.
- The > denotes the chosen best route. None of the routers inside the various ISPs set PAs for the purpose of influencing the best path choice, so the first used BGP best path decision is the shortest AS_Path.
- We can confirm that all E1’s BGP table entries were learned using eBGP, rather than iBGP, by the absence of the letter “i” in the third column. Immediately after the *>, a space appears in the output. If a route was learned with iBGP, an “i” would appear in this third character position.
Let's check the routing table of R1 - it should contain the routes from the BGP table that were chosen as best routes (>):
R1#show ip route bgp
192.168.44.0/32 is subnetted, 1 subnets
B 192.168.44.44 [20/0] via 101.101.101.101, 01:01:03
192.168.42.0/32 is subnetted, 1 subnets
B 192.168.42.42 [20/0] via 101.101.101.101, 01:01:03
192.168.43.0/32 is subnetted, 1 subnets
B 192.168.43.43 [20/0] via 101.101.101.101, 01:01:03
192.168.40.0/32 is subnetted, 1 subnets
B 192.168.40.40 [20/0] via 101.101.101.101, 01:01:33
192.168.41.0/32 is subnetted, 1 subnets
B 192.168.41.41 [20/0] via 101.101.101.101, 01:01:03
More info about each BGP route can be seen using:
R1#show ip route 192.168.44.44
Routing entry for 192.168.44.44/32
Known via "bgp 100", distance 20, metric 0
Tag 101, type external
Last update from 101.101.101.101 01:01:59 ago
Routing Descriptor Blocks:
* 101.101.101.101, from 101.101.101.101, 01:01:59 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 101
Verification Commands for eBGP-Learned Routes
show ip bgp neighbors ip-address received-routes - List routes learned from one neighbor, before any inbound filtering is applied.
show ip bgp neighbors ip-address routes - List routes learned from a specific neighbor that passed any inbound filters.
show ip bgp neighbors ip-address advertised-routes - Lists routes advertised to a neighbor after applying outbound filtering.
CCNP ROUTE: 3. eBGP Neighborships & Issues When Redundancy Exists Between eBGP Neighbors
When redundant Layer 3 paths exist between two eBGP neighbors, the use of interface IP addresses for the underlying TCP connection can result in an outage when only one of the two links fails.
BGP neighborships fail when the underlying TCP connection fails.
TCP uses a concept called a socket, which consists of a local TCP port number and an IP address.
That IP address must be associated with a working interface (an interface whose state is line status up, line protocol up, per the show interfaces command).
If the interface whose IP address is used by BGP were to fail, then the TCP socket would fail, closing the TCP connection. As a result, the BGP neighborship can only be up when the associated interfaces also happens to be up.
One option would be to configure two neighbor commands on each router, one for each of the neighbor’s interface IP addresses - big bandwidth and memory consumption.
The preferred option, which uses loopback interfaces as the TCP connection endpoints, solves the availability problem while avoiding the extra overhead.
The two routers each configure a loopback interface and IP address, and use those loopback IP addresses as the source of their single BGP TCP connection.
If one of the multiple links fails, the loopback interface does not fail. As long as the two routers have working routes to reach each other’s loopback IP addresses, the TCP connection does not fail.
Configuring eBGP peers to use a loopback interface IP address with BGP requires several steps, as follows:
Step 1. Configure an IP address on a loopback interface on each router.
Step 2. Tell BGP on each router to use the loopback IP address as the source IP address 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 at 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.
Step 5. Configure eBGP multihop using the neighbor... ebgp-multihop hops command. This command defines the TTL that the router will use when creating the BGP packets.
The fifth configuration step for using loopback IP addresses with eBGP peers refers to a feature called eBGP multihop. By default, when building packets to send to an eBGP peer, IOS sets the IP Time-To-Live (TTL) field in the IP header to a value of 1.
With this default action, the eBGP neighborship fails to complete when using loopback interface IP addresses.
Let's consider routers R1 and R101 and configure all the above options (steps):
R1(config)#interface loopback 1
*Mar 1 00:02:23.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#ip route 101.101.101.101 255.255.255.255 201.1.1.2
R101(config)#interface loopback 101
*Mar 1 00:02:49.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R101(config-if)#ip address 101.101.101.101 255.255.255.255
R101(config)#ip route 1.1.1.1 255.255.255.255 201.1.1.1
R1#ping 101.101.101.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 101.101.101.101, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms
R101#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/52 ms
Now the BGP configuration (+ MD5 authentication):
R1(config)#router bgp 100
R1(config-router)#neighbor 101.101.101.101 remote-as 101
R1(config-router)#neighbor 101.101.101.101 update-source loopback 1
R1(config-router)#neighbor 101.101.101.101 ebgp-multihop 2
R1(config-router)#neighbor 101.101.101.101 password ccnp
R1(config-router)#
*Mar 1 00:06:19.835: %TCP-6-BADAUTH: No MD5 digest from 101.101.101.101(179) to 1.1.1.1(55651) (RST)
R101(config)#router bgp 101
R101(config-router)#neighbor 1.1.1.1 remote-as 100
R101(config-router)#neighbor 1.1.1.1 update-source loopback 101
R101(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
R101(config-router)#neighbor 1.1.1.1 password ccnp
R1(config-router)#
*Mar 1 00:08:11.431: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Up
R101(config-router)#
*Mar 1 00:08:12.883: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 4 4 1 0 0 00:01:07 0
R101#show ip bgp summary
BGP router identifier 101.101.101.101, local AS number 101
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 3 3 1 0 0 00:00:55 0
Note: The Neighbor column lists the IP address as defined on the local router’s neighbor command and not the neighbor’s BGP RID.
Note: The State/PfxRcd column either lists the BGP neighbor state or the number of prefixes received (PfxRcd) from that neighbor.
A numeric value under this heading implies a neighbor state of established, because the peers must be in established state before Updates can be sent. If the peer is not in an established state, the value in this heading lists the text name of the current BGP state.
BGP Neighbor States
Idle - The BGP process is either administratively down or awaiting the next retry attempt.
Connect - The BGP process is waiting for the TCP connection to be completed. You cannot determine from this state information whether the TCP connection can complete.
Active - The TCP connection has been completed, but no BGP messages have been sent to the peer yet.
Opensent - The TCP connection exists and a BGP Open message has been sent to the peer, but the matching Open message has not yet been received from the other router.
Openconfirm - An Open message has been both sent to and received from the other router. The next step is to receive a BGP Keepalive message (to confirm all neighbor-related parameters matched) or BGP Notification message (to learn there is some mismatch in neighbor parameters).
Established - All neighbor parameters match, the neighbor relationship works, and the peers can now exchange Update messages.
More information about a neighbor can be seen using:
R1#show ip bgp neighbors 101.101.101.101
BGP neighbor is 101.101.101.101, remote AS 101, external link
BGP version 4, remote router ID 101.101.101.101
BGP state = Established, up for 00:10:11
Last read 00:00:10, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 0
Keepalives: 12 12
Route Refresh: 0 0
Total: 13 13
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 1; dropped 0
Last reset never
External BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 1.1.1.1, Local port: 179
Foreign host: 101.101.101.101, Foreign port: 13302
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x10E064):
Timer Starts Wakeups Next
Retrans 13 0 0x0
TimeWait 0 0 0x0
AckHold 13 12 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 517553984 snduna: 517554258 sndnxt: 517554258 sndwnd: 16111
irs: 3069838838 rcvnxt: 3069839112 rcvwnd: 16111 delrcvwnd: 273
SRTT: 247 ms, RTTO: 663 ms, RTV: 416 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs, md5
IP Precedence value : 6
Datagrams (max data segment is 536 bytes):
Rcvd: 15 (out of order: 0), with data: 13, total data bytes: 273
Sent: 25 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 12, total data bytes: 273
We can further verify TCP socket state and details using:
R1#show tcp brief
TCB Local Address Foreign Address (state)
65CD8A58 1.1.1.1.179 101.101.101.101.13302 ESTAB
Cisco IOS provides a means to administratively disable any BGP neighbor. Using the debug ip bgp command, BGP messages and states can be viewed:
R1#debug ip bgp
R1(config)#router bgp 100
R1(config-router)#neighbor 101.101.101.101 shutdown
*Mar 1 00:33:37.235: BGPNSF state: 101.101.101.101 went from nsf_not_active to nsf_not_active
*Mar 1 00:33:37.239: BGP: 101.101.101.101 went from Established to Idle
*Mar 1 00:33:37.239: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Down Admin. shutdown
*Mar 1 00:33:37.239: BGP: 101.101.101.101 closing
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 28 28 0 0 0 00:02:07 Idle (Admin)
R1(config)#router bgp 100
R1(config-router)#no neighbor 101.101.101.101 shutdown
*Mar 1 00:36:08.247: BGP: 101.101.101.101 went from Idle to Active
*Mar 1 00:36:08.263: BGP: 101.101.101.101 open active, local address 1.1.1.1
*Mar 1 00:36:08.335: BGP: 101.101.101.101 went from Active to OpenSent
*Mar 1 00:36:08.335: BGP: 101.101.101.101 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 00:36:08.347: BGP: 101.101.101.101 send message type 1, length (incl. header) 45
*Mar 1 00:36:08.391: BGP: 101.101.101.101 rcv message type 1, length (excl. header) 26
*Mar 1 00:36:08.395: BGP: 101.101.101.101 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 00:36:08.395: BGP: 101.101.101.101 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 00:36:08.399: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 00:36:08.399: BGP: 101.101.101.101 OPEN has CAPABILITY code: 1, length 4
*Mar 1 00:36:08.403: BGP: 101.101.101.101 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 00:36:08.403: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:36:08.407: BGP: 101.101.101.101 OPEN has CAPABILITY code: 128, length 0
*Mar 1 00:36:08.407: BGP: 101.101.101.101 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 00:36:08.411: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:36:08.411: BGP: 101.101.101.101 OPEN has CAPABILITY code: 2, length 0
*Mar 1 00:36:08.415: BGP: 101.101.101.101 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 101.101.101.101 rcvd OPEN w/ remote AS 101
*Mar 1 00:36:08.419: BGP: 101.101.101.101 went from OpenSent to OpenConfirm
*Mar 1 00:36:08.419: BGP: 101.101.101.101 went from OpenConfirm to Established
*Mar 1 00:36:08.419: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Up
BGP Message Types
Open - Used to establish a neighbor relationship and exchange basic parameters, including ASN and MD5 authentication values.
Keepalive - Sent on a periodic basis to maintain the neighbor relationship. The lack of receipt of a Keepalive message within the negotiated Hold timer causes BGP to bring down the neighbor connection.
Update - Used to exchange PAs and the associated prefix/length (NLRI) that use those attributes.
Notification - Used to signal a BGP error; typically results in a reset to the neighbor relationship.
BGP neighborships fail when the underlying TCP connection fails.
TCP uses a concept called a socket, which consists of a local TCP port number and an IP address.
That IP address must be associated with a working interface (an interface whose state is line status up, line protocol up, per the show interfaces command).
If the interface whose IP address is used by BGP were to fail, then the TCP socket would fail, closing the TCP connection. As a result, the BGP neighborship can only be up when the associated interfaces also happens to be up.
One option would be to configure two neighbor commands on each router, one for each of the neighbor’s interface IP addresses - big bandwidth and memory consumption.
The preferred option, which uses loopback interfaces as the TCP connection endpoints, solves the availability problem while avoiding the extra overhead.
The two routers each configure a loopback interface and IP address, and use those loopback IP addresses as the source of their single BGP TCP connection.
If one of the multiple links fails, the loopback interface does not fail. As long as the two routers have working routes to reach each other’s loopback IP addresses, the TCP connection does not fail.
Configuring eBGP peers to use a loopback interface IP address with BGP requires several steps, as follows:
Step 1. Configure an IP address on a loopback interface on each router.
Step 2. Tell BGP on each router to use the loopback IP address as the source IP address 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 at 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.
Step 5. Configure eBGP multihop using the neighbor... ebgp-multihop hops command. This command defines the TTL that the router will use when creating the BGP packets.
The fifth configuration step for using loopback IP addresses with eBGP peers refers to a feature called eBGP multihop. By default, when building packets to send to an eBGP peer, IOS sets the IP Time-To-Live (TTL) field in the IP header to a value of 1.
With this default action, the eBGP neighborship fails to complete when using loopback interface IP addresses.
Let's consider routers R1 and R101 and configure all the above options (steps):
R1(config)#interface loopback 1
*Mar 1 00:02:23.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#ip route 101.101.101.101 255.255.255.255 201.1.1.2
R101(config)#interface loopback 101
*Mar 1 00:02:49.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R101(config-if)#ip address 101.101.101.101 255.255.255.255
R101(config)#ip route 1.1.1.1 255.255.255.255 201.1.1.1
R1#ping 101.101.101.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 101.101.101.101, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms
R101#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/52 ms
Now the BGP configuration (+ MD5 authentication):
R1(config)#router bgp 100
R1(config-router)#neighbor 101.101.101.101 remote-as 101
R1(config-router)#neighbor 101.101.101.101 update-source loopback 1
R1(config-router)#neighbor 101.101.101.101 ebgp-multihop 2
R1(config-router)#neighbor 101.101.101.101 password ccnp
R1(config-router)#
*Mar 1 00:06:19.835: %TCP-6-BADAUTH: No MD5 digest from 101.101.101.101(179) to 1.1.1.1(55651) (RST)
R101(config)#router bgp 101
R101(config-router)#neighbor 1.1.1.1 remote-as 100
R101(config-router)#neighbor 1.1.1.1 update-source loopback 101
R101(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
R101(config-router)#neighbor 1.1.1.1 password ccnp
R1(config-router)#
*Mar 1 00:08:11.431: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Up
R101(config-router)#
*Mar 1 00:08:12.883: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 4 4 1 0 0 00:01:07 0
R101#show ip bgp summary
BGP router identifier 101.101.101.101, local AS number 101
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 3 3 1 0 0 00:00:55 0
Note: The Neighbor column lists the IP address as defined on the local router’s neighbor command and not the neighbor’s BGP RID.
Note: The State/PfxRcd column either lists the BGP neighbor state or the number of prefixes received (PfxRcd) from that neighbor.
A numeric value under this heading implies a neighbor state of established, because the peers must be in established state before Updates can be sent. If the peer is not in an established state, the value in this heading lists the text name of the current BGP state.
BGP Neighbor States
Idle - The BGP process is either administratively down or awaiting the next retry attempt.
Connect - The BGP process is waiting for the TCP connection to be completed. You cannot determine from this state information whether the TCP connection can complete.
Active - The TCP connection has been completed, but no BGP messages have been sent to the peer yet.
Opensent - The TCP connection exists and a BGP Open message has been sent to the peer, but the matching Open message has not yet been received from the other router.
Openconfirm - An Open message has been both sent to and received from the other router. The next step is to receive a BGP Keepalive message (to confirm all neighbor-related parameters matched) or BGP Notification message (to learn there is some mismatch in neighbor parameters).
Established - All neighbor parameters match, the neighbor relationship works, and the peers can now exchange Update messages.
More information about a neighbor can be seen using:
R1#show ip bgp neighbors 101.101.101.101
BGP neighbor is 101.101.101.101, remote AS 101, external link
BGP version 4, remote router ID 101.101.101.101
BGP state = Established, up for 00:10:11
Last read 00:00:10, last write 00:00:10, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 0
Keepalives: 12 12
Route Refresh: 0 0
Total: 13 13
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 1; dropped 0
Last reset never
External BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 1.1.1.1, Local port: 179
Foreign host: 101.101.101.101, Foreign port: 13302
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x10E064):
Timer Starts Wakeups Next
Retrans 13 0 0x0
TimeWait 0 0 0x0
AckHold 13 12 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 517553984 snduna: 517554258 sndnxt: 517554258 sndwnd: 16111
irs: 3069838838 rcvnxt: 3069839112 rcvwnd: 16111 delrcvwnd: 273
SRTT: 247 ms, RTTO: 663 ms, RTV: 416 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs, md5
IP Precedence value : 6
Datagrams (max data segment is 536 bytes):
Rcvd: 15 (out of order: 0), with data: 13, total data bytes: 273
Sent: 25 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 12, total data bytes: 273
We can further verify TCP socket state and details using:
R1#show tcp brief
TCB Local Address Foreign Address (state)
65CD8A58 1.1.1.1.179 101.101.101.101.13302 ESTAB
Cisco IOS provides a means to administratively disable any BGP neighbor. Using the debug ip bgp command, BGP messages and states can be viewed:
R1#debug ip bgp
R1(config)#router bgp 100
R1(config-router)#neighbor 101.101.101.101 shutdown
*Mar 1 00:33:37.235: BGPNSF state: 101.101.101.101 went from nsf_not_active to nsf_not_active
*Mar 1 00:33:37.239: BGP: 101.101.101.101 went from Established to Idle
*Mar 1 00:33:37.239: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Down Admin. shutdown
*Mar 1 00:33:37.239: BGP: 101.101.101.101 closing
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
101.101.101.101 4 101 28 28 0 0 0 00:02:07 Idle (Admin)
R1(config)#router bgp 100
R1(config-router)#no neighbor 101.101.101.101 shutdown
*Mar 1 00:36:08.247: BGP: 101.101.101.101 went from Idle to Active
*Mar 1 00:36:08.263: BGP: 101.101.101.101 open active, local address 1.1.1.1
*Mar 1 00:36:08.335: BGP: 101.101.101.101 went from Active to OpenSent
*Mar 1 00:36:08.335: BGP: 101.101.101.101 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 00:36:08.347: BGP: 101.101.101.101 send message type 1, length (incl. header) 45
*Mar 1 00:36:08.391: BGP: 101.101.101.101 rcv message type 1, length (excl. header) 26
*Mar 1 00:36:08.395: BGP: 101.101.101.101 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 00:36:08.395: BGP: 101.101.101.101 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 00:36:08.399: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 00:36:08.399: BGP: 101.101.101.101 OPEN has CAPABILITY code: 1, length 4
*Mar 1 00:36:08.403: BGP: 101.101.101.101 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 00:36:08.403: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:36:08.407: BGP: 101.101.101.101 OPEN has CAPABILITY code: 128, length 0
*Mar 1 00:36:08.407: BGP: 101.101.101.101 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 00:36:08.411: BGP: 101.101.101.101 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 00:36:08.411: BGP: 101.101.101.101 OPEN has CAPABILITY code: 2, length 0
*Mar 1 00:36:08.415: BGP: 101.101.101.101 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 101.101.101.101 rcvd OPEN w/ remote AS 101
*Mar 1 00:36:08.419: BGP: 101.101.101.101 went from OpenSent to OpenConfirm
*Mar 1 00:36:08.419: BGP: 101.101.101.101 went from OpenConfirm to Established
*Mar 1 00:36:08.419: %BGP-5-ADJCHANGE: neighbor 101.101.101.101 Up
BGP Message Types
Open - Used to establish a neighbor relationship and exchange basic parameters, including ASN and MD5 authentication values.
Keepalive - Sent on a periodic basis to maintain the neighbor relationship. The lack of receipt of a Keepalive message within the negotiated Hold timer causes BGP to bring down the neighbor connection.
Update - Used to exchange PAs and the associated prefix/length (NLRI) that use those attributes.
Notification - Used to signal a BGP error; typically results in a reset to the neighbor relationship.
Subscribe to:
Posts (Atom)