[quagga-dev 5434] Re: [PATCH] RFC 2328, chap 8.1:

paul at clubi.ie paul at clubi.ie
Tue Jun 3 11:01:05 BST 2008


On Tue, 3 Jun 2008, Joakim Tjernlund wrote:

> On Mon, 2008-06-02 at 22:20 +0100, paul at clubi.ie wrote:

>> You're saying you've already got routers with shared addresses,
>> enabled for OSPF? Which happens to work somehow by accident? And
>> you're afraid that if you upgrade Quagga to a version that
>> understands how to safely advertise such shared addresses, that other
>> routers (broken ones) will break?
>
> Exactly, we are using zebra-0.93-pre2 + many patches

On routers which have the same address on multiple interfaces, all 
enabled for OSPF?

> This I don't get. What is it I have to avoid? Please spell it out 
> for me.

Well, the address no longer uniquely identifies an interface. A 
property depended on by at least ospfd, in its implementation - I 
wouldn't be surprised if other daemons did too. The OSPF RFC also 
depends on this property.

>> 'zebra' can be made to auto-detect shared addresses though - and it
>> *should*, to prevent breakage (as is possible today).
>
> hmm, don't think so.

Sure it can. Keep an index of the local addresses - if there's a 
collision for an index entry, then that address is shared.

> I like the shared address better than a unnumbered flag that is 
> manually configured on each i/f.

Do you have reasons for why?

If software can take care of something without manual intervention, 
then it should. The entire point of computer software is to automate 
processes we'd have to otherwise carry out ourselves. With regard to 
routing specifically: It's already administratively intensive, and 
the routing protocols *already* have too many arcane knobs to 
configure and/or tweak - we should try not to add to that.

So there needs a good reason to make something manually configured, 
if it need not have been. :)

> A new zebra command would be used to specify the shared address.

Why exactly?

> Once ospf start transmitting the ifIndex in its LSAs, old ospf will 
> break, won't it? The old quagga tries to match this ifIndex against 
> a remote address and that won't match.

Correct.

However, the only way ospfd will start transmitting ifIndex's is if 
your routers were already borken..

The situation you're worried about is going to need administrative 
action to fix, either way. I'd rather we get administrators to change 
their network configuration to avoid the unsupported-and-broken setup 
in the first place, than make ospfd more complex to configure (and 
continue to be broken-by-default).

Such broken setups are equally fragile in the face of *other* (more 
conformant) OSPF implementations, which we have 0 zero control over. 
Adding a new router to your network can break them as easily as 
upgrading a Quagga/GNU Zebra one to support unnumbered. I.e. The only 
way to avoid breakage is to administratively vet the use of shared 
addresses / unnumbered interfaces across /all/ your routers, 
regardless of whether they are Quagga or not.

I.e.: There's going to be administrative pain, yes. Let's try 
minimise it (by keeping it specific to networks already using shared 
addresses + borken GNU Zebra/Quagga), rather than maximising it (by 
requiring special configuration in Quagga for shared addresses, 
always)..

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Trying to define yourself is like trying to bite your own teeth.
 		-- Alan Watts



More information about the Quagga-dev mailing list