Support Center > Search Results > SecureKnowledge Details
eBGP peers connected over OSPF external routes are using wrong next hop for BGP routes when BGP multihop is configured
Symptoms

  • Hosts behind the BGP peers are not reachable in the following scenario:

    1. eBGP membership is established over OSPF external routes (LSA Type 5 and Type 7), so that eBGP peers learn how to reach each other via OSPF routes.
    2. BGP multihop is configured.

  • When there are no static routes configured on the Gaia OS, the BGP routes are removed from the routing table, although they are received from the eBGP peer.

    Example: 
    HostName:0> show bgp peers
PeerID        AS     Routes  ActRts  State             InUpds  OutUpds  Uptime
192.168.30.30  102    0       0       Established       1       0        01:14:36
192.168.30.34  103    0       0       Established       1       0        01:15:12

HostName:0> show bgp peer 192.168.30.30 received

IPv4 Route MED LocalPref Nexthop Communities
192.168.30.40/30 -1 N/A(EBGP) 192.168.30.30

HostName:0> show route
O E       192.168.30.28/30   via 192.168.30.1, eth1, cost 1:10, age 5025, tag 0x00000000
O E       192.168.30.32/30   via 192.168.30.1, eth1, cost 1:10, age 5025, tag 0x00000000
Cause

When using BGP multihop, the next hop received with BGP routes will be the IP address of BGP peer, which is not directly connected.

RouteD daemon needs to check how to reach the next hop in order to add the route to the routing table.

When an OSPF route leads to the next hop, RouteD daemon does not take OSPF routes into account when deciding what would be the next hop used for the BGP routes.


Solution
 Note: To view this solution you need to Sign In .