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

[Saku Ytti]

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
<juniper-nsp at puck.nether.net> 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti