Why the route is valid () although the next-hop is not reachable?
what is the benefit of () symbol if the route is not reachable?
Which example are you referring to? Could you paste the output of the console here?
in this example:
R1#show ip bgp BGP table version is 1, local router ID is 192.168.12.1 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 * i18.104.22.168/24 192.168.23.3 0 100 0 3 i
The next-hop is not reachable,however, the route is valid.
it doesn’t make sense to put * and mark the route as valid if the next-hop is not reachable
19 posts were merged into an existing topic: BGP Next Hop Self
If there are multiple routers in IBGP is it necessary to configure next hop self on all IBGP routers?
Many thanks for your question. It is not necessary to configure next-hop-self on all iBGP routers and can have undesirable results. Any time we configure this we are modifying the original routes and modifying routes should always be done with care. Even better we try to avoid the need to modify routes by appropriate design choices.
Next hop self is one possible solution if a router receiving the unmodified route would be unable to understand how to reach the specified next hop. Although we can modify the route in BGP, a common alternative is to provide the router with an additional piece of information about how to reach the specified next-hop, for example providing a static route to that next hop or having another routing protocol (such as OSPF) operating more locally sharing information about exit points from your network.
If we apply next hop self by default a common issue is that traffic will flow but follow a sub-optimal path such as looping via a transit AS (it might be some remote branch site) rather than taking a more direct route with more bandwidth available. Connectivity can feel “slow” but not broken in this case.
So you have several options you can design into your network. Have fun choosing!
Ok I was working through the first part above. I created my own GNS3 lab to follow.
I got to the part where you state that you can just add the network 22.214.171.124 mask 255.255.255.0 to R2 to allow R1 to see the network. Sure enough this worked.
See below a picture of my lab its the same except I used 126.96.36.199 for my loopback instead of 188.8.131.52 and I also used one different interface on R2 but that was just mistake on my part that did not effect the lab so I left it.
My question was even though all the BGP networks and routes show up I still cannot ping the address of 184.108.40.206 from R1 to R3. Why is that? can you not ping over BGP? how can you not ping over it but the network traffic and routes work just fine?
Should they not have had IGP or static routes underneath the BGP or was it not needed because both IBGP routers are directly connected and then the R3 and R2 are connected directly over EBGP. if I run a capture you can tell the IP are getting there but just no reply and that’s because R3 does not know how to get back to R1 which makes sense as there is no IGP or static route. However, back to the question in bold about how come BGP can get back and forth but the ping cannot.
Sure enough if I add a static route the ping works so its just as I said above.
after adding static route:
So if this was a real world scenarios for an ISP it does not seem like BGP could help with any transit data because it certainly didn’t help with the ping. So is this lab an incomplete lab that is not really a working model because there is no underlying routing protocols or static routes?
In other words it seems to me that BGP lies to us when it says its connected because if it was connected we should be able to ping. OH well I am getting off topic maybe when you answer my question in bold it will explain everything.
wireshark after I added static route:
I went ahead and removed the static route to watch the wireshark traffic. I still see traffic but I just have to wonder if any payload data would be transmitted over BGP for example SIP, or IP traffic regular PC stuff. Why would ICMP(pings) be blocked but the rest of the traffic make it or would none of the traffic make it and just the BGP and management traffic only be transmitted??? Which if that was the case then BGP really does nothing but send its own crap over the network which I don’t see how that helps move data over the internet.
I have been just sitting and watching wireshark racking my brain. I finally highlighted all the Internet p[rotocol version 4, which should be the IP correct? all of the traffic is just the 192.168.23.0 /24 network nothing from the 192.168.12.0 /24 network.
That tells me the following if we don’t see any IP traffic from the 192.168.12.0/24 network that means no payload or transit data would ever get to us from the 192.168.12.0 /24.
Maybe I am wrong but it seems to me that BGP then cannot work without underlying routing protocol or static route because you would never receive information from another subnet that was not directly connected.
So if John Smith on his PC was on 192.168.12.0/12 and he was trying to get to the internet which was the 192.168.23.0 /24 network he would never reach it. which makes bgp worthless without a IGP or static route of some type? correct? Even the BGP its receiving is only from the 192.168.23.0 /24 network.
I setup a wireshark on the IBGP link between R1 and R2 and I don’t even see BGP keep alives there:
I am unsure why there are no BGP keep alives between R1 and R2.
wait I see why… there is no network command on R1, or R2 its on R3 only. Let me add one to the other two and test it.
! router bgp 12 no synchronization bgp log-neighbor-changes neighbor 192.168.12.1 remote-as 12 neighbor 192.168.12.1 next-hop-self neighbor 192.168.23.3 remote-as 3 no auto-summary ! R2# ----------------------------------------------------- ! router bgp 12 no synchronization bgp log-neighbor-changes neighbor 192.168.12.2 remote-as 12 no auto-summary ! R#1 ------------------------------------------------------- ! router bgp 3 no synchronization bgp log-neighbor-changes network 220.127.116.11 mask 255.255.255.0 neighbor 192.168.23.2 remote-as 12 no auto-summary ! R3#
Ok maybe NEVER MIND… when I added the network 192.168.12.0 mask 255.255.255.0 command to R2 I can now ping 18.104.22.168 on R3.
So the problem was me not BGP. BGP is behaving normally it will work with traffic as the ping worked… I just had not advertised the 192.168.12.0 /24 through BGP.
So I just have to ask this how does the BGP 22.214.171.124 /24 route show up in R1 BGP table even though I could not previously ping it? The other stuff now makes sense but that question remains.
Oh and a second question. How come I don’t see BGP Keep alives betgween R1 and R2 on the IBGP side and I do see them between R2 and R3 which is a EBGP connection. does IBGP not use keep alives. not sure what the TCP are for I guess just “ACK”?
It’s nice to see how you are working through the problem and we can “read your thoughts” along the way.
So, having answered your own original question, here’s the question that I’ll try to answer:
You must remember one of the fundamental laws of routing: If a route is successful in one direction, it does NOT mean that it will be successful in the other. So R3 was able to communicate with R2 and R1 the route to the 126.96.36.199 network. So it is possible for R1 to reach R3. This is the perspective or R1 since there is a route from R1 to 188.8.131.52. However, if you looked at the routing table of R3 (which you did) you will see that there is no route back to R1 without the appropriate
So looking at the routing table in R1 only shows you that R1 can reach R3. It says nothing about R3 reaching R1. In order to determine that you’ll have to look at the routing table on R3.
I hope this has been helpful!
So I can apply that rule to routes? Meaning as long as it can get there it will be added just not reachable because it knows how to get there but not the way back.
That does make perfect sense…gosh… I should have thought about that or at least posed it as a question. I was thinking that it probably had to do with some rule I had learned at some point about TCP/IP and traffic movement but just didn’t think of what was right in front of me. I hate when I do that but that happens a lot lol…
Ok now that makes sense and I can put it in a nice little box and label it lol… thanks!
any thoughts on this ? Even I am wondering why it shows as valid route ?
Thanks for indicating this. The * indicates that it is a valid route and that BGP is able to use it. However, in this case the next-hop is not reachable, so it should not be valid. I will let @ReneMolenaar know about this…
When you run iBGP with multiple nodes we should use IGP protocols to advertise prefixes between the iBGP nodes since iBGP does not carry forward the prefixes to another peer when It was learned from another neighbor. please correct me if I’m wrong.
An iBGP neighbour relationship can form between any BGP routers even if they are not directly connected. The only prerequisite is that there is a routed path between the IP addresses of the interfaces through which the relationship is formed.
Now the routed path can be established either via IGP or static routing. iBGP cannot be used because it requires the routing to form a neighbor relationship. It’s kind of like the chicken and the egg. iBGP cannot create a route for itself to create a neighbor relationship because it has no neighbor relationship to create it with.
I hope this has been helpful!
Does eBGP change the next hop ip address to itself? or not the same as iBGP does?
In an external BGP (eBGP) session, by default, the router does indeed change the next hop attribute of a BGP route (to its own address) when the router sends out a route. This behaviour can be changed however using the BGP Next Hop Unchanged feature. This is a command that is issued when defining a BGP neighbour. An example of this implementation is:
Router(config-router-af)# neighbor 10.0.0.100 next-hop-unchanged
I hope this has been helpful!
Yeah, so to summarise:
Learned from eBGP -> Advertise to eBGP -> Next-hop-self automatic
Learned from eBGP -> Advertise to iBGP -> “Next-hop-self” required
Learned from iBGP -> Advertise to iBGP -> “Next-hop-self all” required
Why IBGP speaking router by default does not change next hop to its ibgp peer
When routes are being exchanged between iBGP peers, the next hop IP address used by default is that of the router in an external AS. iBGP will not provide a next hop address of an iBGP peer. This is because within an autonomous system, it is assumed that there are routing protocols present that will allow for internal routing. The primary purpose of BGP in general is to find routes to other autonomous systems and not to route within an AS. So, a router will get a next hop IP address of the next eBGP peer because it is assumed that routing information to reach that is already available.
Now if you choose to use iBGP to route within your autonomous system, then of course you can do that, but you will need the “next hop self” command/configuration.
I hope this has been helpful!
Aside from this scenario, Is there other scenario that we can use BGP Next Hop Self?
What is the best practice to implementing BGP Next Hop Self?
The next hop self feature is used primarily for this purpose, to allow iBGP routers to change the next hop IP address in order avoid potential reachability issues.
A slightly different scenario that comes to mind where BGP next hop self is used is when you have two internet routers running eBGP with their ISPs and iBGP between them. If the next hop self command is not implemented, then each iBGP neighbour will have the eBGP ISP as the next hop for some networks, something that you may not want for your network. The principle is the same, the scenario is somewhat different.
Best practice for using next hop self is to use it whenever an internal peer must see the iBGP peer as the next hop rather than the eBGP peer to which it may not have a route. Now you could have an IGP provide the route to that peer, however, because it is outside of the AS, it is not ideal. IGPs should function only within an AS and have only BGP operate on an interAS basis.
I hope this has been helpful!