Changes bringing interface down in Junos

I don’t know if there is any comprehensive list of changes which brings down an interface apart from specifically disabling the interface.
So far I recall two of them which are striking and might not be expected to flap interface. If anyone has also experience, it might be a good
place to share.

per-unit-scheduler
Years back I didn’t know that this change (i.e adding or removing this) was flapping the interface. If you have any routing protocol or any other component depending on the interface, be aware!

MTU change
If you change the MTU of an interface and again if you are running e.g BGP you will see a flap as traceoptions will clearly tell you that interface is going down.

Any other change you know affecting interface status? Please feel free to share!

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE


2 thoughts on “Changes bringing interface down in Junos”

  1. A few years ago I was working on an SRX connected to a layer-3 WAN with OSPF. Using some pings I figured out that the WAN had a maximum MTU of 1470, so I though that to avoid fragmentation then I would apply that MTU to the SRX interface.

    Bad move.

    I soon learned that the MTU is checked between OSPF neighbors and it is a requirement that the MTU matches before LSAs are exchanged. I learned that the hard way, because as soon as I did the commit then more than 400 routes disappeared from the SRX.

    rollback 1
    commit

    – these commands are your friend.

  2. yes that MTU is a tricky one that we should keep in mind. The thing is although I knew it, I did the mistake in the past too 🙂

You have a feedback?

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading