BGP over static route

[Elopower123]

Hi,

I am trying to configure eBGP between two routers, the routers are not directly connected to each other but have reachablity via static routes. I have configured the bgp neighbor-ship between the two routers and it's up. On the routing table of the routers I have a route to the LAN of the other side via the BGP neighbor IP but I can't reach the LAN.

Please I need help in resolving this. 

[Giuseppe Larosa]

Hello @Elopower123 ,

have you configured

neighbor x.x.x.x ebgp-multihop 2  ?

in show ip bgp neighbor is the state established ?   Active is not a good state ( it is misleading I agree on this)

if the eBGP session is established there is a return route for devices on the remote LAN?

I mean if you try to ping a device on the remote LAN that has a default gateway that is not the router with which you have configured the eBGP session you can have issues.

For a successful ping you need to check also the return path.

Hope to help

Giuseppe

[Elopower123]

Hi Larosa,

I have configured the multi-hop command and the BGP state is established. And I'm trying to ping the LAN interface of the router at the other end. The ping responds as UUUUU

[Giuseppe Larosa]

Hello @Elopower123 ,

on the remote router under

router bgp <AS-number>

network 10.10.10.0 mask 255.255.255.0

You need to advertise in BGP the remote LAN IP subnet.

The U may mean there is an ACL blocking ICMP traffic. U= unreachable ACL or no route to host.

Hope to help

Giuseppe

[Elopower123]

Hello Larosa,

I advertised the LAN for each of the networks on their respective BGP configurations. I had to configure a null0 ip route to the LAN network on their routers before it showed up on the routing table of the remote side via BGP.

[Giuseppe Larosa]

Hello @Elopower123 ,

modern BGP uses

no auto-summary

and you need to advertise the subnets with their correct subnet masks as BGP looks for an exact match in the IP routing table.

You have likely used network commands without the mask option if you do so the classful mask is supposed and then you have added static routes to null0.

>> had to configure a null0 ip route to the LAN network on their routers before it showed up on the routing table of the remote side via BGP.

Be aware that if the subnet mask is the same of that of the remote LAN you are actually blackholing traffic = discarding packets with the static route to null0.

use the mask or netmask option in the network command to provide the correct mask and you will not need the static to null0 anymore.

Hope to help

Giuseppe

[Elopower123]

Hi Larosa,

The networks are now advertised with precise masks and I have removed the null0 routing. I can still see the remote LANs in my routing table but I still get an unreachable response.

Could this be because of the router sitting between the two peers? Perhaps the router is unable to send the packets to the remote peer destination because something else still needs to be done to bridge the gap.

[Jon Marshall · Accepted solution]

The router between the two peers will need to know how to route to the LAN subnets. 

If this was an MPLS VPN setup then the intermediate router(s) don't but this is not the case in your setup by the sounds of it. 

Jon

[Giuseppe Larosa · Accepted solution]

Hello @Elopower123 ,

@Jon Marshall is correct if there is a router on the path between the two eBGP peers it will need appropriate static routes configured to know how to send the traffic to the right and to the left,  because it is not taking part in the BGP routing exchange.

As noted the only exception would be in an MPLS environment where the internal routers do not perform IP routing but only MPLS label swapping.

Hope to help

Giuseppe

[Richard Burts]

If the issue is some intermediate router not having an appropriate route why is ping response unreachable and not timeout?

[Elopower123]

Hello Jon and Larosa,

It worked, I am now able to reach the remote LANs from either side.

I am very grateful for your time and help, thanks very much.

[paul driver]

Hello
Make sure those static routes for reachabilty are not default static routes otherwise the bgp peering will fail because default routes for peering are not supported in bgp due to its internal route lookup check
sh ip cef <bgp peering> samecable
sh ip route
telnet <bgp peering> 179

[Elopower123]

Hi Paul,

The peering has already been established and I even have a route for the remote LAN in my routing table. The route is advertised as being available via the remote peer IP. I don't know if the issue is because the remote peer IP is not directly connected but connected through a static route.

I used network specific static route not default route

[Richard Burts]

I think we need to look at the response being uuuuu. If the issue was something like the remote peer not having a return route then the response would be ..... timeout. Why is the router reporting unreachable?

perhaps the original poster can tell us a bit more about the routes they are advertising and the routes they are learning?