[ BGP Router c in Remote AS] --- [Router B non bgp router in local AS] ------ [Router A BGP router in local AS]
Router C in the Remote AS sees the next hop for a route we are advertising to it as an intneral router in our local AS, we want to change this so it sees the next hop as Router A, the BGP connected router in our AS.
Let me know if I can add any more.
Let me re-state the situation to see if I understand:
Router A is an eBGP peer with Router C, but they are separated by a non-BGP router. Router A is advertising a prefix to Router C, which for some reason is seeing the next hop as Router B. Is that correct? If so, I think something is already wrong. Router C, as an eBGP peer to Router A, should have Router A as the next hop in the BGP table. You would then then an IGP route or static route to recursively point to the actual next hop, which is router B.
From your description you have the opposite problem and I'm not sure why. Am I understanding the problem correctly?
Without configs, my best bet is that you haven't redistributed BGP into your IGP. You have to do that because router B doesn't know where any destinations are Alternatively, you need to run BGP on Router B.
This sounds like a weird setup, you need to draw the topology in order for us to debug the problem. The picture I've got in my mind suggests you are saying I want the internet table to go through a router that doesn't support the internet table (router b). So everything will be blackholed at router B because no routes are in the routing table. Do a quick #sh ip route to check.
As for the next hop issue, the rule for the next hop is this:
- When advertising networks to eBGP peers, set the next hop to yourself
- When advertising to iBGP peers, do not change the next hop address
This behavour can be adjusted by using a route-map on your neighbor statements to set the next-hop manually.
Thanks. Let me be a little more descriprtive than I have been.
It is not possible to run BGP on router B, this is why we have had to employ EBGP multi-hop. Ordinarily , I would have expected the remote end peer to see the next hop as our BGP routers loopback interface, but this is not the case. Looking at routes advertised to the remote end peer, it is seeing the same next hop to the advertised subnets as our advertising router sees them, and here lies the problem.
Any way arround this, or explanation as to why the remote end peer is seeing the next hop as an internal address ?
With eBGP multihop, the standard solution is to use static routes to make just the next-hop reachable. So Router C would create a static route that looks like this:
ip route [router A's BGP loopback] 255.255.255.255 [router B's interface]
This lets Router C do a recursive lookup for the nexthop and find that it should route those packets to Router B.
I apologize because I feel like I'm missing something. Are you saying that if you go to Router C and do "show ip bgp x.x.x.x" and look at a BGP route that came from router A, the next hop you see listed is an IP address on Router B that is not running BGP? That seems to be what you're saying and I'm confused about how that could be happening. An eBGP peer should be resetting the next-hop address to its own address before it advertises it to another eBGP peer. It sounds like you're saying that that isn't happening.
If you have a ebgp peering, your next hop should be always the ip address configured in the peer commands for ebgp routes. Next hop self changes the next hop for ibgp relationships, not for ebgp. If you want do this will have to apply a route map and set other next hop.
If neighbors are not directly connected, then the peering ip address should be learned some way, if not peering will not get established. Since this looks like you bgp peer works, this is not the problem.
If you execute a show ip bgp, you will see the bgp route table, show ip route should be more or less the same. The next hop for the bgp routes will be the peer neighbor, if you execute the show ip route x.x.x.x for that peer ip address, this should point to the network between your two peers.
If you have problems this is nothing related to your bgp configuration, this is something wrong in your igp between the peers. For example a redistribution from bgp to the igp that may cause a loop.
There is a case in which the EBGP neighbor will not set it self as the next hop when advertising routes to its EBGP peer, instead it will advertise the IP address of the originating router as the next hop, if the medium used to connect the EBGP peers and the originating router is a Multiaccess or Non Broadcast Multiaccess(NBMA) like the (Ethernet, and Frame Relay).
In your scenario if Router B (or any other router that originated the route) and the EBGP peers are connected to a common medium that is multiaccess like ethernet or NBMA like frame relay, and they all belong to the same subnet (say 188.8.131.52/24) so they all can reach each other directly, the EBGP router (say Router A) will set Router B as the next hop.
The reason for that is from BGP perspective it does not make sense to add an extra hop (which is Router A) for the remote EBGP peers ( Router C) to reach the originating router ( Router B), instead Router A will set Router B as the next hop this way Router C will send packets directly to Router B.
In some cases this could cause a problem, say you are using a frame relay in a hop and spoke scenario, where Router A is the hub and Router B,C are the spokes, so for Router C to reach Router B it has to use Router A, since Router C does not have a direct permanent virtual circuit (PVC) to Router B setting Router B as the next hop will cause packets to get lost .
To solve this problem use the command (next-hop-self) with the EBGP neighbor, this way Router A will be set as the next hop which will solve the problem.
Note: The (next-hop-self) can be used with the EBGP connections also.