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!

2 thoughts on “Changes bringing interface down in Junos

  1. Kerry

    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.

    Reply
  2. rtoodtoo Post author

    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 🙂

    Reply

Leave a Reply to Kerry Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.