Re: [j-nsp] Limit on interfaces in bundle

On Tue, Nov 03, 2015 at 01:22:49AM +0200, Saku Ytti wrote: > On 2 November 2015 at 19:14, Jesper Skriver wrote: > > Right, on those types of platforms it can be done - assuming there > > are spare bits in the meta data that goes with the packet, enough > > free instruction

Re: [j-nsp] Limit on interfaces in bundle

> From: Jesper Skriver [mailto:jes...@skriver.dk] > Sent: Tuesday, November 03, 2015 10:34 AM > > On Mon, Nov 02, 2015 at 06:30:00PM +, Adam Vitkovsky wrote: > > Adam Vitkovsky IP Engineer T: 0333 006 5936 E: adam.vitkov...@gamma.co.uk W: www.gamma.co.uk

Re: [j-nsp] Limit on interfaces in bundle

On 3 November 2015 at 17:19, Adam Vitkovsky wrote: > But I like your example with the Entropy label. > What if the topmost label value or even better the VPN/VC label could > indicate how to parse the remainder of the packet. > And if a middle node or end node(in case

Re: [j-nsp] Limit on interfaces in bundle

On Mon, Nov 02, 2015 at 06:30:00PM +, Adam Vitkovsky wrote: > -Original Message- > > From: Jesper Skriver [mailto:jes...@skriver.dk] > > Sent: Monday, November 02, 2015 5:14 PM > > > > > > Right, on those types of platforms it can be done - assuming there are spare > > bits in the meta

Re: [j-nsp] Limit on interfaces in bundle

On 3 November 2015 at 12:08, Jesper Skriver wrote: > I magine you have 4 routers in a line A-B-C-D, router A sends > packets with different ethertypes depending on payload, but router > B doesn't have the ability to preserve this, so all MPLS packets > leaving B has the same

Re: [j-nsp] Limit on interfaces in bundle

On 2 November 2015 at 15:30, Jesper Skriver wrote: Hey, > 1) Keep all the logic as today, but for different received >ethertypes point to different L3 tables, that result in >different rewrite objects that ensure the outgoing packets >have the different ethertypes

Re: [j-nsp] Limit on interfaces in bundle

sp@puck.nether.net > Subject: Re: [j-nsp] Limit on interfaces in bundle > > On Sun, Nov 01, 2015 at 05:06:22PM +0200, Saku Ytti wrote: > > On 1 November 2015 at 12:08, Jesper Skriver <jes...@skriver.dk> wrote: > > > > > To do what you suggest, one either has to

Re: [j-nsp] Limit on interfaces in bundle

> Adam Vitkovsky IP Engineer T: 0333 006 5936 E: adam.vitkov...@gamma.co.uk W: www.gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was

Re: [j-nsp] Limit on interfaces in bundle

On Mon, Nov 02, 2015 at 03:04:22PM +, Adam Vitkovsky wrote: > > Saku, > > > > The point is that the incoming ethertype is only used to determine how to > > interprete the header (IPv4, IPv6, MPLS etc) and to select what L3 table to > > lookup in. After that it is gone, and never used again. >

Re: [j-nsp] Limit on interfaces in bundle

On Mon, Nov 02, 2015 at 06:47:06PM +0200, Saku Ytti wrote: > On 2 November 2015 at 18:09, Jesper Skriver wrote: > > I am not sayint that it doesn't make sense - I am saying that it > > doesn't appear practical given the architecture of the average > > router. What I've

Re: [j-nsp] Limit on interfaces in bundle

On 2 November 2015 at 18:09, Jesper Skriver wrote: > I am not sayint that it doesn't make sense - I am saying that it > doesn't appear practical given the architecture of the average > router. What I've described above is how the typical router > is implemented. > > Feel free

Re: [j-nsp] Limit on interfaces in bundle

On 2 November 2015 at 19:14, Jesper Skriver wrote: > Right, on those types of platforms it can be done - assuming there > are spare bits in the meta data that goes with the packet, enough > free instruction space etc - but it will come at a performance impact > as it will

Re: [j-nsp] Limit on interfaces in bundle

Saku, On Fri, Oct 30, 2015 at 10:47:48PM +0200, Saku Ytti wrote: > On 30 October 2015 at 12:35, Jesper Skriver wrote: > > > That would not be practical to implement for a router, implementations > > typically have the L2 header cached and the L3 forwarding > > constructs just

Re: [j-nsp] Limit on interfaces in bundle

On 1 November 2015 at 12:08, Jesper Skriver wrote: > To do what you suggest, one either has to replicate the MPLS > table, so that we can handle the same label values for each of the > suggested MPLS-IPv4, MPLS-IPv6, MPLS-XX, MPLS-YY, with the only > different being that they

Re: [j-nsp] Limit on interfaces in bundle

On 30/Oct/15 18:49, Michael Hare wrote: > Thanks much for the replies, I better understand your dilemma. > > Assume your P/PE support RFC 6790, isn't RFC 6790 essentially a superset of > RFC 6391? If you configure RFC 6790 network wide for all LDP FECs [again, > we're homogenous], you

