BGP Show and Tell: Beginners

BGP Show and Tell: Beginners

This blog is a weaving together of 5 YouTube videos.  To see a video just click on the diagram for that “Show and Tell” section.  It is a link to that specific YouTube video. Since it is quite possible that not every one of the 5 may be of interest to you. I have a “spoilers” section below each Show and Tell diagram describing exactly what will happen in that video and the video length.

THE START:

We start in the below environment with

  • R20 already eBGP peered with Internet and receiving prefixes
  • R30 already eBGP peered with Internet and receiving prefixes
  • R1, R2, and R3 are already OSPF neighbored
  • Link between R2 and R20 is already configured
  • Link between R3 and R30 is already configured

bgp_lab

The Steps

#1: eBGP neighbor up R2 and R20 with IPv4 and IPv6

#2: iBGP peer IPv4 and IPv6 between R2 and R3

#3: eBGP neighbor up R3 and R30 with IPv4 and IPv6

#4: Shut the Link Between R2 and R20

#5: Ping the IPv4 & IPv6 Internet Addresses from R1

The End

The end will be when R1 can successfully ping the AS40 IPv4 address 40.100.100.40 and the IPv6 address 2001:db8:40:40::40

The Files

PDF On Dropbox: bgp_lab.pdf

Sniffer Trace for Show and Tell #1: R2_R20_ipv4_ipv6_neighbor_startup.pcap

Sniffer Trace for Show and Tell #3: R3_R30_ipv4_ipv6_neighbor_startup.pcap


Show and Tell #1: eBGP neighbor up R2 and R20 with IPv4 and IPv6

Time: 13 min, 49 seconds

Sniffer: R2_R20_ipv4_ipv6_neighbor_startup.pcap

R2_R20_youtube

SPOILERS:
We will see that both IPv4 eBGP and IPv6 eBGP peering will not come up between R2 and R20 because R20 is has the wrong AS number configured for R2.

  • Configure R2 to eBGP peer with R20 via IPv4 address
  • See that the eBGP peer isn’t coming up
  • Notice that the physical interface on R2 going to R20 is admin down
  • No shut the interface
  • See that the eBGP peer is still not coming up
  • Notice in the logs on R2 that there is a BGP notification being received from R20 that R20 views that the peer is in the wrong AS
  • Go to R20 and see that the neighbor statement to R2 is configured to be AS 100
  • Fix this and change it to AS 10
  • Go back to R2 and see that the eBGP peer is up and we are receiving prefixes
  • Configure R2 to eBGP peer with R20 via IPv6 address
  • See that the eBGP IPv6 peer isn’t coming up
  • Notice in the logs on R2 that there is a BGP notification being received from R20 that R20 views that the peer is in the wrong AS
  • Go to R20 and see that the neighbor statement to R2 for eBGP IPv4 peering is configured to be AS 100
  • Fix this and change it to AS 10
  • Go back to R2 and see that the eBGP IPv6 peer is up and we are receiving prefixes

 


Show and Tell #2: iBGP peer IPv4 and IPv6 between R2 and R3

Time: 24 min, 47 seconds

R2_R3_youtube

SPOILERS:
First we will configure iBGP peers between R2 and R3.  Once it is up, we will see that R3 will not install any of the IPv4 prefixes that R2 learned from R20 and is advertising to R3.  We will see that it is because iBGP, by default, does not change the next hop IP address.  We will see this again in reference to R3 not installing any of the IPv6 prefixes that R2 learned from R20 and is advertising to R2.  This will be the same reason.

Since this YouTube is longer… I’ll break down some of the major time stamps for you.

  • Configure R2 and R3 to iBGP peer with each other via  IPv4 address
  • R3 sees the iBGP peer w/ R2 is up and show ip bgp summary on R3 shows R3 is learning 3 prefixes from R2  comes up (timestamp: 4min 42seconds in)
  • show ip route on R3 shows NO BGP routes in the RIB (timestamp: 5min 22seconds in)
  • Look at BGP best path and read that Routers will ignore “Paths for which the NEXT_HOP is inaccessible” and not take these paths into consideration for best path. (timestamp: 7min 11 seconds in)
  • Poke around and talk about what is happening and why
  • Go to R2 and configure the iBGP neighbor to R3 to have “next-hop-self” (timestamp: 11min 40 seconds in)
  • In R3 see that the BGP table shows now that there is a “>” (best path) indicator associated with the prefixes that R2 is advertising (timestamp: 12min 28 seconds in)
  • Rinse and repeat above but with IPv6 (timestamp: 14min 56 seconds in)

 

