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

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 incorrectly. Yes, I've specifically disabled control

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

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? Sorry if this has been discussed before on list

Re: [j-nsp] EX4550: LACP channels short lost after commit

Infamous LAG LACP flap... I think there are several factors: crappy Junos code, LACP is CPU managed (at least on EX), so a pike in CPU (or a latency in the dedicated process) can break LAGs (make them flap in fact). I had some similar issues with SRX code. Go for slow LACP rate (30 seconds

[j-nsp] EX4550: LACP channels short lost after commit

Hi everybody, yesterday we had a very small hickup on a bunch of EX4550 doing Layer2 only in a Virtual-Chassis. According to the logfiles, there were some LACP changes on multiple independent channels on various fpcs so I couldn't spot just one VC member as a source. Now, just 1 hour ago, I

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

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 wouldn't need FAT-PW? -Michael > -Original