Re: [j-nsp] GRE tunnels on a QFX10002-60C
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
Re: [j-nsp] GRE tunnels on a QFX10002-60C
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: [j-nsp] GRE tunnels on a QFX10002-60C
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: [j-nsp] GRE tunnels on a QFX10002-60C
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: [j-nsp] GRE tunnels on a QFX10002-60C
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 > 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: [j-nsp] GRE tunnels on a QFX10002-60C
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 on behalf of Mark Tinka via juniper-nsp Sent: Monday, June 27, 2022 1:04:55 PM To: Saku Ytti Cc: 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-nspdata=05%7C01%7Cgiuliano%40wztech.com.br%7Ce35a2c7f7326465f02b208da5856e3c8%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C637919427484898816%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=fvCpfQeWWcHTJJSxGZsiHAeKRHxcvtxSUeGRlg8HHi4%3Dreserved=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: [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://puck.nether.net/mailman/listinfo/juniper-nsp
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
