[quagga-dev 3685] Re: BGP distribution into OSPF / next-hop is dropped?

Paul Jakma paul at clubi.ie
Tue Sep 27 07:49:11 BST 2005


On Sun, 25 Sep 2005, Hasso Tepper wrote:

> In fact forwarding address concept is introduced to specify 
> nexthops other than routers own addresses. But there are several 
> restrictions - most importantly there MUST be internal on inter 
> area path to forwarding address to be used in calculations at all.

Right.

Also the RFC (2328 anyway) says the forwarding address "should point 
to a router belonging to another Autonomous System", if set. It 
doesn't say much else about what that address should be though. The 
NSSA RFC does however require the forwarding address to be on-link 
for the Type-7 at least, but that's type-7 not 5 ;).

> In fact forwarding address works just fine in ospfd, try 
> redistribute static route with next-hop in the ospf enabled 
> connected network. But I'm not aware of any implementation that 
> allows setting forwarding address other than connected network.

Hmm, maybe not directly, but think of type-7s translated to type-5. 
The type-5s will be originated by the NSSA area's ABR but the 
forwarding address will be of the NSSA ASBR or even of the external 
next-hop.

Further, even if the forwarding address is on-link, that address is 
unlikely to be on-link for routers to which the LSA propogates.

> As far as I understood (routing loop occurs), user expected 
> forwarding address to be in the network hop away from originating 
> router. As I said, I'm not aware of any implementations which 
> allows this.

Well in the example given, AIUI:

   _________eBGP_______
  /                    \
R1 <------> R2 <-----> R3
  \___OSPF__/


R1 redistributes BGP prefix X NEXT_HOP R3 into OSPF, but uses the FIB 
next-hop rather than the next-hop of the protocol being 
redistributed.

 	LSA ID: prefix X
 	Adv-RID: R1
 	Forward: 0.0.0.0

So R2 obviously calculates prefix X via R1. If instead we set the 
forward address to the distributed protocol's next-hop:

 	LSA ID: prefix X
 	Adv-RID: R1
 	Forward: R3

Then, as long as R2 shares a link with R3 and advertises it in its 
/router-lsa/ (not as an external), everything should work. If the R3 
address is a loopback address on R3, it will never work. Does that 
make sense?

Ie, it would actually be nice to be able to specify whether the 
originating protocol's next-hop or self should be specified.. Indeed, 
we should probably at a minimum adopt the same rules as for type-7 as 
for type-5 and do some kind of check exactly as per:

> Same rules apply as with static routes (which I already explained). 
> If connected link is in ospf domain (ospf is enabled on interface) 
> forwarding-address is set to resolved nexthop.

Ah, much more concise.

You mean "If connected link is in ospf domain" as: so R1 could check 
whether the BGP NEXT_HOP existed in OSPF, if it found intra/inter 
area path (ie R2 with a connected interface to NEXT_HOP R3), then we 
could set R3 as forward address, right?

(Ie the "ospf is enabled on interface" part - ignore, cause obviously 
R1 has no interface to R3).

> Otherwise behaviour depends on area used - in normal area 
> forwarding address is set to 0.0.0.0, in NSSA area to one of 
> routers ip addresses in ospf domain. And this works just fine in 
> ospfd.

Right.

The original poster would obviously though be much better served by 
*NOT* distributing BGP into OSPF. ;)

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Wernher von Braun settled for a V-2 when he coulda had a V-8.



More information about the Quagga-dev mailing list