Re: [j-nsp] EX2200 OSPF question
On Wednesday, May 22, 2013 11:17:29 PM Paul Stewart wrote: You have to buy the extended feature license on the EX2200 to run OSPF. We have a bunch of EX2200-C deployed that have OSPF routes on them and they work fine - to qualify that though, there is very little traffic through them at layer3 - cant' see them handling much layer3 traffic. That deployment is mainly layer2 oriented. It's a shame that Juniper make you pay for an IS-IS license to run it on the lower-/mid-end EX platforms, yet all an operator might want that for is management access. Maybe some bright soul at Juniper will come up with yet- another-license where we can run IS-IS in management access mode. Granted, all you'll get today, if you turn it on, is complaints about it not having a license, but Juniper are now seriously threatening software enforcement in upcoming code. 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] ISSU timeouts on MX upgrades due to large routing tables?
I have an MX960, full routes, performed issu. Did not have a timeout problem. However, like Ras eluded to, other issues...Once the backup routing-engine upgrades and takes primary RE position, the used-to-be primary upgrades itself. You would think everything is fine with a new primary RE but the chassis goes into alarm still saying the backup is active like it switched for a failure event. JTAC says I have to switch it back to the old primary to get the alarm to clear. Why can't I run the 'new' primary for a while? - Original Message - From: Richard A Steenbergen r...@e-gerbil.net To: Clarke Morledge chm...@wm.edu Cc: juniper-nsp@puck.nether.net Sent: Wednesday, May 22, 2013 5:44:03 PM Subject: Re: [j-nsp] ISSU timeouts on MX upgrades due to large routing tables? On Tue, May 21, 2013 at 09:01:57PM -0400, Clarke Morledge wrote: I was curious to know if anyone has run into any issues with large routing tables on an MX causing ISSU upgrades to fail? On several occasions, I have been able to successfully do an In-Software-Service-Upgrade (ISSU) in a lab environment but then it fails to work in production. I find it difficult to replicate the issue in a lab, since in production I am dealing with lots of routes as compared to a small lab. Does anyone have any experience when the backup RE gets its new software, then reboots, but since it takes a long time to populate the routing kernel database on the newly upgraded RE that it appears to timeout? I have seen behavior like this with upgrades moving from 10.x to a newer 10.y and from 10.x to 11.y. We had that issue for many years. There is a hard-coded timeout in the NSR process which is very easy to hit if you have a box with a large number of routes. We had a case open on it for about 1.5 years, but Juniper refused to actually fix it (it works fine in the lab), and eventually we just gave us and declared ISSU to be dead. There are way too many other bugs with it anyways, even turning on NSR caused nothing but problems. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] experience using 10G DAC (twinax) cables between EX and multi-vendor
* Andy Litzinger andy.litzin...@theplatform.com [2013-05-15 21:00]: Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor gear? Did you use Juniper DAC cables or the other vendor cables? In particular I'm planning on linking a Cisco UCS Fabric Interconnect and also an F5 BigIP 4200v to a VC of EX4550s. would you recommend it or should I fork over the money to use optics? Hi, we use DAC between EX4500 and Intel servers without problem. We use Flexoptics cables where both ends of the cable can be flashed to diferent vendors. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISSU timeouts on MX upgrades due to large routing tables?
On 05/23/2013 09:25 AM, Mike Azevedo wrote: I have an MX960, full routes, performed issu. Did not have a timeout problem. However, like Ras eluded to, other issues...Once the backup routing-engine upgrades and takes primary RE position, the used-to-be primary upgrades itself. You would think everything is fine with a new primary RE but the chassis goes into alarm still saying the backup is active like it switched for a failure event. JTAC says I have to switch it back to the old primary to get the alarm to clear. Why can't I run the 'new' primary for a while? You can. Just switch the master/backup relationship in the configuration, and the alarm clears. -- Byron Hicks Lonestar Education and Research Network office: 972-883-4645 google: 972-746-2549 aim/skype: byronhicks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX connectivity between Routing Instances
I'm working on a routing design that uses multiple routing instances to allow traffic shaping based on destination, CG Nat based on destination and a set of traffic filters. Those three things don't tend to play very nicely together on the same interface since they're all require various firewall filters and even service filters. Has anyone built any interesting routing instance configurations to accomplish this? Previously I was going to have a physical loop that ran through an IPS, which gave me an extra pair of physical interfaces to work with. I've migrated that service elsewhere, so now I need to research how much I can do on logical tunnel interfaces. Thoughts? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How useful is Juniper storm control?
Date: Tue, 14 May 2013 14:29:35 + From: James S. Smith jsm...@windmobile.ca Subject: [j-nsp] How useful is Juniper storm control? I'm looking for people's experience with storm control on Juniper switches. We have a pair of EX4500 switches and I notice that storm control kicks in a lot. I'm concerned that it might be stopping legitimate broadcast and multicast traffic. Depends on what you consider legitimate, both quality and quantity wise. MS Windows NLB (Network Load Balancing) floods stuff, so I have ~250Mbps minimum of flooded traffic on that VLAN... We disabled storm control on the ports in that specific VLAN, and yes, we really will do normal loadbalancing if I can get the Exchange admins to budge... Do most people have storm control enabled or disabled? Enabled, it can prevent other bad stuff, like looped traffic, not per se a loop on the specific switch. Plus, it's a switch, not a hub. :) Kind regards, JP Velders ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How useful is Juniper storm control?
Date: Tue, 14 May 2013 14:29:35 + From: James S. Smith jsm...@windmobile.ca Subject: [j-nsp] How useful is Juniper storm control? I'm looking for people's experience with storm control on Juniper switches. We have a pair of EX4500 switches and I notice that storm control kicks in a lot. I'm concerned that it might be stopping legitimate broadcast and multicast traffic. Depends on what you consider legitimate, both quality and quantity wise. MS Windows NLB (Network Load Balancing) floods stuff, so I have ~250Mbps minimum of flooded traffic on that VLAN... We disabled storm control on the ports in that specific VLAN, and yes, we really will do normal loadbalancing if I can get the Exchange admins to budge... Do most people have storm control enabled or disabled? Enabled, it can prevent other bad stuff, like looped traffic, not per se a loop on the specific switch. Plus, it's a switch, not a hub. :) Kind regards, JP Velders ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
