[j-nsp] BMP and IPv6
Hey! I am trying to collect route information using BMP: https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bmp-understanding.html No problem with IPv4. I receive new routes and withdrawn routes without any issue. However, for IPv6, the MP_REACH_NLRI path attribute is incorrectly encoded (both Wireshark and GoBGP agree on this): Path Attribute - MP_REACH_NLRI Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete Type Code: MP_REACH_NLRI (14) Length: 30 Address family identifier (AFI): IPv6 (2) Subsequent address family identifier (SAFI): Unicast (1) Next hop network address (16 bytes) Number of Subnetwork points of attachment (SNPA): 0 Network layer reachability information (9 bytes) MP Reach NLRI length 184 invalid [Expert Info (Error/Malformed): MP Reach NLRI length 184 invalid] 90 0e 00 1e 00 02 01 10 20 01 0d b8 00 01 00 00 ... 0010 00 00 00 00 00 00 00 01 00 40 20 01 0d b8 00 53 .@ S 0020 00 00.. Moreover, when routes are withdrawn, the UPDATE message doesn't contain withdrawn routes but come with a MP_UNREACH_NLRI which has the same encoding problem. Border Gateway Protocol - UPDATE Message Marker: Length: 39 Type: UPDATE Message (2) Withdrawn Routes Length: 0 Total Path Attribute Length: 16 Path attributes Path Attribute - MP_UNREACH_NLRI Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete Type Code: MP_UNREACH_NLRI (15) Length: 12 Address family identifier (AFI): IPv6 (2) Subsequent address family identifier (SAFI): Unicast (1) Withdrawn routes (9 bytes) MP Unreach NLRI length 184 invalid [Expert Info (Error/Malformed): MP Unreach NLRI length 184 invalid] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010 00 27 02 00 00 00 10 90 0f 00 0c 00 02 01 40 20 .'@ 0020 01 0d b8 00 07 00 00 ... Again, with IPv4 routes, no such issue: Border Gateway Protocol - UPDATE Message Marker: Length: 28 Type: UPDATE Message (2) Withdrawn Routes Length: 5 Withdrawn Routes 192.0.2.7/32 Withdrawn route prefix length: 32 Withdrawn prefix: 192.0.2.7 Total Path Attribute Length: 0 I have tried various versions (16.1, 17.1, 17.3) without any change. Even if Juniper was implementing an earlier draft, encoding of path attributes should still be correct. Has someone already get this problem? -- Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Hi, We had issues with port 1 of 3 switches, it was more power related than a physical issue in our case. Once we replaced then with SRs the issue went away but only 1 set lasted, and it was the 0,2 aeX. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 12/05/17 10:59, Benoit Plessis wrote: Le 05/12/2017 à 16:40, Alain Hebert a écrit : Rofl, That's why!!! We where wondering why 0 & 2 worked but not 0 & 1. Did you mean you were able to plug them in and they didn't work ? ___ 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] EX3400 experiences / software recommendation
Hi, we run 6 of them with 15.1X53-D56 (pure layer2 stanmdalone boxes, no specials, out of band management with external firewalling, i.e. without local firewall filters). In opposite to the older releases (first steps with them were cruel, first release was more some kind of "pre-alpha early access" than "can be used in production") they run fine yet. kind regards Rolf > Hi, > > quick question about the EX3400 series... is one of you using them in > earnest, and can recommend a software version? > > One of my customers was sold four of them, and we see "funny things" > (like, switch ports only forwarding ARP packets but no IP, bunch of > copper GE ports going down and back up simultaneously with nobody > near the box, untypical things in logs...) and "common wisdom" hints > at "you want a more recent software version". > > On the boxes is "jtac recommended" 15.1X53-D56, which is a bit old - > one would assume that this is "for stability", but it could as well > be "nothing so critical was found that they bothered to update the > page"... > > > (As one or the other might know, I'm usually more a Cisco guy, so please > excuse if this is something "one really should know" - and yes, I'm > trying to figure out in parallel what sort of formal support the customer > was sold by their "value added integrator" here, so I can raise a formal > case...) > > gert ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3400 experiences / software recommendation
I have (2) of them in a new small data center deployment and they are
function fine. However, the first 2 I deployed one of the them
crash-rebooted over and over... after talking to JTAC, I replaced it and now
all is well. I run that same junos version you mentioned. JTAC rma'd the
bad one.
{master:0}
gvtc@stlr-dcvc-3400> show version | grep "Model|Junos:|fpc"
fpc0:
--
Model: ex3400-24t
Junos: 15.1X53-D56
fpc1:
--
Model: ex3400-24t
Junos: 15.1X53-D56
{master:0}
gvtc@stlr-dcvc-3400> show virtual-chassis
Virtual Chassis ID: 4255.1234.2468
Virtual Chassis Mode: Enabled
Mstr Mixed Route
Neighbor List
Member ID Status Serial NoModel prio Role Mode Mode
ID Interface
0 (FPC 0) Prsnt(removed) ex3400-24t 128 Master* N VC 1
vcp-255/2/3
1 (FPC 1) Prsnt(removed) ex3400-24t 128 Backup N VC 0
vcp-255/2/3
Member ID for next new member: 2 (FPC 2)
- Aaron Gould
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX3400 experiences / software recommendation
Hi, quick question about the EX3400 series... is one of you using them in earnest, and can recommend a software version? One of my customers was sold four of them, and we see "funny things" (like, switch ports only forwarding ARP packets but no IP, bunch of copper GE ports going down and back up simultaneously with nobody near the box, untypical things in logs...) and "common wisdom" hints at "you want a more recent software version". On the boxes is "jtac recommended" 15.1X53-D56, which is a bit old - one would assume that this is "for stability", but it could as well be "nothing so critical was found that they bothered to update the page"... (As one or the other might know, I'm usually more a Cisco guy, so please excuse if this is something "one really should know" - and yes, I'm trying to figure out in parallel what sort of formal support the customer was sold by their "value added integrator" here, so I can raise a formal case...) gert -- now what should I write here... Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Even different Juniper models have slightly diferent form factors. I have both 1GE and Tri-rate sfps from Juniper and they are different On Dec 5, 2017, at 11:49 AM, Aaron Gould wrote: We *carefully* tried copper sfp's above and below each other in ACX5048 and it's ok. Perhaps there are other slightly larger form factor copper sfp's out there on the market that this is not so advisable... dunno. I think our Occam (now Calix) B-Series boxes had this issue as well years ago -Aaron ___ 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] Copper transcievers in QFX5100, EX4600 and ACX5048
We *carefully* tried copper sfp's above and below each other in ACX5048 and it's ok. Perhaps there are other slightly larger form factor copper sfp's out there on the market that this is not so advisable... dunno. I think our Occam (now Calix) B-Series boxes had this issue as well years ago -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Le 05/12/2017 à 16:40, Alain Hebert a écrit : > Rofl, > > That's why!!! > > We where wondering why 0 & 2 worked but not 0 & 1. Did you mean you were able to plug them in and they didn't work ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Rofl, That's why!!! We where wondering why 0 & 2 worked but not 0 & 1. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 12/05/17 09:40, Karl Gerhard wrote: Hello the official documentation for QFX5100, EX4600 and ACX5048 contains the following statement: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/port-panel-qfx5100-48S.html "Caution: Do not place a copper transceiver in an access port directly above or below another copper transceiver. Internal damage to the access ports and switch can occur. We recommend either using the top port row exclusively, or bottom port row exclusively, for copper transceivers." Does this apply only to Direct Attach Cables or copper SFP modules oder both? This is potentially a big thing for us since we would like to use copper SFP modules on some of our devices. Regards Karl ___ 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] Copper transcievers in QFX5100, EX4600 and ACX5048
❦ 5 décembre 2017 15:40 +0100, Karl Gerhard : > the official documentation for QFX5100, EX4600 and ACX5048 contains the > following statement: > https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/port-panel-qfx5100-48S.html > "Caution: Do not place a copper transceiver in an access port directly > above or below another copper transceiver. Internal damage to the > access ports and switch can occur. We recommend either using the top > port row exclusively, or bottom port row exclusively, for copper > transceivers." > > Does this apply only to Direct Attach Cables or copper SFP modules > oder both? This is potentially a big thing for us since we would like > to use copper SFP modules on some of our devices. DAC cables are fine, only copper SFP modules are affected. The damage is mechanical due to the SFP module being too high. -- Don't diddle code to make it faster - find a better algorithm. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Hello the official documentation for QFX5100, EX4600 and ACX5048 contains the following statement: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/port-panel-qfx5100-48S.html "Caution: Do not place a copper transceiver in an access port directly above or below another copper transceiver. Internal damage to the access ports and switch can occur. We recommend either using the top port row exclusively, or bottom port row exclusively, for copper transceivers." Does this apply only to Direct Attach Cables or copper SFP modules oder both? This is potentially a big thing for us since we would like to use copper SFP modules on some of our devices. Regards Karl ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley)
I can't afford wasting time figuring out whether the feature is broken per se or due to use in logical-system and there's the problem of missing features as you mentioned, so all in all, can't really use logical-systems in virtual or physical lab. I find the only limiting factor in large builds to be the system memory. CPU wise the VMs are still rock solid even if "load average" is ~4-5. And for simulation purposes you don't need to be concerned with speed. -hence no need to worry about the VT support, these router VMs will happily run in pure QEMU. adam > -Original Message- > From: Chris Burton [mailto:chris.bur...@speakeasy.net] > Sent: Sunday, December 03, 2017 6:37 AM > To: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] [c-nsp] LACP between router VMs (James Bensley) > > For better or worse I do remember those days, though I was referring to > recent hardware switches/bridges (should have clarified that). To my > knowledge that only applies to things like the STP protocols, but I could be > wrong, again would need to read through the specifications again to be sure > as that is not a use case I have needed thus far. > > Scaling the vMX for testing/lab/PoC deployments can be challenging, but I > have been able to get large topologies off of a single older model dual Xeon > E5-2670 server using logical systems, total of seven vMX instances and 84 > routers using the aforementioned logical systems, at that point I run into > thermal limits because of the VFP CPU usage (even in lite-mode, which only > appears to be related to the number of interfaces rather than the packet > processing, which seems to be the same in lite and performance modes > hence the CPU usage). Some months back I tried to see how large of a > topology I could build with five servers I had access to, I was able to get to > seven vMX instances per server with > 12 logical systems per vMX instance which gave me a 420 router topology > using the trial license, so you can scale a lab/PoC setup quite nicely. Only > downside to using logical systems is they do not support everything that a > non-LS would support, the biggest missing feature in my case being EVPN. > > Another item I have been testing is the vQFX which has much less CPU > demand since the interfaces are bound to the VCP instead of the VFP, but I > have run into many other issues with that and have not tested it as > thoroughly, it is also just a alpha/beta release from Juniper at the moment. > > -C > > > On 12/02/2017 03:40 AM, adamv0...@netconsultings.com wrote: > > Hey, > > > >> local link and not forwarded by the soft bridge by default (I do not know > of > >> any hardware bridges that allow you to disabled this restriction, if you > know > >> of any I would be interested. > >> > > My understanding is that Carrier-Ethernet grade switches/routers should > allow you to peer/drop/tunnel/forward L2 protocols. > > If you're in be business long enough you may remember migrations from > leased-lines to frame-relay and then from FR to MPLS and then from L3VPNs > to L2VPNs to complete the circle. > > These L2 services especially the point-to-point ones, that's where > customers pretty much expect the same properties as they used to have in > leased-lines or FR services, basically just a pipe where MTU is not an issue > and can transport anything from L2 up so they can run their own MPLS/DC > networks over these pipes. > > > >> Out of curiosity what is your use case that you need to use LACP to > >> communicate with VMs? > >> > > Large scale ISP network simulations (for proof of concept testing of various > designs/migrations/etc). > > This allows me to verify my designs, how the technology works on selected > code versions -if there are any bugs, interworking between vendors. > > And there are the provisioning and network monitoring systems, new SDN > approaches that can be tested in this virtual environment, you name it. > > Since it's all virtual one can simulate complete networks rather than scaled > down slices used in physical labs, so I can see the effects of topology-based > route-reflection in terms of routes distribution, the effects of node or link > failures on traffic-engineering and possible congestion as a result across the > whole backbone all in 1:1 scale, but the important point is to make the > simulated control-plane as close to reality as possible hence the need for > LACP. > > > > Speaking of scale, the fact that the VFP is always at 100% CPU is not > > helping > -reminds me of the good old Dynamips -but at least there you could fix it > with an idle value. > > Having hundreds of these VNFs running is not very green. > > > > > > adam > > > > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
