Cogent Layer 2

Thu Oct 15 14:49:47 UTC 2020

> Do you want your martini emulated backbone link to fail when operator reroutes their own LSR-LSR link failure?
As I said, it's an acceptable loss for my employers network, as we have a BGP failover mechanism in place that works perfectly.

> So you're dropping in every edge all UDP packets towards these three ports? Your customers may not appreciate.
You must not be familiar with JUNOS' ACL handling. This would be applied to interface lo0, which is specifically for control planes. No data plane traffic to customers would be hit.

Ryan
On Oct 15 2020, at 1:03 am, Saku Ytti <saku at ytti.fi> wrote:
> On Thu, 15 Oct 2020 at 10:28, Ryan Hamel <ryan at rkhtech.org> wrote:
>
> > My experience with multiple carriers is that reroutes happen in under a minute but rarely happen, I also have redundant backup circuits to another datacenter, so no traffic is truly lost. If an outage lasts longer than 5 minutes, or it's flapping very frequently, then I call the carrier. Last mile carriers install CPE equipment at the sites, which makes BFD a requirement to account for the fiber uplink on it going down, or an issue upstream.
> I think I may have spoken ambiguously and confusingly based on that
> statement. Rerouting inside operator network, such as their LSR-LSR
> link dropping is ostensibly invisible to the customer, can be tens of
> milliseconds outage can be 10s outage.
> Do you want your martini emulated backbone link to fail when operator
> reroutes their own LSR-LSR link failure?
>
> > As for security vulnerabilities, none can be leveraged if they are using internal IPs, and if not, a quick ACL can drop BFD traffic from unknown sources the same way BGP sessions are filtered.
> > In Juniper speak, the ACL would look like:
> > term deny_bfd {
> > from {
> > protocol udp;
> > destination-port [ 3784 3785 4784 ];
> > }
> > then discard;
>
> So you're dropping in every edge all UDP packets towards these three
> ports? Your customers may not appreciate.
>
> --
> ++ytti
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201015/5c8a2766/attachment.html>