[c-nsp] necessity of nowadays

[Sebastian Beutel]

Hi Lukas,

On Wed, Mar 23, 2016 at 04:47:14PM +0100, Lukas Tribus wrote:
> > but in the case of udld aggressive, i lost connectivity to the rest
> > of the network, because udld was only showing down on the n7k side
> > (not the far end).
> 
> This is exactly what aggressive mode does, I don't see how you could
> argue against UDLD because it does exactly what you configured it to
> do.
> 
> No, nobody needs aggressive mode, its a feature completely unrelated
> to the original UDLD idea, so why enabled it at all?
>
I belive, udld is supposed to prevent forwarding loops that arise because
stp brings a blocking port to forwarding state because it did not receive
bpdus from the other side (that can't be seen due to unidirectionality of
the link). As far as i understand rfc5171 the "normal" mode of udld does
_NOT_ bring down any interface, it only detects unidirectional links. Thus
it does _NOT_ prevent a loop but might help find it. That's probably why
people use "aggressive" mode. Am i wrong?

Most of the problems we had where concurrent to broadcast storms caused by
loops on simple, unmanaged user switches connected to our switches. Be it,
that excessive mac relearning restrained the cpu to respond to udld in time,
be it, that storm control discarded udld multicast frames. We did not
investigated that further. We once even had udld considering a link as
unidirectional (in a VSS szenario) where we couldn't find any reason at all. 
Can't remember how we fixed it.

Today we have much lower storm control thresholds in our access and we have
no storm control on our own inter switch links any longer. This proved as a
big relieve. The reasons why i am still considering to abandon udld are:

- Nowadays networks use link aggregation for redundancy instead of stp and
  thus have no blocking ports anymore.
- It's default timers are designed for classic stp. Today we run rstp so
  even in aggressive mode forwarding loops occur till udld timers age out
  (with default config).
- In our campus network we mostly have our own fibers and few leased dark
  fibers. The only way to create a unidirectional link on them was, to
  shine some light in from a third sfp. Interrupting a single fiber always
  brought down the whole interface. In other words: The situation from
  which udld is supposed to protect me is already prevented by other
  mechanisms for any likely cause. 

The reason why i still not dare abandoning it is, that i am not perfectly
shure that i missed some points in my consideration. 

Best,
    Sebastian.