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 I
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 confirmatio
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) int
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).
T
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.
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
