Re: [j-nsp] Redundancy with MX
On Friday, January 25, 2013 09:46:28 AM Saku Ytti wrote: Still I'd be afraid that the added complexity bites me more often than saves me. I have to agree - I'd rather buy another chassis to solve my problems than implement logical systems (SDR in the Cisco world). I'm also still waiting for some justification as to why this would be useful beyond the obvious (I know many folk that like this type of thing). Looking at all the restrictions involved, what may or may not work, what may or may not break, for me, it's like ISSU - nice on paper but not very practical. 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] Redundancy with MX
On Friday, February 01, 2013 10:28:13 PM Eugeniu Patrascu wrote: I would go with the two MX80s and two L2 switches to aggregate all connections. I did a design like this with 2 x MX80 and 2 x EX4500 in a stack (only L2 aggregation, routing done on the MX).The switches would be connected to the MX80s by 10G ports (2 for IN, 2 for OUT - in each MX80) - connected in a MC-LAG to the EX4500 stack. Redundancy all the way :) Yes, you would have to play with the routing protocols to balance traffic at some point if you saturate one of your links in the MX, but that would only happen if you want to do more than 20G one way. The above is a reasonable design. We structure ours based on small, medium or large edge sites, where it doesn't yet make sense to launch a full PoP with core routers, route reflectors, e.t.c. This would typically be a new PoP where we're going in on the back of a handful of customers, but not big enough yet to use as a transit PoP for major traffic flow in the global scheme of things. My main issue with the MX80 is low 10Gbps density, if the box is a collapsed P/PE device, handling both customers as well as core traffic. In such cases, provided there is space, the MX480 has been considered from the Juniper side. Cisco ends up providing more flexibility with their ASR1006 platform, which can then later be scaled to an ASR9000 for a large edge PoP, pre-full PoP design. It really depends on: - How small or large you expect your PoP to be. - How much you plan to make in sales. - How many core links come in. - How fast those core links will be. 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] Redundancy with MX
On Mon, Jan 21, 2013 at 10:40 PM, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? I would go with the two MX80s and two L2 switches to aggregate all connections. I did a design like this with 2 x MX80 and 2 x EX4500 in a stack (only L2 aggregation, routing done on the MX).The switches would be connected to the MX80s by 10G ports (2 for IN, 2 for OUT - in each MX80) - connected in a MC-LAG to the EX4500 stack. Redundancy all the way :) Yes, you would have to play with the routing protocols to balance traffic at some point if you saturate one of your links in the MX, but that would only happen if you want to do more than 20G one way. Cheers, Eugeniu ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
Ouch… I picked a single MX480 chassis design over a dual MX80 because of the unavailability of the MS-DPC card in the MX80. We're very new to Juniper here with close to no practical experience. Nonetheless, we're migrating away from Brocade NetIron MLX to the MX and we figured that dual RE and SCB would helpful relative to ISSU and NSR but I guess the general consensus is that it's preferable to have separate routers over redundant RE's. I'm wondering though, would dividing some of the routing duties into logical systems help to protect from a massive system-wide problem? From what I understand the logical systems spin up their own set of processes and have their own configuration so it would seem that there could be some level of protection. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
There are some per-logical-system processes but there are also some that are chassis wide. Logical systems also do not support some features, including I believe most MS-DPC functions, FA-LSPs (go figure) and some others. You will also always have a single cos and chassis process for all logical systems so no real help for a crash there. Also, maintenance/provisioning tools will almost never work properly with logical systems for some reason or another so I would recommend keeping logical systems limited to the lab for testing larger scenarios on less equipment.. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stephen Hon Sent: Friday, 25 January 2013 9:53 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Redundancy with MX Ouch... I picked a single MX480 chassis design over a dual MX80 because of the unavailability of the MS-DPC card in the MX80. We're very new to Juniper here with close to no practical experience. Nonetheless, we're migrating away from Brocade NetIron MLX to the MX and we figured that dual RE and SCB would helpful relative to ISSU and NSR but I guess the general consensus is that it's preferable to have separate routers over redundant RE's. I'm wondering though, would dividing some of the routing duties into logical systems help to protect from a massive system-wide problem? From what I understand the logical systems spin up their own set of processes and have their own configuration so it would seem that there could be some level of protection. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
On 1/24/13 2:53 PM, Stephen Hon wrote: Ouch… I picked a single MX480 chassis design over a dual MX80 because of the unavailability of the MS-DPC card in the MX80. yeah that's a consideration if you need an msdpc. We're very new to Juniper here with close to no practical experience. Nonetheless, we're migrating away from Brocade NetIron MLX to the MX and we figured that dual RE and SCB would helpful relative to ISSU and NSR but I guess the general consensus is that it's preferable to have separate routers over redundant RE's. dual RE and and NSR work and are useful... if you every have to replace a failing cb or RE and you do so without a hitch, you'll be pretty impressed. software upgrades even without ISSU are simpler and less impactful (and easier to recover from) than with only one RE that said tradeoffs are tradeoffs and everyone has a slightly different point at which they compromise to meet their price/availability/functional needs. I'm wondering though, would dividing some of the routing duties into logical systems help to protect from a massive system-wide problem? From what I understand the logical systems spin up their own set of processes and have their own configuration so it would seem that there could be some level of protection. ___ 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] Redundancy with MX
Are you looking to do active-standby or active-active mc-lag? On Mon, Jan 21, 2013 at 3:48 PM, Andre Christian andre.christ...@o3bnetworks.com wrote: Marcus - I am building about 10 PoPs and opted for the dual mx-80 design. Also looked at making the PoPs all layer 2 with a pair of exs. Plan to use MC-LAG where applicable. On Jan 21, 2013, at 3:43 PM, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
On (2013-01-24 17:53 -0500), Stephen Hon wrote: I'm wondering though, would dividing some of the routing duties into logical systems help to protect from a massive system-wide problem? From what I understand the logical systems spin up their own set of processes and have their own configuration so it would seem that there could be some level of protection. I would personally avoid lsys as much as possible. I would not out-right ban the feature, but I would want extremely good justification for it, I haven't figured out one yet, but I'm sure there are reasons to run it. But you are right, each lsys runs own copy of RPD. And this is probably only way to use more than 4GB of memory today. I'm sure there are some failure scenarios where fault won't propagate across LSYS borders. Like maybe one LSYS is VPN BGP and another is INET BGP, and when some UPDATE from DFZ crashes your INET RPD possibly VPN RPD is alive and kicking. Still I'd be afraid that the added complexity bites me more often than saves me. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
On 1/21/13 11:44 PM, Saku Ytti wrote: On (2013-01-21 21:40 +0100), Markus H wrote: I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. a) 2xMX80 b) 1xMX240/480 with redundant SCB and RE a) no question. As long as you can live with modest RE performance of MX80. Routing separated two units always better than stateful single unit. Frankly, I'm not sure if dual RE even delivers better MTBF, since it does expose you to new issues, even outside HW failures. It probably does deliver you better MTTR though. I would always take two routers over one router with two RE's I have Lost RE's or crashed them in ways that a second RE helped enough to consider them worthwhile, and sometimes they make upgrading easier, but sometimes they make it harder, and it's pretty easy to justify trading lower cost and less complexity for modularity. The original poster I think raised the issue of load balancing between upstream(s). realistically that isn't that hard if you're architecture is designed to account for it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Redundancy with MX
Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
Marcus - I am building about 10 PoPs and opted for the dual mx-80 design. Also looked at making the PoPs all layer 2 with a pair of exs. Plan to use MC-LAG where applicable. On Jan 21, 2013, at 3:43 PM, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ 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] Redundancy with MX
Any constraints? Power? Bandwidth? What's the driver/function? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 21 Jan 2013, at 20:40, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ 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] Redundancy with MX
On (2013-01-21 21:40 +0100), Markus H wrote: I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. a) 2xMX80 b) 1xMX240/480 with redundant SCB and RE a) no question. As long as you can live with modest RE performance of MX80. Routing separated two units always better than stateful single unit. Frankly, I'm not sure if dual RE even delivers better MTBF, since it does expose you to new issues, even outside HW failures. It probably does deliver you better MTTR though. jabbering: I've been installing 8 MX960 in last week and this week, 5/8 of them suffered from some type of FW misprogram. They were delivered with export software, so field-tech pushed template config, disabled lo0 filter and enabled telnet, to allow remote management. After remotely over telnet upgrading RE (no ISSU) and swapping or reloading master RE, I found that RE filter was again enabled, even though it was not seen in config I could observe my telnet packets hitting discard term couter of filter which wasn't on any interface. Fix was 'commit full'. I've seen other issues too, affecting transit traffic too, post-upgrade. I've not yet lost RE due to HW failure though. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
