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
Hi Daniel,
thank you for your reply.
I've read the RFC now and you're right. I opened a bug report with quagga
regarding this issue:
https://bugzilla.quagga.net/show_bug.cgi?id=602
OSPFv3 on quagga seems to be a bit buggy in general, I'm still waiting for a
fix of another
problem (bug #600).
Hi,
On Thu, Jun 17, 2010 at 10:46:51PM +0200, Volker D. Pallas wrote:
I've read the RFC now and you're right.
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)
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
On Wed, Jun 16, 2010 at 03:39:47AM +0200, Volker D. Pallas wrote:
I'm having an issue with an OSPFv3 neighborship between Linux/quagga
(0.99.16) and JUNOS (10.1R2.8 on SRX-100) via a standard ip-tunnel:
the dbd info sent by JUNOS always contains mtu 0, which quagga does
not like at all. This
Hi,
I'm having an issue with an OSPFv3 neighborship between Linux/quagga (0.99.16) and JUNOS
(10.1R2.8 on SRX-100) via a standard ip-tunnel:
the dbd info sent by JUNOS always contains mtu 0, which quagga does not like
at all. This keeps my neighborship in ExStart.
I set an ipv6 mtu on all
6 matches
Mail list logo
