[c-nsp] loop guard still useful?

[Saku Ytti]

On 19 January 2016 at 17:26, Lukas Tribus <luky-37 at hotmail.com> wrote:

> If the attacker is directly connected to that particular port where we
> are discussing about running UDLD or not, then there are a bunch of other,
> more important problems to fix. In any case he can just block his RX
> channel or spoof whatever UDLD message he wants, which is way simpler than
> congesting a rate-limiter.

They don't have to be on same port, they can be on any port. If you
don't limit L2 BPDU to the control-plane, it's somewhat easy to break
the control-plane. If you do limit it, then you can't run L2 BPDU for
anything critical.

Of course if you run all ports as L2 ports, then you can do L2 ACL,
and allow only etype ipv4, ipv6, arp on untrusted ports, and maybe you
can get away with it. But if you run L3 port, I don't think L2 ACLs
work, but IIRC it will still receive L2 BPDU, ISIS etc.

> Many of those root causes are not SW related, but HW failures (like my
> 7600 linecard).

In my experience software related faults vastly outnumber hardware
related faults. And as such, I'm hesitant to use software complexity
(like stacks, clusters) to solve HW problems.

> A network meltdown in the entire layer 2 domain because of the
> lack of UDLD feels like a bigger issue to me than a single
> switch crash or isolation.

Obviously UDLD can fail to detect unidirectional link, or fail to
report it, or fail to shutdown port. So saying autonego is no good,
because you have anecdotal evidence where it failed to detect
unidirectional link, does not exclude anecdotal evidence of UDLD
failing to do it.

> Therefor, if I have a shadow of a doubt that there is scenario
> in which my network will melt down, I will protect against that
> scenario even though this means using more code paths.

For me, I assume my network to be more robust and better MTBF without UDLD.

> So in your MPLS core you run ISIS/OSPF + LDP + RSVP +
> BGP, but no BFD because of the complexity of the latter?

Yeah I don't particularly like BFD. I've tried to run it few times,
but on 7600 it very often was false-positive link-downs, during BGP
convergence etc. I guess if ti's done in echo mode in NPU, it can be
very very robust. But HW liveliness detection is what I want to use.
But sometimes you buy hardware where you can't afford to buy ports, so
you multiplex ports with switch, and break HW liveliness detection, in
those scenarios, I think BFD is justifiable. But I would evaluate my
business case if I was unable to run ptp routing.

-- 
  ++ytti