The Hebe-jebes (or He-B-GPs): Understanding the Roles of EBGP, IBGP and an IGP Using Lab 7-4, IBGP, Next Hop and Synchronization Rick Graziani Cabrillo

The Hebe-jebes (or He-B-GPs): Understanding the Roles of EBGP,

IBGP and an IGPUsing Lab 7-4, IBGP, Next Hop and Synchronization

Rick GrazianiCabrillo [email protected]

©

STEAL MY STUFF!

Username = ciscoPassword = perlman

Topology

©

Topology• ITA routers need to

receive IPv4 networks from both ISPs.

• SanJose1 and SanJose3 will only include ITA networks 172.16.2.0/24 and 172.16.4.0/24 in its BGP. updates to the ISP routers.

• Both ISPs need to be able to reach ITA LANs

EIGRP

©

Configuring EIGRP

SanJose1(config)# router eigrp 1SanJose1(config-router)# eigrp router-id 1.1.1.1SanJose1(config-router)# network 172.16.0.0SanJose1(config-router)# network 172.17.0.0



• Loopback interfaces are also advertised.

• Beginning with IOS 15, the default is

no auto-summary• What is the role of an IGP (EIGRP)?

©

Role of EIGRP• Provides complete

reachability for ITA routers within the AS.

• Example, for BGP purposes…

• R4 has a route in its routing table to reach the serial interface on R2 and …

• R2 has a route in its routing table to reach the serial interface on R4

EBGP

©

Configuring EBGP

ISP1(config)# router bgp 65100ISP1(config-router)# bgp router-id 1.0.0.0ISP1(config-router)# network 10.1.0.0 mask 255.255.0.0ISP1(config-router)# neighbor 192.168.1.2 remote-as 65000

SanJose1(config)# router bgp 65000SanJose1(config-router)# bgp router-id 1.1.1.1SanJose1(config-router)# neighbor 192.168.1.1 remote-as 65100SanJose1(config-router)# neighbor 172.17.4.1 remote-as 65000 !IBGPSanJose1(config-router)# neighbor 172.17.4.1 update-source Loopback0 !IBGPSanJose1(config-router)# network 172.16.2.0 mask 255.255.255.0

• What is the role of an EBGP?• Share network/prefix information

between AS’s.

©

Configuring IBGP

SanJose1(config)# router bgp 65000SanJose1(config-router)# bgp router-id 1.1.1.1SanJose1(config-router)# neighbor 192.168.1.1 remote-as 65100SanJose1(config-router)# neighbor 172.17.4.1 remote-as 65000SanJose1(config-router)# neighbor 172.17.4.1 update-source Loopback0SanJose1(config-router)# network 172.16.2.0 mask 255.255.255.0

SanJose3(config)# router bgp 65000SanJose3(config-router)# bgp router-id 3.3.3.3SanJose3(config-router)# neighbor 172.17.2.1 remote-as 65000SanJose3(config-router)# neighbor 172.17.2.1 update-source Loopback0SanJose3(config-router)# network 172.16.4.0 mask 255.255.255.0

• What is the role of an IBGP?• Share network/prefix information learned

from EBGP to IBGP routers in the same AS.• Note: Internal networks are also shared but

may not be needed to be reached via IBGP because of IGP (EIGRP).

• Peering via loopbacks allow multi-path reachability

©

Examining SanJose1’s BGP Table

SanJose1# show ip bgp <codes omitted>

Network Next Hop Metric LocPrf Weight Path *> 10.1.0.0/16 192.168.1.1 0 0 65100 i *> 172.16.2.0/24 0.0.0.0 0 32768 i r>i 172.16.4.0/24 172.17.4.1 0 100 0 iSanJose1#SanJose1# show ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches172.16.4.0/24 172.17.4.1 Higher admin distance n/aSanJose1#

• What does BGP know and is it reachable?• IBGP has an AD of 200• EIGRP has an AD of 90

< Reachable via next-hop

< (r) RIB failure, (i) learned via IBGP

< 0.0.0.0 indicates originating this route

©

Examining SanJose1’s Routing Table

SanJose1# show ip route<Only BGP and EIGRP routes are shown>

10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [20/0] via 192.168.1.1, 00:14:14 172.16.0.0/16 is variably subnetted, 7 subnets, 3 masksD 172.16.1.4/30 [90/2681856] via 172.16.1.2, 00:30:41, Serial0/0/1D 172.16.3.0/24 [90/2172416] via 172.16.1.2, 00:30:41, Serial0/0/1D 172.16.4.0/24 [90/2684416] via 172.16.1.2, 00:29:42, Serial0/0/1 172.17.0.0/16 is variably subnetted, 4 subnets, 2 masksD 172.17.3.0/24 [90/2297856] via 172.16.1.2, 00:30:41, Serial0/0/1D 172.17.4.0/24 [90/2809856] via 172.16.1.2, 00:29:42, Serial0/0/1SanJose1# ping 10.1.0.1Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:!!!!!

• What does the routing table show us?

EBGP EIGRP