Re: [j-nsp] Limit on interfaces in bundle

Hi > Saku Ytti [mailto:s...@ytti.fi] > Sent: Friday, October 30, 2015 12:45 AM > There isn't really super good way to duck-type in LSR transit. Frankly MPLS > would have done well to specify multiple ethertypes, MPLS-IP, MPLS-ETH, > MPLS-UNSPECIFIED, this could be introduced post-fact, by making

Re: [j-nsp] Limit on interfaces in bundle

On 29/Oct/15 20:03, Michael Hare wrote: > Mark- > > re: EoMPLS pw balancing, do you have no-control-word configured? Nope - control-word is not disabled. It is on by default in Junos anyway: tinka@lab# run show l2circuit connections | match control-word CM -- control-word mismatch Up --

Re: [j-nsp] Limit on interfaces in bundle

Hey, > Saku Ytti [mailto:s...@ytti.fi] > Sent: Friday, October 30, 2015 12:37 AM > > Exactly. So if it's smart device, like Trio, it can do smart thing with or > without > control-word (unsure if Trio does, and it does, since what versions), if it's > stupid box, lack of control-word causes

Re: [j-nsp] Limit on interfaces in bundle

On 30 October 2015 at 12:35, Jesper Skriver wrote: Hey Jesper, > That would not be practical to implement for a router, implementations > typically have the L2 header cached and the L3 forwarding > constructs just point to a rewrite object that contain the > appropriate L2

Re: [j-nsp] Limit on interfaces in bundle

On 30/Oct/15 11:06, Adam Vitkovsky wrote: > Yes I agree that control word should definitely be enabled across the board, > it’s necessary on Cisco anyways. Enabled by default in Junos. One would have to manually turn it off. Mark. ___ juniper-nsp

Re: [j-nsp] Limit on interfaces in bundle

On Fri, Oct 30, 2015 at 02:44:44AM +0200, Saku Ytti wrote: > On 30 October 2015 at 00:54, Cydon Satyr wrote: > > > Adam I believe that is correct. If I remember this, if it's something other > > than 0x4/0x6 Trio chip looks at bits after first 12 bytes; if it's > >

Re: [j-nsp] Limit on interfaces in bundle

Adam Vitkovsky <adam.vitkov...@gamma.co.uk>; Saku Ytti > <s...@ytti.fi> > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Limit on interfaces in bundle > > > > On 30/Oct/15 11:06, Adam Vitkovsky wrote: > > > Yes I agree that control word should

Re: [j-nsp] Limit on interfaces in bundle

-- > > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On > Behalf > > Of Mark Tinka > > Sent: Friday, October 30, 2015 4:17 AM > > To: Adam Vitkovsky <adam.vitkov...@gamma.co.uk>; Saku Ytti > > <s...@ytti.fi> > > Cc: juniper-nsp@

Re: [j-nsp] Limit on interfaces in bundle

Hi Cydon, > From: Cydon Satyr [mailto:cydonsa...@gmail.com] > Sent: Friday, October 30, 2015 2:08 PM > > Hi Adam, > As far as I know, P router doesn't base hash on mac-address at all. So in case > of non L3VPN packet (not 0x4/0x6) it tries to see if its IPv4/IPv6 payload. > On the other hand

Re: [j-nsp] Limit on interfaces in bundle

On 30/Oct/15 14:44, Michael Hare wrote: > All- > > You are correct about ECMP, I encountered this 12+ months ago and forgot that > specific details. Mark said he put the whole AE bundle into per packet mode > [on a short LAN hop], which can also cause reordering [not just the LSP] if > used

Re: [j-nsp] Limit on interfaces in bundle

