Thursday, April 15, 2010

Configuring EBGP Peerings Without Using EBGP Multihop - With Little Bug Issue

O
***Click On Image For Better View***
Ok....I must say that while doing research and labing up this topic...I beat my head against the wall so many times yesterday....what else you would do ? When you know that you are following all the rules Cisco has suggested and your configuration is 100 % accurate. But things are not working as you expect them to work...

The challenge thrown by one of my friend was -> Hey....say you are asked to establish EBGP peering between two BGP speakers using loopback addresses; but you are not allowed to use " EBGP Multihop" command at all.

Hmmm...just think about it for a sec. As per standard "By default eBGP sessions can only be established between directly connected interfaces.  If you want to connect to a non-connected interface or to a non-connected neighbor, you have to use the eBGP-multihop feature."

So that means if two EBGP speakers are not connected back to back or peered using loopback; then we must use EBGP Multihop option otherwise neighborship will never be formed. Lets see if it's true.

Lets do the basic configuration and verify:

R1(config)#do sh ip int br | e unassign|do
Interface                  IP-Address      OK? Method Status     Protocol
Serial0/0                  12.12.12.1      YES manual up           up
Loopback0                11.11.11.11     YES manual up          up
Loopback1                1.1.1.1         YES manual up             up


R2(config)#do sh ip int br | e unassign|do
Interface                  IP-Address      OK? Method Status     Protocol
Serial1/0                  12.12.12.2      YES manual up           up
Loopback0                22.22.22.22     YES manual up          up
Loopback1                2.2.2.2         YES manual up             up
 

Now lets put static routes in order to establish basic connectivity between loopbacks of both routers:

R1(config)#do sh run | s ip route
ip route 22.22.22.22 255.255.255.255 Serial0/0 12.12.12.2

R2(config)#do sh run | s ip route
ip route 11.11.11.11 255.255.255.255 Serial1/0 12.12.12.1



Now lets do the basic BGP configuration without using "ebgp multihop"


R1(config)#do sh run | s router
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 22.22.22.22 remote-as 200
 neighbor 22.22.22.22 update-source Loopback0
 no auto-summary


R2(config)#do sh run | s router
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 11.11.11.11 remote-as 100
 neighbor 11.11.11.11 update-source Loopback0
 no auto-summary



Now Lets verify if peering has been established:


R1#sh ip bgp summ
BGP router identifier 11.11.11.11, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down 

22.22.22.22     4   200       0       0        0    0    0 never    Idle


As you can see the connection is still in "IDLE" state.


So lets see put "ebgp multihop" and see if neighborship is coming up:


R1(config)#router bgp 100
R1(config-router)#neighbor 22.22.22.22 ebgp-multihop

R2(config)#router bgp 200
R2(config-router)#neighbor 11.11.11.11 ebgp-multihop



R1(config-router)#
*Mar  1 00:40:12.439: %BGP-5-ADJCHANGE: neighbor 22.22.22.22 Up

R2(config-router)#
*Apr 14 08:13:40.191: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Up

R1#sh ip bgp summ
BGP router identifier 11.11.11.11, 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
22.22.22.22     4   200       7       6        1    0    0 00:02:57        0   


R2#sh ip bgp summ
BGP router identifier 22.22.22.22, local AS number 200
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4          100       7       7        1    0    0 00:03:27        0





Now BGP peering is up, lets advertise "Loopback 1" of both routers in BGP:

R1(config)#router bgp 100
R1(config-router)#net 1.1.1.0 mask 255.255.255.0



R2(config)#router bgp 200
R2(config-router)#net 2.2.2.0 mask 255.255.255.0





R1(config-router)#do sh ip route bgp
     2.0.0.0/24 is subnetted, 1 subnets
B       2.2.2.0 [20/0] via 22.22.22.22, 00:01:38



R2#sh ip route bgp
      1.0.0.0/24 is subnetted, 1 subnets
B        1.1.1.0 [20/0] via 11.11.11.11, 00:00:27


So this factor is confirmed that without using "ebgp multihop" this kind of scenario will not work by default.

Now challenge is to find the other ways to make it work.

After reading BGP command reference from Cisco website I found two more ways which could help in this situation:


1. "TTL Security" feature :

BGP Support for TTL Security Check

 2.  " Disable Connected Check"

Disable Connected Check Feature in BGP

 Ok...looks cool in reading, lets try this on command line:

R1(config-router)#no neighbor 22.22.22.22 ebgp-multihop 255

R2(config-router)#no neighbor 11.11.11.11 ebgp-multihop 255
R2(config-router)#do clear ip bgp *

R2(config-router)#do sh ip route bgp
Gateway of last resort is not set

R2(config-router)#



Now lets try "TTL Security Feature"


R1(config-router)#neighbor 22.22.22.22 ttl-security hops 2

R2(config-router)#neighbor 11.11.11.11 ttl-security hops 2





R1#sh ip bgp summ
BGP router identifier 11.11.11.11, local AS number 100
BGP table version is 2, main routing table version 2
2 network entries using 240 bytes of memory
2 path entries using 104 bytes of memory
3/1 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 772 total bytes of memory
BGP activity 11/9 prefixes, 12/10 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
22.22.22.22     4   200      94      90        2    0    0 00:04:34        1


R2#sh ip bgp summ
BGP router identifier 22.22.22.22, local AS number 200
BGP table version is 11, main routing table version 11
2 network entries using 240 bytes of memory
2 path entries using 104 bytes of memory
2/2 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 616 total bytes of memory
BGP activity 8/6 prefixes, 11/9 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
11.11.11.11     4          100      10      10       11    0    0 00:05:06        1