Examine and troubleshoot IBGP next hop reachability on SanJose3

©

Examining SanJose3’s Routing Table

SanJose3# show ip route<Only BGP and EIGRP routes are shown>

172.16.0.0/16 is variably subnetted, 7 subnets, 3 masksD 172.16.1.0/30 [90/2681856] via 172.16.1.5, 01:00:03, Serial0/0/0D 172.16.2.0/24 [90/2684416] via 172.16.1.5, 01:00:03, Serial0/0/0D 172.16.3.0/24 [90/2172416] via 172.16.1.5, 01:00:03, Serial0/0/0 172.17.0.0/16 is variably subnetted, 4 subnets, 2 masksD 172.17.2.0/24 [90/2809856] via 172.16.1.5, 01:00:03, Serial0/0/0D 172.17.3.0/24 [90/2297856] via 172.16.1.5, 01:00:03, Serial0/0/0SanJose3#

• Why doesn’t SanJose3 have the 10.1.0.0/16 prefix from SanJose1 in its routing table? It’s IBGP peering with SanJose1…

• Notice 192.168.1.0/30 is NOT in the routing table either.

EIGRP

Loopbacks

?

©

SanJose3# show ip bgp<Codes omitted>

Network Next Hop Metric LocPrf Weight Path * i 10.1.0.0/16 192.168.1.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i *> 172.16.4.0/24 0.0.0.0 0 32768 iSanJose3#

• Why doesn’t SanJose3 have the 10.1.0.0 prefix from SanJose1 in its routing table?

• Remember, prefixes learned via EBGP are advertised into IBGP with the next-hop address unchanged.

• SanJose3 needs to be able to reach the next hop or the route is not added to the routing table.

• Solutions: • Advertise next-hop (192.168.1.0) AS 65000 • SanJose1 modifies makes itself the next-hop

when advertising EBGP routes using IBGP

EIGRP

?



< NOT reachable because next-hop is not in routing table

Next hop

Examining SanJose3’s BGP Table

©

Next-hop-self

SanJose1(config)# router bgp 65000SanJose1(config-router)# neighbor 172.17.4.1 next-hop-self

SanJose3(config)# router bgp 65000SanJose3(config-router)# neighbor 172.17.2.1 next-hop-self

• SanJose1 will use it’s loopback0 address as the next hop address in its BGP updates

• SanJose3 will use it’s loopback0 address as the next hop address in its BGP updates

©

Re-examining SanJose3’s BGP Table

SanJose3# show ip bgp<Codes omitted>

Network Next Hop Metric LocPrf Weight Path *>i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i *> 172.16.4.0/24 0.0.0.0 0 32768 iSanJose3#

• Notice that the next hop address has been changed to SanJose1’s loopback0 address 172.17.2.1 which is reachable because it being advertised in EIGRP updates from SanJose1.

EIGRP

?



< Reachable because new next-hop is in routing table

Next hop

©

Re-examining SanJose3’s Routing Table

SanJose3# show ip route bgp

10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:03:17SanJose3#

• SanJose3 installs the 10.1.0.0 prefix learned from SanJose1.

• Is 10.1.0.0 reachable?

EIGRP

?

©



10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:03:17SanJose3#SanJose3# ping 10.1.0.1 Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:U.U.USuccess rate is 0 percent (0/5)SanJose3#

• Nope.• Maybe because SanJose3 is not

advertising the source address (172.16.1.4/30) of the ping?

• Remember, ITA is only advertising 172.16.2.0/24 and 172.16.4.0/24.

©


SanJose3# show ip route bgp<Only BGP routes are shown>

10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:03:17SanJose3#SanJose3# ping 10.1.0.1 source gig 0/0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:U.U.USuccess rate is 0 percent (0/5)SanJose3#

• Nope.• Maybe the problem lies with

SanJose2?

It’s not you, it’s me.

Examine the behavior of BGP synchronization being disabled

©

Re-examining SanJose3’s BGP and Routing Table

SanJose3# show ip bgp Network Next Hop Metric LocPrf Weight Path *>i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i *> 172.16.4.0/24 0.0.0.0 0 32768 iSanJose3# show ip route bgp

10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:03:17SanJose3# ping 10.1.0.1 source gig 0/0U.U.USanJose3#

• SanJose3 has the 10.1.0.0 in its BGP and IP routing tables because it learned the route via IBGP from SanJose1 and …

• It now has a valid next hop address to SanJose1 for the route.

• But 10.1.0.0 is unreachable.

©

Examining SanJose2’s BGP and Routing Table

SanJose2# show ip route 10.1.0.0

SanJose2#

• SanJose2 does not have any knowledge of the 10.1.0.0/16 network.

©

Examining SanJose2’s BGP and Routing Table



• SanJose3 still has a IBGP route for this network because the default BGP behavior is no synchronization.

• Beginning with IOS 12.2(8)T, the default BGP behavior is no synchronization.

• The BGP synchronization rule states that a router will not include in its routing table nor advertise routes learned by IBGP unless that route is directly connected or learned from an IGP.