On 30/Oct/15 15:49, Michael Hare wrote: > I see that 14.1 [we're going there for E-VPN] also supports RFC 6391 and RFC > 6790, so I probably need to take a closer look. Anyone have experience with > either in JunOS yet? Mark, was it you that was on 14.2 for ingress CoS > purposes? > >

Re: [j-nsp] Limit on interfaces in bundle

age- > From: Mark Tinka [mailto:mark.ti...@seacom.mu] > Sent: Friday, October 30, 2015 11:36 AM > To: Michael Hare <michael.h...@wisc.edu>; Adam Vitkovsky > <adam.vitkov...@gamma.co.uk>; Saku Ytti <s...@ytti.fi> > Cc: juniper-nsp@puck.nether.net > Subject: Re

[j-nsp] Limit on interfaces in bundle

Hello experts, Could somebody confirm if 16 is the max number of physical interfaces one can have in a LAG on MX? What about MX2020, is it still 16, or is it possible to have more than that? So far I've see 16 is max on every MX platform but I heard someone mentioned it could go higher. Best

Re: [j-nsp] Limit on interfaces in bundle

Oh wow. Any real drawbacks to running something like 32x10Gbps LAG link in core instead of higher bandwidth physical links? Just seems so unreal. Thanks, BR On Thu, Oct 29, 2015 at 1:09 PM, Olivier Benghozi < olivier.bengh...@wifirst.fr> wrote: > max 64 ports per LAG: > >

Re: [j-nsp] Limit on interfaces in bundle

On 29 October 2015 at 14:22, Cydon Satyr wrote: > Any real drawbacks to running something like 32x10Gbps LAG link in core > instead of higher bandwidth physical links? Just seems so unreal. I imagine you have 70% utilisation, so you have 96Gbps of free capacity, but any

Re: [j-nsp] Limit on interfaces in bundle

max 64 ports per LAG: http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/maximum-links-edit-chassis-.html There's also a

Re: [j-nsp] Limit on interfaces in bundle

On 29/Oct/15 14:22, Cydon Satyr wrote: > Oh wow. > > Any real drawbacks to running something like 32x10Gbps LAG link in core > instead of higher bandwidth physical links? Just seems so unreal. Folk like AMS-IX have publicly acknowledged running 32x 10Gbps on their exchange point (albeit, with

Re: [j-nsp] Limit on interfaces in bundle

On 29 Oct 2015, at 12:49, Mark Tinka wrote: > > > On 29/Oct/15 14:22, Cydon Satyr wrote: > >> Oh wow. >> >> Any real drawbacks to running something like 32x10Gbps LAG link in core >> instead of higher bandwidth physical links? Just seems so unreal. > > Folk like AMS-IX

Re: [j-nsp] Limit on interfaces in bundle

On 29/Oct/15 16:09, Saku Ytti wrote: > > JunOS does have these days adaptive balancing, which essentially > monitors if one link has higher utilisation than others, then proceeds > to give smaller share of hash results to that interface. I don't know > how well it works in practice. It works

Re: [j-nsp] Limit on interfaces in bundle

> Cydon Satyr > Sent: Thursday, October 29, 2015 12:22 PM > Any real drawbacks to running something like 32x10Gbps LAG link in core > instead of higher bandwidth physical links? Just seems so unreal. > LAGs are tricky. You get unpredictable failover times when links go down and it's even worse

Re: [j-nsp] Limit on interfaces in bundle

On 10/29/15 5:57 AM, Edward Dore wrote: > On 29 Oct 2015, at 12:49, Mark Tinka wrote: > >> >> >> On 29/Oct/15 14:22, Cydon Satyr wrote: >> >>> Oh wow. >>> >>> Any real drawbacks to running something like 32x10Gbps LAG link in core >>> instead of higher bandwidth physical

Re: [j-nsp] Limit on interfaces in bundle

nsp@puck.nether.net > Subject: Re: [j-nsp] Limit on interfaces in bundle > > > > On 29/Oct/15 16:09, Saku Ytti wrote: > > > > > JunOS does have these days adaptive balancing, which essentially > > monitors if one link has higher utilisation than others, then

Re: [j-nsp] Limit on interfaces in bundle

It's code version dependent. It was raised recently, so if you still see 16 you need to upgrade. On Oct 29, 2015 5:01 AM, "Cydon Satyr" wrote: > Hello experts, > > Could somebody confirm if 16 is the max number of physical interfaces one > can have in a LAG on MX? What

Re: [j-nsp] Limit on interfaces in bundle

On 29 October 2015 at 20:03, Michael Hare wrote: Hey Michael, > re: EoMPLS pw balancing, do you have no-control-word configured? My > understanding [and experience] is that vc is sticky due to hashing based on > presence of control word. If control word is absent you

Re: [j-nsp] Limit on interfaces in bundle

Hey all, Adam I believe that is correct. If I remember this, if it's something other than 0x4/0x6 Trio chip looks at bits after first 12 bytes; if it's 0x0800/0x86dd it still load balances this packet based on IPv4/IPv6 rules, and if it's 0x8100 it skips up to two vlan headers and again checks

Re: [j-nsp] Limit on interfaces in bundle

> Saku Ytti > Sent: Thursday, October 29, 2015 7:49 PM > > Now you can have MAC address > starting with 4, which would be incorrectly balanced as if it were IPv4, > causing > reordering. > But shouldn’t the box check for packet length to avoid the "4" or "6" DMAC issue So it should revert back

Re: [j-nsp] Limit on interfaces in bundle

On 30 October 2015 at 01:31, Adam Vitkovsky wrote: ​Hey, ​ For labelled traffic it should be: > > label 1-5 (by default) > > MPLS Payload (L3-header for L3VPN packets or L2-header for L2VPN/PW > packets) > > > > And the LU chip should receive 320B chunk so there

Re: [j-nsp] Limit on interfaces in bundle

On 30 October 2015 at 00:54, Cydon Satyr wrote: > Adam I believe that is correct. If I remember this, if it's something other > than 0x4/0x6 Trio chip looks at bits after first 12 bytes; if it's > 0x0800/0x86dd it still load balances this packet based on IPv4/IPv6 rules, >

Re: [j-nsp] Limit on interfaces in bundle

Hey Cydon, > From: Cydon Satyr [mailto:cydonsa...@gmail.com] > Sent: Thursday, October 29, 2015 10:55 PM > Hey all, > Adam I believe that is correct. If I remember this, if it's something other > than > 0x4/0x6 Trio chip looks at bits after first 12 bytes; if it's 0x0800/0x86dd > it still >