New to BGP?  This should definitely help!  We will connect R1/R2/R3 into the already existing BGP network.  We will go step by step through all of this together… me right along side of you in the YouTube in a lab environment, this blog giving you a step by step of what will happen in each YouTube… and also files for you to download.  🙂

Ready to rock and roll?  You are going to learn tons!

The Steps We Will Take Together

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

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

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

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

The Files

Sniffer Traces

R2_R20_BGP_not_coming_up.pcap

R3_R30_not_coming_up.pcap

Configs: Configs from a 2018 Class I Taught

---

Time to Play and Learn 

Show and Tell #1: eBGP neighbor R2 with R20

Time: 13 min, 49 seconds

Sniffer: R2_R20_ipv4_ipv6_neighbor_startup.pcap

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

SPOILERS:
First we will configure iBGP peers between R2 and R3.  The iBGP neighbor will  come up.

• 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.  Again for 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 R3 with R30 with IPv4 and IPv6

Time: 14 min, 10 seconds

Sniffer Trace: R3_R30_ipv4_ipv6_neighbor_startup.pcap

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 hold time 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

SPOILERS: We will see while we added “next-hop-self” to the config of R2 towards R3 on the iBGP IPv4 neighbor statement and the iBGP IPv6 neighbor statement… that we did not do it in the reverse direction. What does this mean?

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

SPOILER: Now that R2 and R3 have the IPv4 and IPv6 internet addresses in their RIB…. we will try to ping both of them from R2.  We these pings will not be successful.  We will jump over to the Internet router see if the ICMP echo is making it.  On the Internet router  we have debugs on for ICMP and see this router attempting to respond with 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.

Hope you had tons of fun and learned lots!   BGP is awesome!  Keep learning!

---

*Additional Note: This blog originally posted in 2016.  It was updated and rewritten in March of 2019.