[j-nsp] Origin Validation on MX80

Mark Tinka mark.tinka at seacom.mu
Wed Aug 17 22:58:56 EDT 2016



On 17/Aug/16 18:51, Brad Fleming wrote:

> Seems to drop a little (not as much as I thought). What I found a
> little odd is that simply disabling the import policy on the BGP peer
> didn't result in decreased CPU after 15mins. I rebooted the MX80 and
> after the ~15mins of BGP flooding and convergence the CPU has calmed
> down a little.

I've found that major BGP changes on the MX80 and MX104 take too long to
settle down while in-flight. The quickest way is to reboot the box. For
instance, we once changed a BGP MSS value for a bunch of peers in one
go, and the sessions could not re-establish after the commit for more
than 30 minutes. Rebooting the box was the only option. That PPC CPU is
pretty slow...


>
> The RPKI you guys have enabled; is it just to test building the
> validation database?

We've enabled RPKI in our network, but are not yet enforcing policy.

One of the reasons was due to buggy code within IOS XE that crashed the
box when it evaluated RPKI data. This is now fixed.

The other reason was most networks that have created ROA's have not done
so for the longer prefixes - only for the aggregates. As such, we end up
the a lot of Invalid routes, even though they are not mis-originated.
This reduces the full table we can send to customers, making RPKI a
little less-than-useful in a practical setting.

But we have it fully enabled on our looking glass for our customers,
peers and interested parties to play with. You can take a look here if
you're interested:

    http://as37100.net/

We still plan to re-enable it for practical use going forward.

Mark.


More information about the juniper-nsp mailing list