Mailing List Archive

GRE tunnels on a QFX10002-60C
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
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
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@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@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
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
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: GRE tunnels on a QFX10002-60C [ In reply to ]
On Fri, 24 Jun 2022 at 10:54, Mark Tinka via juniper-nsp
<juniper-nsp@puck.nether.net> 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: GRE tunnels on a QFX10002-60C [ In reply to ]
On 6/24/22 11:01, Saku Ytti wrote:

> 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.

Agreed.

We use the MX204 as the dedicated router attached to the scrubber, so
there is no performance issue (yet).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
MX204 was announced at EoS

We have used MX204 for last 5 years. It was a huge success for any function it was designed.

Juniper only recommend to us ( about gre projects ) in mx product line

Are you going to use mx304 after this year ?

Even this box is more expensive ( 5x at least )

Or Juniper is thinking to launch a new router with TRIO 6 ?


Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> on behalf of Mark Tinka via juniper-nsp <juniper-nsp@puck.nether.net>
Sent: Monday, June 27, 2022 1:04:55 PM
To: Saku Ytti <saku@ytti.fi>
Cc: juniper-nsp@puck.nether.net <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] GRE tunnels on a QFX10002-60C



On 6/24/22 11:01, Saku Ytti wrote:

> 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.

Agreed.

We use the MX204 as the dedicated router attached to the scrubber, so
there is no performance issue (yet).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nsp&amp;data=05%7C01%7Cgiuliano%40wztech.com.br%7Ce35a2c7f7326465f02b208da5856e3c8%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C637919427484898816%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=fvCpfQeWWcHTJJSxGZsiHAeKRHxcvtxSUeGRlg8HHi4%3D&amp;reserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright ? 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informa??es deste e-mail e o conte?do dos eventuais documentos anexos s?o confidenciais e para conhecimento exclusivo do destinat?rio. Se o leitor desta mensagem n?o for o seu destinat?rio, fica desde j? notificado de que n?o poder? divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informa??es e do conte?do dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
I guess that the right thing to do would be to provide a licence based model for MX304 with an entry level capacity licence priced as the MX204 currently is...


> Le 27 juin 2022 à 18:15, Giuliano C. Medalha via juniper-nsp <juniper-nsp@puck.nether.net> a écrit :
>
> MX204 was announced at EoS
>
> We have used MX204 for last 5 years. It was a huge success for any function it was designed.
>
> Juniper only recommend to us ( about gre projects ) in mx product line
>
> Are you going to use mx304 after this year ?
>
> Even this box is more expensive ( 5x at least )
>
> Or Juniper is thinking to launch a new router with TRIO 6 ?


--
*Ce message et toutes les pièces jointes (ci-après le "message") sont
établis à l’intention exclusive des destinataires désignés. Il contient des
informations confidentielles et pouvant être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de détruire le message. Toute utilisation de
ce message non conforme à sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite, sauf autorisation expresse
de l'émetteur*
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
On 6/27/22 18:15, Giuliano C. Medalha wrote:

> MX204 was announced at EoS
>
> We have used MX204 for last 5 years. It was a huge success for any
> function it was designed.

We intend to keep running ours until the 2nd coming :-).

I don't have time for Juniper's nonsense.


>
> Juniper only recommend to us ( about gre projects ) in mx product line
>
> Are you going to use mx304 after this year ?
>
> Even this box is more expensive ( 5x at least )
>
> Or Juniper is thinking to launch a new router with TRIO 6 ?

I'm having a meeting with them about all this on Thursday. If anything
is exciting, and I can share, I will.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
On 6/27/22 18:22, Olivier Benghozi via juniper-nsp wrote:

> I guess that the right thing to do would be to provide a licence based model for MX304 with an entry level capacity licence priced as the MX204 currently is...

That would, indeed, be the right thing. But it's the wild west in
vendor-land, now. Can't believe anything they say to stay true for any
reasonable period of time.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
On 6/27/22 21:22, Mark Tinka wrote:

>
> I'm having a meeting with them about all this on Thursday. If anything
> is exciting, and I can share, I will.

As promised, below is what has developed:

As it pertains to the both the MX204 and MX10003, Juniper have made the
following amendments:

    EoS = 2023.
    End of new features = 2024.
    End of bug fixes = 2028.
    End of critical features = 2028.
    EoL = 2029.

FWIW.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: GRE tunnels on a QFX10002-60C [ In reply to ]
On 24-Jun-22 9:28, Saku Ytti via juniper-nsp wrote:
> 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.:



On the other hand, there is fti (flexible tunnel interface) concept
which is the recommended (as far as i'm aware) way for BT platforms.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp