Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC
Hello,
These are taken from MX104 Routing Engine logs, correct?
If yes then "2016-05-11 16:19:58" is added by syslogd on RE.
And "2016-05-11 21:19:57" is WELF timestamp in syslog message from MS-MIC.
MS-MIC always keeps UTC timezone and this cannot be changed.
HTH
Thx
Alex
On 11/05/2016 23:08, Aaron wrote:
Continuing this thread...
Any idea why my cgnat syslog shows 2 different times (Central Time and
Universal Time) ?
16:19:58 is actually the system time on the mx104, but further into the
syslog trap you see UTC 21:19:57
2016-05-11 16:19:58 User.Info 10.101.12.243 May 11 16:19:58
eng-lab-mx104-cgn (FPC Slot 1, PIC Slot 0) 2016-05-11 21:19:57:
{cgn-sset}[jservices-nat]: JSERVICES_NAT_PORT_BLOCK_RELEASE: 10.144.0.102 ->
1.2.3.250:14900-14999 0x5733a0ae
- Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
Aaron, Have you tested any of the OAM features on the ACX5048 like Y.1564, 802.3ah, 802.1ag, Y.1731, Two-Way Active Measurement Protocol (TWAMP) and RFC2544? Do you have smaller ACX's like the 2200 connected to the ACX5048? Are you using Juniper MX routers in your network as well? On Tue, May 10, 2016 at 11:11 AM, Aaron wrote: > Hi Colton, first please understand that my motivation was to replace ~40 > cisco me3600’s eventually… we have deployed our cisco me3600’s as mpls pe’s > with eline, elan, etree in eline pw ldp flavors and bgp ad w/ldp sig vpls > flavors… and vpnv4/6 (junos speak inet/inet6) for mpls l3vpn’s… we needed > more 10 gig interfaces as our FTTH subs were consuming lots of bw. So I > wanted an mpls edge box about 1 or 2 U high around the same price as the > ME3600’s it would replace and bunches of 10 gig interface with some 40/100 > gig uplinks if possible. > > > > we compared... > > > > - Juniper ACX5048 – in lab > > - Juniper MX104 – in lab > > - Juniper EX4550 – in lab > > - Cisco ASR903 – in lab > > - Cisco ASR9001 – on paper > > - Cisco ASR903 – in lab > > - Cisco ASR920 (2 versions – in lab > > - Cisco NCS5001 (skywarp) – in lab > > > > I think the closest thing to the ACX5048 was the Cisco NCS5001…. But it > was a dog in the lab trial. Seriously, I had LLDP global config freeze up > my ssh/telnet sessions… then l2vpn had serious issues and so did l3vpn. > That ncs5k was not ready from prime time in the state (hw/xr sw) that I had > it in. > > > > We went with the acx5048. We bought (14) of them > > > > I just spent the last few days testing various mpls l2vpn architectures so > that I can confidently proceed with installing them. (I was told they > support lots of stuff and I proved out **some** of it last fall, but I > needed to get more experience on it… now I feel a bit better with the > eline, elan, etree ideas if have now introducing the acx5048 into my mpls > cloud with other 9k’s and me3600’s. > > > > Are there other mpls pe’s out there on the market ? probably so…. I > didn’t have time to test them all > > > > -Aaron > > > > > > > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC
Continuing this thread...
Any idea why my cgnat syslog shows 2 different times (Central Time and
Universal Time) ?
16:19:58 is actually the system time on the mx104, but further into the
syslog trap you see UTC 21:19:57
2016-05-11 16:19:58 User.Info 10.101.12.243 May 11 16:19:58
eng-lab-mx104-cgn (FPC Slot 1, PIC Slot 0) 2016-05-11 21:19:57:
{cgn-sset}[jservices-nat]: JSERVICES_NAT_PORT_BLOCK_RELEASE: 10.144.0.102 ->
1.2.3.250:14900-14999 0x5733a0ae
- Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Full routes on MX5
On 11/May/16 20:47, Michael Loftis wrote: > In our case except in testing with flow prior to 14.2 (unsure which > revision), and with a cold start we've not really observed issues with > RIB->FIB convergence in our use cases after upgrading to MPC3E's and > later. With the prior generation setup using DPCs there were occasionally > some significant RIB->FIB sync problems but in all cases I recall it > settled within a couple minutes. We've been quite happy with the convergence speed on our MX480's with an all-Trio compliment. This is on 14.2R6.5 Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Full routes on MX5
On Tue, May 10, 2016 at 1:12 PM, Adam Vitkovsky wrote: > > Michael Loftis > > Sent: Wednesday, April 27, 2016 6:48 PM > > To: Matthew Crocker > > Cc: juniper-nsp@puck.nether.net > > Subject: Re: [j-nsp] Full routes on MX5 > > > > You'll definitely be a lot happier with the bigger RE's...usually my > > convergence time at $dayJob is generally 3 minutes or less, with the less > > often depending on how fast we get routes form the other guy when a > > transit flaps. Cold starts are a little ugly-ish with the number of > full tables we > > take in but still ~5 minutes usually once booted...that RARELY happens > > though, esp now w/ 14.2's ISSU on MPCs... This is on an MX960 w/ MPC's > -- > > DPCs actually slowed the RIB->FIB process down I don't remember exact > > timings sorry -- 14.2 train as well which makes huge differences if > you're > > using flow, and that definitely slows things down. > > > So do I understand it right that your experience is that 14.2 further > slows down the RIB to FIB convergence as I'd assume the opposite? > No, sorry, you've misunderstood. It's no better, no worse with same hardware. DPCs are slower to get the RIB->FIB convergence, with MPCs we generally have not noticed any RIB->FIB convergence WITHOUT flow sampling on all supported releases. WITH sampling prior to more recent revs we DID see RIB->FIB issues with MPCs as well. For our use cases in production (not using sampling in production on DPCs!) it was DPCs causing occasionally slower RIB->FIB times for us. Never really had any serious issues like many have had but I put that down to having not used sampling/flow until well after Juniper had taken significant steps to address the sync issues as being the biggest reason. 14.2 didn't seem to change the timings except in problematic cases in the lab (flow sampling) but we didn't use flow sampling in production prior to 14.2 at all so I can't speak from any real experience there. > > Also I'd like to ask if you've considered using hierarchical FIB as a > workaround for the slow RIB to FIB convergence? > In our case except in testing with flow prior to 14.2 (unsure which revision), and with a cold start we've not really observed issues with RIB->FIB convergence in our use cases after upgrading to MPC3E's and later. With the prior generation setup using DPCs there were occasionally some significant RIB->FIB sync problems but in all cases I recall it settled within a couple minutes. In general when I'm speaking of convergence I mean the whole thing end to end. Which means you're also at the mercy of your peers because if they're not sending routes as fast as you can process them, you'll get slowed down. If your hardware at any point has a bottleneck you'll get slowed down. I'm generally NOT discussing the RIB->FIB step alone. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Channelization on EX4300
You cant do it They didnt want to create a switch with 16 x 10G for 5K$ list price Nitzan On Wed, May 11, 2016 at 5:30 PM, Paul S. wrote: > Hi folks, > > Do the QSFP+ ports on the EX4300 support channelization ( > https://www.juniper.net/documentation/en_US/junos15.1/topics/task/configuration/qfx3500-3600-standalone-channel-configuring.html > )? > > i.e: Can I break them out to 4x10g interfaces if ever needed? I've > actually been unable to find concrete info on this. > > Went through > https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-ex4300-support.html > without being able to find anything useful. > > ___ > 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] options for adding communities to an EVPN routing-instance?
Adam- I opened a JTAC case a few weeks back and was told to use the bgp export policy method. I haven't tried it in our lab yet, as I'm not keen on the method. To be fair I was looking at instance granularity, not mac address. If I end up testing something, I'll report back. -Michael > -Original Message- > From: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk] > Sent: Wednesday, May 11, 2016 9:04 AM > To: Michael Hare ; juniper-nsp@puck.nether.net > Subject: RE: options for adding communities to an EVPN routing-instance? > > > Michael Hare > > Sent: Saturday, April 23, 2016 12:12 AM > > > > Does anyone know if it is possible and how to add communities to routes to > > an EVPN routing-instance in the instance configuration itself? For example, > > in bgp.evpn.0, I have > > > > 2:a.b.c.d:200::1900::00:1f:45:a0:1b:bb/304 (2 entries, 0 announced) ... > > Communities: target:64900:200 > > > > I'd like to be able to add, for example, $MYISP:12345 to the mac > > announcements. I haven't tried but am guessing I could do this in the IBGP > > export policy using 'from instance' but this is suboptimal because then my > > PE > > will need different export policies whereas they are currently now all > > congruent. > > > Very interesting question indeed, > and I believe it's valid requirement as well. > > I'm just trying to find out, to no avail, if one can control what MAC > addresses > make it from MAC address table to MP-BGP and with what attributes. > If such a policy attachment point would exist one could tag MAC addresses with > standard communities there (but I think no such thing exist in Junos or XR) > > So when you tried to tag the MAC routes using iBGP peer export policy -has > that worked please? > > > adam > > > 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 addressed. This email is not intended to create any legal > relationship. No > one else may place any reliance upon it, or copy or forward all or any of it > in > any form (unless otherwise notified). If you receive this email in error, > please > accept our apologies, we would be obliged if you would telephone our > postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk > > Gamma Telecom Limited, a company incorporated in England and Wales, with > limited liability, with registered number 04340834, and whose registered > office > is at 5 Fleet Place London EC4M 7RD and whose principal place of business is > at > Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
On 11/May/16 18:04, Adam Vitkovsky wrote: > Brocade is using Broadcom chips as well right? Or are they using their own > chips in some of the boxes? The last time I tested the NetIron's, it was their own silicon. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
> Mark Tinka > Sent: Saturday, April 30, 2016 10:50 AM > > Besides Cisco and Juniper solutions discussed, what else is out there > > that has more than 4 10G ports with these feature sets? > > Look at Brocade. > > I'm not sure what they are doing now, but back then, they had a solid 1U > Metro-E box. We never bought it because we wanted to keep two vendors > only in our network. Technically, the box was/is sound. But I'd definitely buy > them for some specific use cases we are working on. > Brocade is using Broadcom chips as well right? Or are they using their own chips in some of the boxes? adam 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 addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Channelization on EX4300
Hi folks, Do the QSFP+ ports on the EX4300 support channelization (https://www.juniper.net/documentation/en_US/junos15.1/topics/task/configuration/qfx3500-3600-standalone-channel-configuring.html)? i.e: Can I break them out to 4x10g interfaces if ever needed? I've actually been unable to find concrete info on this. Went through https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/optical-interface-ex4300-support.html without being able to find anything useful. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] options for adding communities to an EVPN routing-instance?
> Michael Hare > Sent: Saturday, April 23, 2016 12:12 AM > > Does anyone know if it is possible and how to add communities to routes to > an EVPN routing-instance in the instance configuration itself? For example, > in bgp.evpn.0, I have > > 2:a.b.c.d:200::1900::00:1f:45:a0:1b:bb/304 (2 entries, 0 announced) ... > Communities: target:64900:200 > > I'd like to be able to add, for example, $MYISP:12345 to the mac > announcements. I haven't tried but am guessing I could do this in the IBGP > export policy using 'from instance' but this is suboptimal because then my PE > will need different export policies whereas they are currently now all > congruent. > Very interesting question indeed, and I believe it's valid requirement as well. I'm just trying to find out, to no avail, if one can control what MAC addresses make it from MAC address table to MP-BGP and with what attributes. If such a policy attachment point would exist one could tag MAC addresses with standard communities there (but I think no such thing exist in Junos or XR) So when you tried to tag the MAC routes using iBGP peer export policy -has that worked please? adam 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 addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cgnat on service module - interesting bgp advertisements
> Alexander Arseniev > Sent: Wednesday, April 20, 2016 7:36 AM > > Hello, > MS-MIC (and MS-MPC NPUs as well) automatically cuts out network (in your > case .128) and broadcast (in your case .255) IPs. > The rest cannot be expressed as single prefix, hence a bunch of smaller > prefixes is annonced instead. > This was done as PR 1019354 fix > https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1019 > 354 Although I understand the part with omitting first and last address for NAT translations I don't understand the advertisement chopping part. I'm just trying to think of a case where I'd define a NAT pool of 1.2.3.128/25 on the CG-NAT box and then use the 1.2.3.128 and 1.2.3.255 IPs somewhere else in the network so I would need the CG-NAT device to actually advertise just the IP ranges between 1.2.3.128 and 1.2.3.255 to avoid ...not sure what, as if I'd use and advertise the 1.2.3.128 and 1.2.3.255 as /32s they would still win over the 1.2.3.128/25 advertisement from CG-NAT box so no black holing or looping. Anyways I assume one could hopefully summarize these back into /25 before the fragments are advertised to BGP peers right? adam 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 addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
On 11/May/16 09:48, Phil Mayers wrote: > > The Cat6k including 6840 can certainly do a fair number of MPLS > features, we use their older brother (6880, sup2T) and for a little > while longer predecessor (sup720) as MPLS PE in L3VPN (inc. 6vPE), > MVPN and some small amount of L2VPN (mainly EoMPLS) > > IIUC the layer2 and MVPN stuff is lagging the state of the art quite a > bit on that software train, which might be an issue for you. > > The per-port cost will be relatively high compared to a merchant > silicon-based device, but the features tend to be a bit better. Port > density is also kind of low on the cat6k sadly. > > They also run plain old IOS, with it's paucity of modern comforts > (like any form of API, or transactional commits, etc.). Slightly weedy > CPU, especially if you use Netflow on them (do not get me started...) Egress policing and other advanced QoS features also used to be a big problem on this platform and its cousins, but I believe this has since been fixed for the SUP-2T as well as the current generation boxes in this portfolio. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
On 10/05/16 21:47, Aaron wrote: I have been curious about the cisco catalyst 6800 line… seems that the 6840 might fit this realm of smaller mpls pe… not sure of price… The Cat6k including 6840 can certainly do a fair number of MPLS features, we use their older brother (6880, sup2T) and for a little while longer predecessor (sup720) as MPLS PE in L3VPN (inc. 6vPE), MVPN and some small amount of L2VPN (mainly EoMPLS) IIUC the layer2 and MVPN stuff is lagging the state of the art quite a bit on that software train, which might be an issue for you. The per-port cost will be relatively high compared to a merchant silicon-based device, but the features tend to be a bit better. Port density is also kind of low on the cat6k sadly. They also run plain old IOS, with it's paucity of modern comforts (like any form of API, or transactional commits, etc.). Slightly weedy CPU, especially if you use Netflow on them (do not get me started...) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
