Hi,
did you get any feedback from Netonix?

Well, doing further checkings, we found that the Netonixs are not honoring the displayed MTU. Connecting only via the Arista, the tunnel began to work as expected.

We are getting in touch with Netonix to see how we can solve the issue.

Many thanks!

Did you find a solution?

It's possible, but convergence time can be horrible.. between 5 and 15 minutes.

Don't put the native vlan to the members list.

unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ production ];
}
native-vlan-id vlan0;
}
}
}

I'm experiencing the same problem on CCR1016 when disabling ND on interfaces or after removing IP addresses from interfaces - at least since v6.23. Correspondence with MT support did not result in a solution or even acknowledgment of the problem.

What about #2015042966000618?
It was supposed to be addressed in 6.30.

What about #2015042966000618?

Sorry for not beeing precise. LEDs of ports sfp10 to sfp12 show activity although nothing is connected. Ports are working. It's a new box upgraded from 6.18 to 6.28. Seems there's an error in default config: /system leds set 0 interface=sfp1 set 1 interface=sfp2 set 2 interface=sfp3 set 3 interface=...

CCR-1016-12S-1S+

Same problem here - but over reliable ethernet link.
Ticket#2014091666000304

Is there any workaround besides configuring static routes?

zerxen, did you succeed?

MrPaul, did you succeed?

The OSPF instance immediately recovered after the interface was up again and the device was pingable from the other end. And tehre were no changes to the MTU in the network.

If it happens again I will try to gather more information.

Best Regards
Christof

shdwmstff,

did you find a solution for your problem? I did experience the same problem last night when an ethernet port went down for 12 seconds.
I'm using RSVP TE instead of LDP. The tunnel was "on hold" after that until reset.

Best Regards
Christof