Show and Tell #3: eBGP neighbor up R3 and R30 with IPv4 and IPv6

Time: 14 min, 10 seconds

Sniffer Trace: R3_R30_ipv4_ipv6_neighbor_startup.pcap

R3_R30_youtube

SPOILERS: We will see that both IPv4 eBGP and IPv6 eBGP peering will not come up between R3 and R30 because R30 is configured to not accept the peering if the holdtime that R3 sends is less than 9 seconds.

  • Configure R3 to eBGP peer with R30 via IPv4 address and IPv6 address
  • See that neither eBGP peer (IPv4/IPv6) is coming up (timestamp: 4min 9 seconds in)
  • Notice that the physical interface on R3 going to R30 is admin down
  • No shut the interface (timestamp: 4min 52 seconds in)
  • Focusing right now on just the IPv4 eBGP peer — See that the eBGP peer is still not coming up
  • Notice in the logs on R3 that there is a BGP notification being received from R30 that R30 views that the peer has an “unacceptable hold timer” set. (timestamp: 5 min 47 seconds in)
  • Go to R30 and see that the IPv4 neighbor statement to R3 is configured with a “9” as the minimum allowed hold time (timestamp: 6 min 33 seconds in)
  • Go back to R3 and change the timers on BOTH the IPv4 and the IPv6 eBGP peer configs to 3 9. (timestamp: 7 min 56 seconds in)
  • On R3 see that the IPv4 eBGP peer is up and we are receiving prefixes (timestamp: 8 min 29 seconds in)
  • On R3 see that the IPv4 eBGP peer is up and we are receiving prefixes (timestamp: 8 min 45 seconds in)
  • At timestamp 8 min 59 seconds in spend some time looking at the BGP table for IPv4 and IPv6 and the prefixes R3 is receiving from R2 and R30. Noticed that it is the eBGP vs iBGP BGP Best Path Decision Making that makes the best path of the 2 the path R3 has via R30.

 


Show and Tell #4: Shut the Link Between R2 and R20

Time: 12 min, 49 seconds

R2_R20_youtube_shut

SPOILERS: We will see while we adding “next-hop-self” to the config of R2 towards R3 on the iBGP IPv4 neighbor statement and the iBGP IPv6 neighbor statement… we did not do it in the reverse direction.  So R2 will not install the prefixes (IPv4 and IPv6) that R3 learned from R30 and is advertising to R2.  The reason, will again, be because iBGP by default leaves the next-hop unchanged and R2 does not have the IPv4 or IPv6 subnet that is between R3 and R30 in its RIB.  Hence the next hop for those prefixes are “inaccessible”


Show and Tell #5: Ping the IPv4 & IPv6 Internet Addresses from R1

Time: 17 min, 41 seconds

ping-youtube

SPOILER: Now that R2 and R3 have the IPv4 and IPv6 internet addresses in their RIB…. we will try to ping them from R2. We will ping from R2 and get no success. Move to the Internet router where we have debugs on for ICMP.. and see this router doing an echo reply. But to an address it doesn’t have in its routing table. We will go back to R2 and R3 and do a redistribute of the OSPF into the BGP but for the loopbacks of R1, R2, and R3 only. We will go back to R2 and R3 and do an extended ping to the internet addresses sourcing the pings from the loopback. These will be successful. We will then move to R1 and try extended pings from there. This will not succeed because R1 doesn’t have the prefixes nor the default route in its IPv4 RIB or IPv6 RIB. We will fix this and then ping again. This time successfully.

Filed Under: BGP
  • Pingback: FishNet: BGP()

  • Mad_Prof Mad_Prof

    Hello Denise,

    Thanks for the great presentations. I would like if know if you can post the configuration and associated virl file.

    Thanks
    Ksudi

    • Denise “Fish” Fishburne

      🙂 I will have to hunt a little for them. Let me see.