[j-nsp] ospfv3 - JUNOS sends zero mtu in dbd -> stuck in ExStart

[Addy Mathur]

I ran into this a few years ago.  Even without going into the JUNOS
implementation (they will probably tell you that this is
"works-as-designed", and that this was a conscious decision), this
should not cause an issue in the OSPF session establishment.

Per RFC 2328 section 10.6,

"        If the Interface MTU field in the Database Description packet
        indicates an IP datagram size that is larger than the router can
        accept on the receiving interface without fragmentation, the
        Database Description packet is rejected.  Otherwise, if the
        neighbor state is:
...
        ExStart
            If the received packet matches one of the following cases,
            then the neighbor state machine should be executed with the
            event NegotiationDone (causing the state to transition to
            Exchange)...
"

Theoretically, MTU=0 would imply that the DBD packets should always be
received/processed, and thereby *not* cause any interop concerns.

--Addy.


On Thu, Jun 17, 2010 at 6:29 PM, Volker D. Pallas <juniper-nsp at sqmail.de> wrote:
> Hi again,
>
> yeah, this makes total sense!
> At first I thought this is a JUNOS-problem, as Cisco does send the "right"
> mtu along.
>
> I closed the bug report on the quagga bugzilla for now (with closed/invalid)
> and will
> talk to JTAC.
> I'll get back to you and the list as soon as I have some confirmation and/or
> fix.
>
>>I'm not so sure anymore. A fellow reader has challenged my
>>interpretation of the RFC wording, that it might mean "OSPF virtual
>>links", not tunnel (and similar virtual, non-physical) interfaces.
>>Upon re-reading with that interpretation in mind, I tend to agree.
>>
>>Thinking further about it, mtu=0 for OSPF virtual links makes sense, as
>>only OSPF PDUs are being tunnelled, no actual traffic. So there is no
>>sensible MTU to report in the DBD packets. On real tunneling interfaces
>>though, everything (OSPF PDUs and actual traffic) gets tunnelled, and
>>the tunnel has a real MTU associated.
>>
>>So in fact, I think my interpretation was wrong and JUNOS is actually
>>misbehaving by advertising MTU=0. It should report the tunnel interface
>>L3 MTU.
>>
>>Sorry for the noise. I suggest raising a case with JTAC and closing off
>>the Quagga bug filing.
>
> No, not at all! Thanks a lot for your input! I did not even read the
> appropriate
> RFC before you posted, which I should do next time.
>
>>BTW, I noticed your Linux tunnel interface being named "gre-nc" - I
>>guess the "gre" part is a leftover misnomer from trying GRE encaps?
>
> exactly ;-) It's actually "sit" now on the linux side
>
>>Best regards from Porz to Porz,
>>Daniel
>
> and best wishes back to you!
>
> Volker
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>