eBGP peers connected over OSPF external routes are using wrong next hop for BGP routes when BGP multihop is configured

Support Center > Search Results > SecureKnowledge Details

Technical Level

Solution ID	sk112112
Technical Level
Product	ClusterXL, Cluster - 3rd party, Quantum Security Gateways, VSX
Version	R77.30 (EOL)
OS	Gaia
Platform / Model	All
Date Created	24-Jul-2016
Last Modified	23-May-2017

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 .