Re: [j-nsp] EX-4200 mixed DC/AC power supply
On Wed, Dec 21, 2011 at 01:04:37PM +0800, Mark Tinka wrote: On Wednesday, December 21, 2011 07:45:40 AM Jim Glen wrote: I've done this on both the EX-4200... I'm curious what the switch would do, in this case, if you wanted to drive some IP phone or wi-fi AP's via PoE, as DC power supplies don't normally allow the switch to drive power to anything via 802.3af. Since the switch has both an AC and DC power supply, what would it do :-)? and the MX480 systems, it's not recommended by Juniper but it works, I've also mixed 110v and 208v with no problems. JimG That's when you, accidentally, plug the 208VAC source into the 110VAC power supply :-). Document, document, document. DON'T USE or DON'T CONNECT stickers all over the place, e.t.c. :-). All the EX4200 930W AC and MX240/480/960 power supplies I have seem are designed to work at 120V, 208V, or 240V with a 90V-250V or similar rating. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 mixed DC/AC power supply
The switch only has L2 basic functions, anything will be managed via PoE, just need to have a redundant PS for protection. Regards Enviado desde BlackBerry® de COMCEL S.A. -Original Message- From: Mark Tinka mti...@globaltransit.net Date: Wed, 21 Dec 2011 13:04:37 To: juniper-nsp@puck.nether.net Reply-To: mti...@globaltransit.net Cc: Jim Glenjim.g...@codonis.com; maeve2...@gmail.com Subject: Re: [j-nsp] EX-4200 mixed DC/AC power supply On Wednesday, December 21, 2011 07:45:40 AM Jim Glen wrote: I've done this on both the EX-4200... I'm curious what the switch would do, in this case, if you wanted to drive some IP phone or wi-fi AP's via PoE, as DC power supplies don't normally allow the switch to drive power to anything via 802.3af. Since the switch has both an AC and DC power supply, what would it do :-)? and the MX480 systems, it's not recommended by Juniper but it works, I've also mixed 110v and 208v with no problems. JimG That's when you, accidentally, plug the 208VAC source into the 110VAC power supply :-). Document, document, document. DON'T USE or DON'T CONNECT stickers all over the place, e.t.c. :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 mixed DC/AC power supply
On Wednesday, December 21, 2011 09:49:57 PM Chuck Anderson wrote: All the EX4200 930W AC and MX240/480/960 power supplies I have seem are designed to work at 120V, 208V, or 240V with a 90V-250V or similar rating. Ah okay - we're a 240VAC country, so never had the need to use a lower voltage (although I know some of the Cisco kit we have deployed in the U.S. supports both 120VAC and 240VAC. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX80 and netflow v9
Hi all, anyone knows if it's possible to enable cflowd version 9 on MX80? Usually, enabling cflowd v9 require to use a MultiService PIC, but it seems that this equipment do not supports that. Can anyone help me? Thank you Nino Ciurleo ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IP/MPLS fast convergence
Hello All, I'm planning a greenfield IP/MPLS network for a mobile operator. The requirements are to support MPLS services (mainly L3 VPNs but also some VPLS), enforce strict but fairly simple CoS model, and support fast convergence. No requirement for CSPF based TE. Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just for the sake of FRR, and tunnel LDP inside these LSPs. This way I would get FRR without the burden of full mesh RSVP LSPs. However in the last two years I read more and more about LFA, IP/LDP FRR and similar technologies. I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if anyone is actually using this in the field, if so what is the impression. Regards Amos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IP/MPLS fast convergence
Hello, We did started a greenfield deployment 2 years ago. We had no requirement for FRR and stayed clear of RSVP. We did implement LDP + OSPF LFA since it was just an extra knob and gave us something for free. We used Link Protection. The caveat with LFA is that it will not protect 100% of your paths. A given link failure may re-route some of your traffic via LFA while the rest has to wait for standard OSPF convergence. WANDL did some LFA coverage analysis for us and if I remember correctly based on our topology we have ~70% of paths covered. I ran some tests on our Prod network before it went live. LFA did in fact allow sub-50ms convergence. For paths that weren't covered by LFA in a worst case scenario, I got about 300ms. Not too bad. Junos seems really fast at converging even without LFA. We use MX960s and MX80s. I hope this helps. Serge From: Amos Rosenboim a...@oasis-tech.net To: juniper-nsp@puck.nether.net Sent: Wednesday, December 21, 2011 2:34:22 PM Subject: [j-nsp] IP/MPLS fast convergence Hello All, I'm planning a greenfield IP/MPLS network for a mobile operator. The requirements are to support MPLS services (mainly L3 VPNs but also some VPLS), enforce strict but fairly simple CoS model, and support fast convergence. No requirement for CSPF based TE. Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just for the sake of FRR, and tunnel LDP inside these LSPs. This way I would get FRR without the burden of full mesh RSVP LSPs. However in the last two years I read more and more about LFA, IP/LDP FRR and similar technologies. I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if anyone is actually using this in the field, if so what is the impression. Regards Amos ___ 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] IP/MPLS fast convergence
Hello Serge, Thanks for sharing your insights, it's valuable. Can you explain why only some of the paths are protected ? Regards, Amos Sent from my iPhone On 21 Dec 2011, at 21:47, Serge Vautour sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca wrote: Hello, We did started a greenfield deployment 2 years ago. We had no requirement for FRR and stayed clear of RSVP. We did implement LDP + OSPF LFA since it was just an extra knob and gave us something for free. We used Link Protection. The caveat with LFA is that it will not protect 100% of your paths. A given link failure may re-route some of your traffic via LFA while the rest has to wait for standard OSPF convergence. WANDL did some LFA coverage analysis for us and if I remember correctly based on our topology we have ~70% of paths covered. I ran some tests on our Prod network before it went live. LFA did in fact allow sub-50ms convergence. For paths that weren't covered by LFA in a worst case scenario, I got about 300ms. Not too bad. Junos seems really fast at converging even without LFA. We use MX960s and MX80s. I hope this helps. Serge From: Amos Rosenboim a...@oasis-tech.netmailto:a...@oasis-tech.net To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Sent: Wednesday, December 21, 2011 2:34:22 PM Subject: [j-nsp] IP/MPLS fast convergence Hello All, I'm planning a greenfield IP/MPLS network for a mobile operator. The requirements are to support MPLS services (mainly L3 VPNs but also some VPLS), enforce strict but fairly simple CoS model, and support fast convergence. No requirement for CSPF based TE. Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just for the sake of FRR, and tunnel LDP inside these LSPs. This way I would get FRR without the burden of full mesh RSVP LSPs. However in the last two years I read more and more about LFA, IP/LDP FRR and similar technologies. I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if anyone is actually using this in the field, if so what is the impression. Regards Amos ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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
[j-nsp] Junos 11.2R4.3 on MX
Just wondering if anyone has been brave enough to run Junos 11.2R4.3 yet on a MX960? We are currently on the latest 10.4, but would really like to upgrade to get “trunk style” config on Trio line cards. I also noticed during a previous ISSU that the Trio based line cards aren’t compatible yet with ISSU and had to be rebooted during a software upgrade. This feature is also available in 11.2. Our configuration is pretty basic, Layer2, BGP, OSPF, nothing fancy. Any info would be appreciated. Thanks, Brendan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 11.2R4.3 on MX
Yes, doing a lab eval on it and it has a nasty mibd leak bug. Running a daily 11.2 build at the moment that fixes it (precursor to R5 coming out in January). So, I would wait for R5 if you plan on doing any SNMP work at all on the box. -Jeff On Dec 21, 2011, at 12:20 PM, Brendan Mannella wrote: Just wondering if anyone has been brave enough to run Junos 11.2R4.3 yet on a MX960? We are currently on the latest 10.4, but would really like to upgrade to get “trunk style” config on Trio line cards. I also noticed during a previous ISSU that the Trio based line cards aren’t compatible yet with ISSU and had to be rebooted during a software upgrade. This feature is also available in 11.2. Our configuration is pretty basic, Layer2, BGP, OSPF, nothing fancy. Any info would be appreciated. Thanks, Brendan ___ 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] IP/MPLS fast convergence
LFA relies on the topology to be one in which a failure won't cause a traffic to head back the other direction. So topologies such as rings are not good because an adjacent node may send traffic back to a node with an upstream failure creating a microloop. The router will not create a protection path in that scenario just use regular convergence. LFA works well in triangle or hub and spoke topologies. You have to be careful with setting metrics as well. There has been some work on newer algorithms and ways to notify adjacent nodes either inband or out of band of a failure to ensure 100% coverage. Today I do not think any vendor has implemented those features. As for the design it really depends on the SLA. If you do not need 50ms Traffic restoration LDP should work fine. On a metro network IGP convergence is pretty fast these days probably less than 500ms. Phil On Dec 21, 2011, at 3:23 PM, Amos Rosenboim a...@oasis-techs.net wrote: Hello Serge, Thanks for sharing your insights, it's valuable. Can you explain why only some of the paths are protected ? Regards, Amos Sent from my iPhone On 21 Dec 2011, at 21:47, Serge Vautour sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca wrote: Hello, We did started a greenfield deployment 2 years ago. We had no requirement for FRR and stayed clear of RSVP. We did implement LDP + OSPF LFA since it was just an extra knob and gave us something for free. We used Link Protection. The caveat with LFA is that it will not protect 100% of your paths. A given link failure may re-route some of your traffic via LFA while the rest has to wait for standard OSPF convergence. WANDL did some LFA coverage analysis for us and if I remember correctly based on our topology we have ~70% of paths covered. I ran some tests on our Prod network before it went live. LFA did in fact allow sub-50ms convergence. For paths that weren't covered by LFA in a worst case scenario, I got about 300ms. Not too bad. Junos seems really fast at converging even without LFA. We use MX960s and MX80s. I hope this helps. Serge From: Amos Rosenboim a...@oasis-tech.netmailto:a...@oasis-tech.net To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Sent: Wednesday, December 21, 2011 2:34:22 PM Subject: [j-nsp] IP/MPLS fast convergence Hello All, I'm planning a greenfield IP/MPLS network for a mobile operator. The requirements are to support MPLS services (mainly L3 VPNs but also some VPLS), enforce strict but fairly simple CoS model, and support fast convergence. No requirement for CSPF based TE. Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just for the sake of FRR, and tunnel LDP inside these LSPs. This way I would get FRR without the burden of full mesh RSVP LSPs. However in the last two years I read more and more about LFA, IP/LDP FRR and similar technologies. I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if anyone is actually using this in the field, if so what is the impression. Regards Amos ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 and netflow v9
Inline Netflow for the MX using MPCs(Trio) cards only support IPFIX and only IPv4 is currently supported. If the Netflow is done on the RE (software based) you can only do Netflow v5. I know the above is true for our MX960s, believe it's the same for the MX80s. Sent from my iPhone On Dec 21, 2011, at 12:05, Nino Ciurleo nino.ciur...@garr.it wrote: Hi all, anyone knows if it's possible to enable cflowd version 9 on MX80? Usually, enabling cflowd v9 require to use a MultiService PIC, but it seems that this equipment do not supports that. Can anyone help me? Thank you Nino Ciurleo ___ 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] IP/MPLS fast convergence
On Thursday, December 22, 2011 02:34:22 AM Amos Rosenboim wrote: I'm planning a greenfield IP/MPLS network for a mobile operator. The requirements are to support MPLS services (mainly L3 VPNs but also some VPLS), enforce strict but fairly simple CoS model, and support fast convergence. No requirement for CSPF based TE. Watch out though, the thing with Junos is that if you ever want to do IGP Shortcuts in the future, you need CSPF- enabled TE. Cisco allow you to run IGP Shortcuts (Autoroute Announce, as they call it) without CSPF. I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if anyone is actually using this in the field, if so what is the impression. How I'd love to do that, too :-). But, for now, we need RSVP-TE for p2mp LSP's re: running NG-MVPN's. I know mLDP is now shipping in Junos 11.2, but we're nowhere near moving to that line yet. But then again, we'll probably maintain RSVP- TE for IPTv traffic, but use mLDP for data-based Multicast services. Moroever, we're dealing with both Cisco and Juniper in different parts of the network, so although LFA/IP-FRR is cool in that node/link protection is locally significant to the box running it, we'd rather all boxes had support for maximum effect. As of now, some platforms do, some don't. We estimate we should be able to deploy it, across the board, in about 2 or 3 years. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IP/MPLS fast convergence
On Thursday, December 22, 2011 05:20:30 AM Phil Bedard wrote: As for the design it really depends on the SLA. If you do not need 50ms Traffic restoration LDP should work fine. On a metro network IGP convergence is pretty fast these days probably less than 500ms. Indeed. We run RSVP-TE only between the Aggregation routers (Juniper MX480's, M320's, T320's), with the core just processing those messages accordingly. As this is where our IPTv services terminate, it makes sense for us. We don't run RSVP in the Access (Cisco ME3600X's), just LDP. This runs between the Access switches in a ring, and terminates on the Aggregation routers at either end of the ring. We then tunnel LDP inside RSVP across to other rings, although the Aggregation routers also run LDP on all interfaces. We've simulated failures in the live networks across different rings and also within the same ring. And yes, IGP convergence can fall between 300ms - 750ms, give or take. We run BFD throughout the entire network, too. IGP is IS-IS. It is likely we could support RSVP-TE in the Access, but this would be a commercial decision, i.e., a customer requires 50ms failover across their protected l2vpn/l3vpn service - but this would be quite pricey to discourage the practice, as running RSVP is quite hectic. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