Ok So far looks like that prefixes has been exchanged, lets verify a little more:


R2#sh ip bgp
BGP table version is 11, local router ID is 22.22.22.22
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
*> 1.1.1.0/24       11.11.11.11              0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i



R2 looks perfectly cool, lets hop on to R1 for verification:


R1#sh ip bgp
BGP table version is 2, local router ID is 11.11.11.11
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
*> 1.1.1.0/24       0.0.0.0                  0            32768       i
2.2.2.0/24       22.22.22.22             0             0       200i    



Oops...R1 sees the prefix but don't mark it as best. Also I am keep getting following log message:


R1#
*Mar  1 01:50:43.799: BGP(0): no valid path for 2.2.2.0/24




Hmmm...config looks fine but not working as expected...Ok hold this thought for a while and lets try the " disable connected check" feature:


R1(config-router)#no neighbor 22.22.22.22 ttl-security hops 2
R1(config-router)#neighbor 22.22.22.22 disable-connected-check

R2(config-router)#no neighbor 11.11.11.11 ttl-security hops 2
R2(config-router)#neighbor 11.11.11.11 disable-connected-check



Now lets verify routing table to see if this is working as expected:


R1(config-router)#do sh ip ro b
     2.0.0.0/24 is subnetted, 1 subnets
B       2.2.2.0 [20/0] via 22.22.22.22, 00:00:07

R2(config-router)#do sh ip rou b
      1.0.0.0/24 is subnetted, 1 subnets
B        1.1.1.0 [20/0] via 11.11.11.11, 13:57:24



And sure enough we have our success moment :)


Now lets take this config off and try " TTL Security on different IOS"


Lets try 7200 IOS with same "TTL SECURITY" config:


R1(config-router)#do sh ver | i IOS
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.0(1)M, RELEASE SOF
TWARE (fc2)

R1(config-router)#do sh ip bgp
BGP table version is 3, local router ID is 11.11.11.11
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
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 2.2.2.0/24       22.22.22.22              0             0 200 i


R1(config-router)#do sh ip route b
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
B        2.2.2.0 [20/0] via 22.22.22.22, 00:11:55


R2(config-router)#do sh ver | i IOS
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.0(1)M, RELEASE SOF
TWARE (fc2)


R2(config-router)#do sh ip bgp
BGP table version is 5, local router ID is 22.22.22.22
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
*> 1.1.1.0/24       11.11.11.11              0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i



R2(config-router)#do sh ip ro b
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
B        1.1.1.0 [20/0] via 11.11.11.11, 00:13:57



R1(config-router)#do ping 2.2.2.2 so lo 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/82/180 ms



Hmmm...looks like IOS ver 15 helped us finally :)


Now lets hop back to same IOS with same "ttl security" config

R1(config-router)#do sh run | s r b
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 22.22.22.22 remote-as 200
 neighbor 22.22.22.22 ttl-security hops 2
 neighbor 22.22.22.22 update-source Loopback0
 no auto-summary

R2(config-router)#do sh run | s r b
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 network 2.2.2.0 mask 255.255.255.0
 neighbor 11.11.11.11 remote-as 100
 neighbor 11.11.11.11 ttl-security hops 2
 neighbor 11.11.11.11 update-source Loopback0
 no auto-summary


Now Lets turn of debugging to see if we can find some clue:

R2(config-router)#do debug ip bgp up
BGP updates debugging is on for address family: IPv4 Unicast
R2(config-router)#do clear ip bgp *
R2(config-router)#
*Mar  1 00:18:44.775: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Down User reset
*Mar  1 00:18:47.971: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Up
*Mar  1 00:18:48.111: BGP(0): 11.11.11.11 rcvd UPDATE w/ attr: nexthop 11.11.11.11, origin
 i, metric 0, path 100
*Mar  1 00:18:48.111: BGP(0): 11.11.11.11 rcvd 1.1.1.0/24
*Mar  1 00:18:48.115: BGP(0): no valid path for 1.1.1.0/24


ok...let me share something more...this IOS is again having same problem. Later I tried to see if " ebgp multihop" or " disable connected check" options can make it work. But no success so far.... so finally I saved my current config of "ttl security" and reloaded the routers...

And sure enough this time everything worked just fine.


Here are the IOS details:


R1(config-router)#do sh ver | i IOS
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T5, RELEASE S
OFTWARE (fc4)




Now I am not sure if this was a GNS bug or IOS bug...but will research on that...but finally I have big smile on my face because I learned something new again.



Further Readings:

http://www.networkworld.com/community/blog/clearing-some-misinformation-re-ebgp-multihop-and-ttl

Regards,
Deepak Arora

5 comments:

Deepak Chougule said...

Nice yar its good information for me i will try last 3-4 days now i understand thanks

Ashish said...

Deepak I think it is a bug in GNS3 as TTL-security should do the job of EBGB multihop as well (You cannot configure EBGP multihop and ttl-sec at the same time)

Anonymous said...

Deepak - Why would you choose one over the other? Any reasons, benefits of ttl-security v/s ebgp multihop?

Suddarshan said...

Deepak, I am working on CCIE R & S lab, which is upcoming Next year!!! Found your blog really usefull. Gr8 Job!!!!

Anonymous said...

different approach .. gud one .. i will try this in the lab .. very useful one ..