[j-nsp] MX80 - Control Plane, Bridge Domains

[Andrei-Marius Radu]

Hi Ritz,

If you sure that specific addresses or ranges are not used at all (as
opposed to machines currently offline but which might wake up at a later
time) then you can configure more-specific static routes with a discard
next-hop.

On Tuesday, 14 October 2014, Ritz Rojas <ritzrojas at gmail.com> wrote:

> We have a particular legacy setup that involves a couple of multi-net
> bridge domains on an MX80 with a fairly decent number of networks attached
> to multiple interfaces.  Example:
>
> Bridge Domain
> ===
> > show configuration bridge-domains
> CUSTOMER {
>     description Customer;
>     domain-type bridge;
>     vlan-id XXX;
>     interface ge-1/0/0.0;
>     interface ge-1/0/1.0;
>     (multiple interfaces omiited, roughly 25 total);
>     routing-interface irb.xxx
>
> Interfaces
> ===
> > show configuration interfaces ge-1/0/0
> description Customer;
> encapsulation ethernet-bridge;
> unit 0;
>
> (repeat above for each bridge domain member)
>
> IRB
> ===
> > show configuration interfaces irb.xxx
> description Customer;
> family inet {
>     address 192.168.1.1/24;
>     address 192.168.2.1/24;
>     address 192.168.3.1/24;
>     (additional addresses omitted);
>
> The number of routed networks on the IRB is pretty large, >75.
>
> The problem that we're seeing is when somewhat large-ish amounts of traffic
> gets directed to non-existing hosts on these multi-nets (say to
> non-existing hosts numbered .100 to .200 in the 192.168.1/24 subnet, and
> expand that by all the configured subnets), the control-plane on the MX80
> seems to grind down to a halt.  ICMP RTT goes way up which alerts
> monitoring services, and we've even seen the box drop IGP/BGP to it's
> upstream device.
>
> We've already slapped in some interface specific ARP policers, but ARP
> policing won't really do anything for this issue, since the box itself is
> sending ARP traffic *out* towards those non-existing hosts, and IIRC ARP
> policing is an ingress interface function.  The box has a decent CoPP
> filter, but this is data-plane traffic to the directly attached hosts in
> the network, not necessarily to the interface itself (though it *is*
> resulting in excessive control-plane traffic due to the ARP load, it would
> appear) so I'm not sure we can solve this with CoPP.  We've also looked at
> sticking in some BUM policers on the bridge domains (bridge-domain
> blah/forwarding-options/flood), but that appears to be an ingress function
> as well, and we haven't seen that help either.
>
> Simply killing off and re-architect-ing this topology isn't currently an
> option, though it's planned at some point.  I'm curious if anyone run into
> this type of issue with this type of setup, and how did you solve it?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net <javascript:;>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>