IBGP multihop - intermediate router requirements?

[mrunion]

I have two routers in the same AS (a Juniper and a Cisco) that are running both BGP and OSPF.  These two routers are separated by an intermediate OSPF-only router. I have established an IBGP relationship between the Juniper and Cisco router and they are passing BGP routes between themselves.  The Cisco router also maintains an EBGP relationship where it is receiving various external routes and are marking up the local preference attribute to 400.  The Cisco has the "next-hop-self" associated with the neighbor statement facing the Juniper.  The Juniper sees the external route with the local preference of 400, and knows that the "next hop" to get there is the interface address of the Cisco.

Traffic destined for the external route hits the Juniper.  Presumably, the Juniper does a lookup and sees the best BGP route is held by the Cisco and sends traffic *towards* the Cisco.

HOWEVER, going from the Juniper to the Cisco, on the way to the Cisco, the intermediate OSPF-only router evaluates its own routing table and since it doesn't have the final external destination route in its routing table, decides to subject the traffic to its local default route, which *isn't* the Cisco.  Once again, the OSPF-only router has an OSPF route to the "next-hop" Cisco, but it doesn't have an OSPF route to the final destination of the original packet.

Juniper TAC maintains that the Juniper is doing the correct thing in sending the traffic out the proper interface towards the Cisco, and it's the OSPF-only router that is the problem.  And...it IS true that if I add a static route from the OSPF-only router to the Cisco for that external route, everything works.

Why does the intermediate OSPF-only router need to know a route to the final destnation of the packet?  Am I missing something?

[Harold Ritter]

Hi,

This is indeed the right behavior. Normally on a SP network, you would have BGP running on all edge and intermediate routers, so all of them would be in sync with where the traffic should go.

It is possible not to run BGP on the middle router but that would require you to deploy some tunneling technique between the edge routers, such as MPLS. In the case of MPLS, the traffic would be label switched between the edge routers. The intermediate router would simply label switch the traffic without looking at its IP routing table, so no need for the specific BGP routes in this case.

Regards

[mrunion]

Hi Harold,

Thanks for the prompt reply.  So is this different than how EBGP multi-hop works?  My understanding of EBGP multihop is that intermediate routers don't evaluate the ultimate destination of the packet based on their own routing tables.

Thanks,

Matt

[Harold Ritter]

Hi Matt,

The same behavior equally applies to eBGP. If the intermediate routers do not have the routing information it will simply drop the packets. A tunneling technique (GRE, L2TP, MPLS or other) would be required if the intermediate router does not have the routing information. In some scenarios, a couple of static routes could also be used on the intermediate router (default route in one direction and an aggregate route for the customer routes in the other direction).

Regards

[mrunion]

Harlod,

Hmmm...with regard to EBGP however, although intermediate routers likely have routes to the final destination (as well as to the EBGP peer itself), those intermediate routers don't actually route packets to the ultimate endpoint based on their own local routing tables.  Instead the traffic is routed first to the EBGP peer so that it ultimately handles routing of the packet based on its routing table.  The "tunneling" you speak of is part and parcel of traditional EBGP multihop peering, correct?

Matt

[Harold Ritter]

Hi Matt,

Traffic on the intermediate router is definitely routed using the local routing table. I think you are confusing the eBGP next hop and the destination IP address in the packets traversing the intermediate router. If there is no routing entry for that destination IP address traffic will be dropped, and this regardless whether if we are talking about iBGP or eBGP.

Regards