[c-nsp] ME3600X mLDP

[Lukas Tribus]

> I’m so sick of the ME3600s, and Cisco in general. Our latest
> kick in the pants was turning on DHCP snooping. That caused
> legitimate DHCP traffic that was traversing PWs on the box
> to get dropped. Snooping should have absolutely nothing at
> all to do with DHCP being carried inside a PW. Rediculous.

Its the same story on every platform: once you enable a feature
that has to be handled by the CPU (such as: DAI, PPPoE IA,
DHCP snooping, etc), you face all kinds of bugs because:

- the TCAM rule is a catch-all rule (all DHCP, all ARP traffic
must be forwarded to the CPU), it doesn't matter if certain vlans or
PWs doesn't have this feature enable

- all the forwarding logic that is implement in hardware (DON'T
  rx/tx on STP/REP blocked ports or disabled/not allowed Vlans, DO
  forward even if the traffic is double tagged, DO forward and bypass
  security if this feature is not enabled on this particular Vlan/PW,
  etc.) needs to be replicated in software


They don't have a software fallback for forwarding in these cases,
and they don't think they need one when they implement the TCAM
catch-all rule to punt to the CPU. They just fix one bug after another
that customers report. This kind of development style really is
ridiculous and shows how much those (outsourced) BU's really care
about the platform. I mean, the DE does know how the TCAM rule affects
the traffic, why doesn't he think for one second about the consequences?


Here are some of the bugs I reported for the ME3k4 platform that
trigger when enabling DAI or PPPoE IA:

CSCus14471 - ME3400 :: ARP packets crossing STP blocking port
Fixed in 12.2(60)EZ7

CSCur21533 — ME3400 processes PPPoE packets on stp blocking port and for disabled VLAN.
Fixed in 12.2(60)EZ6

CSCuq54085 — MAC is not learned from ARP with QinQ and DAI enabled.
Fixed in 12.2(60)EZ6

CSCup23223 ARP does not work in QinQ setup.
Fixed in 12.2(60)EZ5


Can you believe it?


Lukas