Re: [j-nsp] GRE tunnels on a QFX10002-60C
On Fri, 24 Jun 2022 at 10:54, Mark Tinka via juniper-nsp wrote:> 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. Many ways to skin the cat. If you can dedicate small router to the scrubber (or routing-instance if you can't) and you run BGP-LU, so you avoid useless egress IP lookup, you just ensure that the scrubber PE or scrubber instance doesn't have the more specific routes, then it'll follow the BGP-LU path to egress CE. You can scrub any and all prefixes, without any scale implications as you never need to touch the network to handle clean traffic. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE tunnels on a QFX10002-60C
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE tunnels on a QFX10002-60C
Tunnel interfaces are not supported on PE/Paradise, I don't think this
changed in BT/Triton either.
However you can decapsulate/encapsulate on ingress firewall filter, e.g.:
term cleanPipe:xe-0-4-1-1 {
from {
source-address {
a.b.c.d/32;
}
destination-address {
e.f.g.h/30;
}
protocol gre;
}
then {
count cleanPipe:xe-0-4-1-1;
decapsulate gre routing-instance xe-0-4-1-1;
}
}
Here traffic coming from a specific source address, going to a
specific destination link using IP protocol 'GRE' is being counted,
accepted and decapsulated into a routing-instance.
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.
On Fri, 24 Jun 2022 at 00:24, Jon Lewis via juniper-nsp
wrote:
>
> I've got an open support case with Juniper, but as it's gotten nowhere
> since opening it last night, I figured I'd try some crowdsourcing :)
>
> Does anyone have working GRE tunnels terminated to a QFX10002-60C? We've
> got a GRE tunnel mesh of several dozen sites, using a mix of Arista 7280s
> and Juniper QFX5120s to terminate the tunnels. We're trying to add a
> couple of new sites to the mesh where the tunnels will live on
> QFX10002-60C. What we're seeing with the QFX10002-60C is, locally
> generated traffic (i.e. ping from the QFX10002-60C to an IP reachable via
> a gr-0/0/0.XX interface) works, but traffic from another device in the POP
> that needs to transit a QFX10002-60C which should then route the traffic
> via a gr-0/0/0.XX interface is dropped.
>
> I'm trying to figure out if there's something special about the
> QFX10002-60C that requires some config knob not needed on QFX5120 or if
> GRE is just broken on the QFX10002-60C. The QFX10002-60C are running
> 20.4R3.8.
>
> --
> Jon Lewis, MCP :) | I route
> StackPath, Sr. Neteng | therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
