[quagga-dev 10616] Re: calculating external route when a forwarding_address is present

Charlet, Ricky ricky.charlet at hp.com
Mon Jul 22 18:08:21 BST 2013

Howdy David,
   Wow, that's a fair bit to ponder in three sentences.  Here are some thoughts...

  I can't disclose more. I am using a quagga variant which we purchase from a vendor and have NDAs with, UNH also runs their testing under NDAs. I'm new in the office and have not read any of those and I've probably already violated them (don't tell my boss). As time goes by here, I will be a voice inside for taking these results public, but that will be more like years from now rather than days from now. Bummer. Sorry.

  Now, "Should quagga skip this check?"...
   Hmmmm, Tough one...
  First off, There is a line of our conversation which should proceed in parallel... do we agree that the RFC specifies this check and am I in the right area of code to implement the check, and if so, what am I doing wrong with my implementation? I'd appreciate not losing sight of that  thread as we take on your question.

   Is it "the right thing" to be more liberal than the RFC here? Some thoughts:
 * This feature feels like esoteric city... varying away from RFC in this feature should be clearly justified in comments in code so that others, in the next decade from now who ask this same question, won't have to wonder at our intent.
 * if zebra is aware of the route via any protocol or even via the kernel (who may have learned routes from other routing daemons) then having the route lookup check will not preclude non-ospfd routes.
 *  I don't understand  what the code in ospf_ase_calculate_route(), near/below " /* Find a route to the same dest */ /* If there is no route, create new one. */" is doing, and understanding that well is probably very germane to choosing our answer here.
* having a forwarding address with a viable route to reach it is only about hop efficiency. If, for some reason, we have a forwarding address but don't have a route to reach, then we can justifiable rely upon default routes and ASBRs.

Ricky Charlet
Software Dev / Routing Dude: Aries team, Roseville CA
ricky.charlet at hp.com
USA: 916.785.2090

-----Original Message-----
From: equinox at diac24.net [mailto:equinox at diac24.net] On Behalf Of David Lamparter
Sent: Sunday, July 21, 2013 1:27 AM
To: Charlet, Ricky
Cc: quagga-dev at lists.quagga.net
Subject: Re: [quagga-dev 10614] calculating external route when a forwarding_address is present

On Sun, Jul 21, 2013 at 01:26:30AM +0000, Charlet, Ricky wrote:
> I'm putting a quagga variant through the paces with UNH testing. They 
> have a test case, OSPFv2_Interop_1.05, which I'm failing. The setup 
> and steps to reproduce are actually fairly arduous and I hope to skip 
> them for the life of this discussion, but I can post if it becomes 
> needful.

Great!  Can you make the results public?  I tried pushing for UNH testing through various channels without much luck so far.

> The bottom line is that I think ospfd is not quite doing the right 
> thing when considering external-lsas that have a forwarding_address 
> set. Take a look at ospf_ase_forward_address_check()... it does not 
> check to see if a route to fwd_addr exists. I think it should. RFC 
> 2328, 16.4 (3) is the relevant reference.

I haven't looked at it in detail yet, but going from the "might there be a reason to this?" angle, it may be that this was done intentionally to support cases where the forwarding address is made reachable by some other routing protocol.  Admittedly, the originating OSPF router shouldn't include a forward address in that case, but who knows what bits operators fiddle with...

(I have no idea if this makes any sense/happens in reality/should be supported, it's just something to think about.  It may well be that it is totally unreasonable.)


More information about the Quagga-dev mailing list