I am using NO synchronization by default. I have an IBGP route

to 10.1.0.0 and even if my routing table doesn’t have an

IGP (EIGRP) route, I will include the route in my routing table.

And I would send this route to ISP2.

IGP (EIGRP) =>IBGPNOT included in routing table

©

Enable Synchronization

SanJose3(config)# router bgp 65000SanJose3(config-router)# synchronization

SanJose3# show ip bgp Network Next Hop Metric LocPrf Weight Path * i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i *> 172.16.4.0/24 0.0.0.0 0 32768 iSanJose3# show ip route bgpSanJose3#

• With synchronization enabled, SanJose3 will not include the BGP route to 10.1.0.0/16 in its routing table unless it already knows about it via EIGRP.

• If SanJose3 had the 10.1.0.0/16 network in its IP routing table as an EIGRP route, it would would mean other routers in the domain, SanJose2, would most likely have this route also.

I have an IBGP route to 10.1.0.0 but I do not have an

IGP (EIGRP) route in my routing table.

So, I will NOT include it in my routing table because I am using “synchronization”.

And, I will not send this route to ISP2.

©

Back to No Synchronization

SanJose3(config)# router bgp 65000SanJose3(config-router)# no synchronization



• Re-enable default, no synchronization

I am using NO synchronization again. I have an IBGP route to 10.1.0.0 and

even if my routing table doesn’t have an IGP (EIGRP) route, I will include the route

in my routing table.And I would send this route

to ISP2.

Hey, I’m still clueless… help!

Configure and verify full-mesh IBGP on all ITA transit routers

©

Two OptionsBGP

EIGRP

EIGRP

BGP

BGP

• Option 1: Redistribute BGP routes into IGP (EIGRP)• Undesirable• All routers in ITA would receive these

routes.• We only need our transit routers to have

these routes.• Option2: Enable full-mesh IBGP - on all routers

in transit path.BGP

IBGP

©

Configure full-mesh IBGP on all transit routers

SanJose2(config)# router bgp 65000SanJose2(config-router)# bgp router-id 2.2.2.2SanJose2(config-router)# neighbor 172.17.2.1 remote-as 65000SanJose2(config-router)# neighbor 172.17.2.1 update-source Loopback0SanJose2(config-router)# neighbor 172.17.4.1 remote-as 65000SanJose2(config-router)# neighbor 172.17.4.1 update-source Loopback0

SanJose1(config)# router bgp 65000SanJose1(config-router)# neighbor 172.17.3.1 remote-as 65000SanJose1(config-router)# neighbor 172.17.3.1 update-source Loopback0SanJose1(config-router)# neighbor 172.17.3.1 next-hop-self

SanJose3(config)# router bgp 65000SanJose3(config-router)# neighbor 172.17.3.1 remote-as 65000SanJose3(config-router)# neighbor 172.17.3.1 update-source Loopback0SanJose3(config-router)# neighbor 172.17.3.1 next-hop-self

• Remember, default is no synchronization IBGP

©

Peering Relationships

ISP1# show bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State PfxRcd192.168.1.2 4 65000 20 21 18 0 0 00:14:25 2

SanJose1# show bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State PfxRcd172.17.3.1 4 65000 18 18 4 0 0 00:12:12 0172.17.4.1 4 65000 19 18 4 0 0 00:12:12 1192.168.1.1 4 65100 18 18 4 0 0 00:12:12 1

SanJose2# show bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State PfxRcd172.17.2.1 4 65000 20 20 9 0 0 00:14:30 2172.17.4.1 4 65000 68 66 9 0 0 00:53:14 1

SanJose3# show bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State PfxRcd172.17.2.1 4 65000 20 22 10 0 0 00:14:35 2172.17.3.1 4 65000 66 68 10 0 0 00:53:19 0

IBGP

©

Examining SanJose2 – No longer clueless

SanJose2# show ip bgp

Network Next Hop Metric LocPrf Weight Path *>i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i r>i 172.16.4.0/24 172.17.4.1 0 100 0 i


10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:06:53

I now have a route via IBGP to 10.1.0.0.

I don’t have to be the missing link any more!

©

Let’s look at SanJose3 again

SanJose3# show ip bgp Network Next Hop Metric LocPrf Weight Path *>i 10.1.0.0/16 172.17.2.1 0 100 0 65100 i r>i 172.16.2.0/24 172.17.2.1 0 100 0 i *> 172.16.4.0/24 0.0.0.0 0 32768 iSanJose3# show ip route bgp

10.0.0.0/16 is subnetted, 1 subnetsB 10.1.0.0 [200/0] via 172.17.2.1, 00:54:55SanJose3# SanJose3# ping 10.1.0.1 source gig 0/0!!!!!SanJose3#

ISP1# ping 172.16.4.1 source gig 0/0!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 80/83/84 msISP1#

Documents

The Hebe-jebes (or He-B-GPs): Understanding the Roles of EBGP, IBGP and an IGP Using Lab 7-4, IBGP, Next Hop and Synchronization Rick Graziani Cabrillo