Re: [j-nsp] Transit composite next hops

[Luis Balbinot]

> My understanding is that "ingress" and "transit" in relation to CCNHs is
> just a very misleading nomenclature.
> If you want to go by definition CCNHs are pointers between VPN and NH label
> -and transit boxes have no knowledge of VPN labels so go figure...
>
> But there are still several levels of indirection in the next hop chain that
> transit routers can leverage in their FIBs.
>
> So what is the use case you're interested in?

None. I was only curious about transit CCNHs and how they managed to
derive information from transit traffic in order to create the CCNHs.
I questioned two SEs and neither came with a straight answer, so I
think even internally at Juniper this is some sort of black magic
restricted to a few Illuminati.

I do use ingress CCNHs, but mostly to make troubleshooting easier. I'm
far away from having tens of thousands of VPN entries that would
greatly benefit from that.

Luis
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Transit composite next hops

[Vladimir Blazhkun]

Hi, no, not supported. CNH is there only for a limited number of LER cases. 
Please contact the account team and PLM for the details.

-- 
Vladimir Blazhkun (via iPhone).

> On 10 Feb 2018, at 21:17, Luis Balbinot  wrote:
> 
> Hi.
> 
> I was reading about composite chained next hops and it was not clear to me
> whether or not MX routers support them for transit traffic. According to
> the doc bellow it's only a QFX10k/PTX thing:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/transit-edit-routing-options-chained.html
> 
> But there are some contradictions like this document:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-vpns-chained-composite-next-hops.html
> 
> Which is correct? Juniper docs on this subject, specially transit CNHs, are
> very superficial. The MX Series book does not mention it and the MPLS in
> the SDN Era only explains how the ingress CNHs work.
> 
> Thanks.
> 
> Luis
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Transit composite next hops

[adamv0025]

> Luis Balbinot
> Sent: Saturday, February 10, 2018 6:17 PM
> 
> Hi.
> 
> I was reading about composite chained next hops and it was not clear to me
> whether or not MX routers support them for transit traffic. According to
the
> doc bellow it's only a QFX10k/PTX thing:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/reference/co
> nfiguration-statement/transit-edit-routing-options-chained.html
> 
> But there are some contradictions like this document:
> 
> https://www.juniper.net/documentation/en_US/junos/topics/concept/mpl
> s-vpns-chained-composite-next-hops.html
> 
> Which is correct? Juniper docs on this subject, specially transit CNHs,
are very
> superficial. The MX Series book does not mention it and the MPLS in the
SDN
> Era only explains how the ingress CNHs work.
> 
The MX Series books are useless if you want to understand how MX routers
actually work.
I suggest you read through Dave Roy's work instead (for free):
https://www.juniper.net/uk/en/training/jnbooks/day-one/networking-technologi
es-series/packet-walkthrough-mx-series/
http://junosandme.over-blog.com/article-junos-load-balancing-part-1-introduc
tion-105738134.html -related to indirect next hops (and "CCNHs")

My understanding is that "ingress" and "transit" in relation to CCNHs is
just a very misleading nomenclature. 
If you want to go by definition CCNHs are pointers between VPN and NH label
-and transit boxes have no knowledge of VPN labels so go figure... 

But there are still several levels of indirection in the next hop chain that
transit routers can leverage in their FIBs. 

So what is the use case you're interested in? 
Is it whether if your P-core box sees 10K PEs behind AE0 interface and has a
ECMP or FRR-backup path via AE1, whether all these 10K will be swung in one
go without this "transit CCNH" feature enabled? 
-as for this specific one I'm not sure since the show outputs I did suggest
that each of these would have their own NH index.  

adam


netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Transit composite next hops

[Olivier Benghozi]

> On 13 feb. 2018 at 18:51, Luis Balbinot  wrote :
> 
> What is even more misleading is that the MX accepts the transit configuration 
> and commits without warnings. I issued the commit on a standalone router but 
> tomorrow I'm going to setup a lab with 3 routers. 

Well, there are plenty of config knobs that JunOS will happily and silently 
accept on any platform even if unsupported :)
They will either don't do anything, or fuck up something, or do what you expect 
but without Juniper support/endorsement.
Bet on one :P

> Some docs mention that MPC-only chassis like the MX80 come with CNHs 
> configured as the default, but that's only true for ingress EVPN. 

And in fact it's for all MXs.
Crappy doc.

> I'm still confused :-)

It's confusing.


> On Sun, 11 Feb 2018 at 19:56 Olivier Benghozi  > wrote:
> Hi Luis,
> 
> I already wondered the same thing, and asked to our Juniper representative ; 
> the answer was that each family supports (and only supports) its specific 
> CCNH flavour:
> CCNH for ingress: MX
> CCNH for transit: PTX (I didn't asked for QFX10k).
> Olivier
> 
> > On 10 feb. 2018 at 19:17, Luis Balbinot  > > wrote :
> >
> > I was reading about composite chained next hops and it was not clear to me
> > whether or not MX routers support them for transit traffic. According to
> > the doc bellow it's only a QFX10k/PTX thing:

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Transit composite next hops

[Luis Balbinot]

What is even more misleading is that the MX accepts the transit
configuration and commits without warnings. I issued the commit on a
standalone router but tomorrow I'm going to setup a lab with 3 routers.

Some docs mention that MPC-only chassis like the MX80 come with CNHs
configured as the default, but that's only true for ingress EVPN.

I'm still confused :-)

Luis

On Sun, 11 Feb 2018 at 19:56 Olivier Benghozi 
wrote:

> Hi Luis,
>
> I already wondered the same thing, and asked to our Juniper representative
> ; the answer was that each family supports (and only supports) its specific
> CCNH flavour:
> CCNH for ingress: MX
> CCNH for transit: PTX (I didn't asked for QFX10k).
> Olivier
>
> > On 10 feb. 2018 at 19:17, Luis Balbinot  wrote :
> >
> > I was reading about composite chained next hops and it was not clear to
> me
> > whether or not MX routers support them for transit traffic. According to
> > the doc bellow it's only a QFX10k/PTX thing:
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Transit composite next hops

[Olivier Benghozi]

Hi Luis,

I already wondered the same thing, and asked to our Juniper representative ; 
the answer was that each family supports (and only supports) its specific CCNH 
flavour:
CCNH for ingress: MX
CCNH for transit: PTX (I didn't asked for QFX10k).
Olivier

> On 10 feb. 2018 at 19:17, Luis Balbinot  wrote :
> 
> I was reading about composite chained next hops and it was not clear to me
> whether or not MX routers support them for transit traffic. According to
> the doc bellow it's only a QFX10k/PTX thing:

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp