[j-nsp] GRE tunnels on a QFX10002-60C

Mark Tinka mark at tinka.africa
Fri Jun 24 03:53:40 EDT 2022



On 6/24/22 09:28, Saku Ytti via juniper-nsp wrote:
>
> In many ways filter based decapsulation is actually preferable to
> interface, so I have no large qualms here. What I'd actually want is
> egress filter decap, instead of ingress. So I could point my GRE
> tunnels to random addresses at customer network, and have in my edge
> filters static decap statement which is never updated. Like 'from
> scurbber/32 to anywhere, protocol gre, decap'. This way my scrubber
> would launch GRE tunnels to any address at customer site, routing
> would follow best BGP path to egress and just at the last moment,
> packet would get decapped.

After failing to get Netscout to natively support IS-IS, we came up with 
a rather convoluted - but elegant - way to transport on-ramp/off-ramp 
traffic into and out of our scrubbers.

Basically, we use lt-* (logical tunnel) interfaces that sit both in the 
global table and a VRF. We loop them to each other, and use IS-IS + BGP 
+ LDP to tunnel traffic natively using MPLS-based LSP's signaled by LDP 
(as opposed to GRE), so that traffic an always follow the best IS-IS + 
iBGP path, without the hassle of needing to run GRE between routers and 
scrubbers.

The scrubbers inject the /32 or /128 route that needs protection, and 
the routers responsible for this "Frankenstein" setup do the rest. I'm 
quite proud of the setup, actually :-).

Essentially, it's equivalent to getting the Netscout TMS to be part of 
your IS-IS and MPLS/LDP domain, even though it supports neither.

Mark.


More information about the juniper-nsp mailing list