BGP – Using the next-hop-self command to provide Transit

img 566c808c8e2d3

yes, I see I spelled Colorado wrong.

In this topology:

 

Denver is AS1

Chicago to Colorado is AS 2

Virginia and everything to the right is AS3

 

First we configure our links with /30s, then I give denver a lo0 of 1.1.1.1 and Chicago a l0 of 2.2.2.2,

then configure eBGP between the AS with physical links. (Denver to Chicago, Colorodo to Virginia)

 

Then we configure the links and loopbacks of newyork 3.3.3.3, boston 4.4.4.4, colorodo 5.5.5.5

Since iBGP allows for a TTL of 255 we don’t need the multi-hop commands. We would need to increase the TTL if we were creating

eBGP sessions since their packet’s TTL is 1.

Then once that is configured, we configure OSPF or EIGRP between these routers that will have iBGP.

 

Then we configure a full mesh of iBGP with each router in the AS with the two commands:

Neighbor x.x.x.x remote-as 2

Neighbor x.x.x.x update-source lo0

 

The above will let us source the loopback of the current router to form a iBGP session since we run a IGP, we can use loopbacks that won’t ever go down since we have multiple paths!

Now the problem here becomes that Router New york, Colorado, and boston will open up their BGP tables, and see this…

img 566c809517cea

Obviously Colorado doesn’t have a ROUTE TO THIS!!! So it won’t ever be able to reach 1.1.1.1 of router Denver.

Now what we can do is tell router Chicago to make itself the next hop for it’s neighbors in its iBGP sessions.

From Chicago we do

Neighbor 2.2.2.2 next-hop-self

Neighbor 3.3.3.3 next-hop-self

 

Now when we look at the routing table we see…

img 566c80a59a1e6

 

Routers Newyork and Boston will get the above, and they have a route to 2.2.2.2 via OSPF so they can definitely cross into AS 1 to get to 1.1.1.0/24

 

Leave a comment