[quagga-dev 3685] Re: BGP distribution into OSPF / next-hop is dropped?
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.
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
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:
R1 <------> R2 <-----> R3
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
LSA ID: prefix X
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
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
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
The original poster would obviously though be much better served by
*NOT* distributing BGP into OSPF. ;)
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
Wernher von Braun settled for a V-2 when he coulda had a V-8.
More information about the Quagga-dev