Re: [j-nsp] EX 8200 deployment
On 21/03/10 02:03, Richard A Steenbergen wrote: We just deployed our first EX8208 a few days ago, running 10.1R1. Gotchas so far: * Obviously this is a very different architecture from Juniper's normal boxes, so be prepared for vlan space being shared across the entire box, not a per-interface basis. So far, apart from the MX I'm not aware of any Juniper gear that does switching with multiple VLAN spaces. * In a move straight out of Foundry's playbook of how to fail at making a useable product, EX has no packet counters (cli or snmp) available for L3 vlan interfaces. It DOES have working counters if you do traditional Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123 vlan-id 123), but it does NOT work if you have to do RVI style (vlan blah l3-interface vlan.123 and then put vlan blah in an ethernet switching interface). Subinterface style is my preference anyways, so as long as you only ever use vlans on point-to-point links this isn't a problem, but the instant you need to put a VLAN on more than one port you no longer get packet counters. Thank you for doing the testing on this, I was assuming this was a bug as I'd thought they couldn't be *that* stupid. To make things worse counters for vlan.XXX traffic are also only the traffic destined *to* the interface, not counting traffic routed *through*. * Related to the issue above, you can't mix subinterface style and RVI style vlans on the same trunk port. The instant you need to do anything more than classic subinterface style vlans, you have to convert everything on the trunk to vlan/rvi style. For example, where I might otherwise be able to get away with doing interface xe-1/0/0 unit 123 vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that same interface I now have to convert unit 123 to RVI style. One possible workaround I have yet to test is doing a CCC instead of a vlan, to keep the subinterface style. This would only work with 2-port member vlans though, and I have yet to test the implications for mixing tagged and untagged ports on EX, so this may not actually work for anyone at all. Either way please post. * Firewall filters are still a bit of a mess. You can't count or log anything, you can't use policers on either control plane or egress filters (heck you can't even commit a firewall filter with a policer in it if applied as an output filter), you can't match frags, etc, etc. Lack of outbound policers also makes it fairly useless in many roles where enforcing max bandwidth on a WAN link is required (At least here in Australia carriers complain if you actually dump 100Mbit of traffic on a 100Mbit point-to-point link). * I don't know who thought 2GB of storage on an RE was sufficient, but it isn't. The best idea I've come up with so far is to grab some small USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and deploy them on every RE so you have a little bit of working space. I've only just upgraded a bunch of stuff *to* 2GB, and don't have any real space issues. I would very much appreciate if Juniper would just give us two, externally accessible CF slots for storage and have that be it. Other than that we haven't found any fundamental flaws in the box yet (though that may change by the time MPLS features get implemented :P). Plenty of bugs to be sure, DOM isn't working right on any of our interfaces, pfe statistics don't work right, monitor interface on vlans isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried to speak BGP flowspec to the box, etc, but we have cases open on all of the above. IMHO it definitely has the potential to be a very good box in the long term, but whoever didn't think to put vlan counters into the hardware really screwed the pooch something fierce. :) So the EX (4200) bits from my personal list: * EX4200 - bootp relay doesn't work when configured inside a routing-instance, works when configured at top to use an instance * The commands in http://kb.juniper.net/index?page=contentid=KB13206cat=JUNOS_EXactp=LIST don't exist in 9.5 I'm mostly on 10.0R2.10, but all our EX's are still 9.5. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
Hi, ..straying a bit off topic.. On Sun, Mar 21, 2010 at 6:08 PM, Julien Goodwin jgood...@studio442.com.au wrote: So the EX (4200) bits from my personal list: * EX4200 - bootp relay doesn't work when configured inside a routing-instance, works when configured at top to use an instance Got bitten by this one a couple of weekends ago, during a big roll-out. Very counter-intuitive 'fix'. We had: set routing-instances blah-vr forwarding-options helpers bootp interface vlan.600 server 172.13.40.9 We actually needed: set forwarding-options helpers bootp interface vlan.600 server 172.13.40.9 routing-instance blah-vr cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
On Sun, Mar 21, 2010 at 06:08:33PM +1100, Julien Goodwin wrote: * Obviously this is a very different architecture from Juniper's normal boxes, so be prepared for vlan space being shared across the entire box, not a per-interface basis. So far, apart from the MX I'm not aware of any Juniper gear that does switching with multiple VLAN spaces. That's not exactly correct. For all intents and purposes MX is a much cheaper ethernet-optimized T640, with an extra layer of stuff added to let it do ethernet switching between some interfaces. Under that layer of stuff though, it is still the same basic architecture as a T-series, in which every interface has its own totally unique vlan space. On a M/T series you didn't have the ethernet switching component, but that has nothing to do with the vlan id space. This is completely and totally different from the architecture of a layer 3 switch (like a 6509, Nexus, Foundry, Force10, etc) which is at its core a layer 2 ethernet switch, with some stuff glued on to make it do routing. In a layer 3 switch the vlan space is shared globally across the box just like in a layer 2 switch, and when you want to route on an interface what you're actually doing is secretly stealing one of those 4096 box-wide vlans, using some hacks to do routing on it, and applying it as an access mode vlan to a single interface. The ironic part of the whole thing is that, as far as I understand at any rate, EX isn't actually a layer 3 switch architecture like the rest of those boxes. In Juniper's rush to get into the enterprise switch market, it seems like they decided to copy the other enterprise-marketed switches out there, bad designs and all. At the end of the day it doesn't really matter, most of us are comparing this to similar boxes in the market segment which have the same limitations (Nexus 7k, etc), it's just something people coming from other Juniper products need to know. Thank you for doing the testing on this, I was assuming this was a bug as I'd thought they couldn't be *that* stupid. To make things worse counters for vlan.XXX traffic are also only the traffic destined *to* the interface, not counting traffic routed *through*. Correct. I actually found some old gripes about this when I searched j-nsp after noticing the problem, but it is a big enough issue that I think it needs to be repeated again (and again and again, until it gets fixed :P). At one point I work working on an sflow to snmp emulator for some of my poor Foundry-using friends who can't bill customers landing on vlans, may end up having to dust that off as a workaround for the EX design flaw. Lack of outbound policers also makes it fairly useless in many roles where enforcing max bandwidth on a WAN link is required (At least here in Australia carriers complain if you actually dump 100Mbit of traffic on a 100Mbit point-to-point link). I believe this is just a current limitation of the software, not a flaw in the design of the hardware, so it should be coming soon. Again, just something people need to be aware of, since as you say it can be a big problem if you need those features. :) I've only just upgraded a bunch of stuff *to* 2GB, and don't have any real space issues. I would very much appreciate if Juniper would just give us two, externally accessible CF slots for storage and have that be it. I'm talking about the EX8200 here, which has 2GB of DRAM, not a stackable box. When the thing crashes, where do you plan to write the kernel panic file? I wasn't even able to work with my 512mb rpd coredump, not enough free space to uncompress the tarball. Maybe you aren't a power user and you don't notice the issue right now, but trust me this is a setup for a lot of problems in the future. So the EX (4200) bits from my personal list: * EX4200 - bootp relay doesn't work when configured inside a routing-instance, works when configured at top to use an instance * The commands in http://kb.juniper.net/index?page=contentid=KB13206cat=JUNOS_EXactp=LIST don't exist in 9.5 I'm mostly on 10.0R2.10, but all our EX's are still 9.5. I'm more interested in the 8200 than the 4200, so we haven't done that much interesting testing on the 4200, but what I can tell (for the sake of the mailing list archives) you is that the 3200/4200 and 8200 are two different revisions of the same family of ASICs, with different feature supported by the hardware, and different levels of support in software for those two different revisions of hardware. What 3200/4200 does is not necessarily the same as what 8200 does. -- 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
Re: [j-nsp] EX 8200 deployment
* Richard A Steenbergen Correct. I actually found some old gripes about this when I searched j-nsp after noticing the problem, but it is a big enough issue that I think it needs to be repeated again (and again and again, until it gets fixed :P). I'll be happy to join the choir on this one. I reported the problem back in March 2009, got PR 435648 opened, but haven't heard anything more since then. My workaround is to terminate the customer VLANs that needs counters for accounting purposes on the EX-es' upstream routers instead, which are MX-es with standard vlan-tagged family inet sub-interfaces. That works well enough but it's not as tidy as I would have preferred. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
So the EX (4200) bits from my personal list: * EX4200 - bootp relay doesn't work when configured inside a routing-instance, works when configured at top to use an instance Got bitten by this one a couple of weekends ago, during a big roll-out. Very counter-intuitive 'fix'. We had: set routing-instances blah-vr forwarding-options helpers bootp interface vlan.600 server 172.13.40.9 We actually needed: set forwarding-options helpers bootp interface vlan.600 server 172.13.40.9 routing-instance blah-vr This is *not* specific to EX, the same applies to the M series. However, the Extended DHCP Relay functionality (forwarding-options dhcp-relay) needs to be configured under the routing-instance. Isn't consistency wonderful? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
Everyone, you do realize that the EX switches were designed to get Juniper into the enterprise switching market (although poorly). This is what they are doing, Don't expect features of the MX to show up. As of the current software offering the EX 8200 isn't even up to par with a 6500 feature wise yet. While its not the best at everything, the 6500 is a swiss army knife. Its going to take quite a bit of time to be at the same level. Then also take the fact that the 6500 is dead as a strategic platform. The Nexus 7k is the new boy on the block. Juniper needs to push features and hardware faster to keep up, yet sadly I don't think they're doing it. --Original Message-- From: Stefan Fouant Sender: juniper-nsp-boun...@puck.nether.net To: mti...@globaltransit.net To: juniper-nsp@puck.nether.net Cc: Richard A Steenbergen ReplyTo: sfou...@shortestpathfirst.net Subject: Re: [j-nsp] EX 8200 deployment Sent: Mar 20, 2010 11:27 PM Chassis-wide VLAN space? Great!... Juniper just managed to build a Cisco 6509 ;) Stefan Fouant Sent from my Verizon Wireless BlackBerry -Original Message- From: Mark Tinka mti...@globaltransit.net Date: Sun, 21 Mar 2010 03:23:41 To: juniper-nsp@puck.nether.net Cc: Richard A Steenbergenr...@e-gerbil.net Subject: Re: [j-nsp] EX 8200 deployment ___ 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 Sent via BlackBerry by ATT ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
Yes, you are correct. The Cat6500 has some new hardware coming to it, however it's still going to be the Cat6500 at the end of the day. Still using IOS, still integrating with older line cards, etc.. The Cat6500 has served my company for years, we have thousands in production ranging from Sup1a to the Sup720 series, CatOS to IOS, etc.. While it has served us, along with bringing many headaches, it's time to move on to the new age. You are right though, currently we're only replacing out Cat6500's in the data centers as we just cannot get the reliability, 10GigE density and support for CEE/DCB (future 7K cards) that the N7K has/will bring.. The fact that we can do ISSU is huge for us.. I believe the EX8200 is on track to have ISSU support in 2011. However in the corp environment, we're still using Cat6500's. I honestly would like to see us start to use stackables. The access tier is a commodity anymore, there is no reason to have a high dollar box. We completed a RFP late last year and we reviewed Brocade(Foundry), Cisco and Juniper's latest offering. We found that the EX8200 didn't have some critical features that our 6500's have, so it was almost an immediate no. I wish somehow Juniper would realize this and put more resources into the EX series. It has TONS of potential, just little pushing on the product side.. Cisco is going to release the 2nd gen of Nexus 5K later this year. Cisco is also releasing a whole new line of modules for the 7K, new fabric extenders, etc.. That is just for the Nexus series. As you stated they're bringing new hardware to the Cat6500 as well. Juniper doesn't have any new modules for the EX8200 series, I've heard rumor of a high density 10Gig module, but it seems to be vaporware. No plans (as of now) to support CEE/DCB. The EX4500 platform is barely in beta stage.. The list goes on, they're moving too slow! Very FRUSTRATING! Currently we only use Juniper products for SSLVPN, Internet edge and some other minor roles, I'd like to see them have more of a play in our environment. How can I bring another switch vendor into my environment when the new box doesn't do what I have now and will be outdated in a short time frame. It's a very hard thing to justify. On Sun, Mar 21, 2010 at 10:15 AM, Mark Tinka mti...@globaltransit.netwrote: On Sunday 21 March 2010 08:52:54 pm chrisccnpsp...@gmail.com wrote: Then also take the fact that the 6500 is dead as a strategic platform. The Nexus 7k is the new boy on the block. You've probably heard that the 6500 will be getting a new switch fabric/supervisor module which should resolve a lot of the hardware limitations seen in the current EARL (for all intents and purposes, it should be the same EARL being used on the Nexus 7000 series platforms). It probably makes more sense for anyone looking at a new 6500 to consider the Nexus 7000 for a number of reasons, least of which isn't the potential for future 40Gbps and 100Gbps Ethernet support. But Cisco will still get customers for the new fabric, especially existing 6500 folk. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
On Sunday 21 March 2010 08:52:54 pm chrisccnpsp...@gmail.com wrote: Then also take the fact that the 6500 is dead as a strategic platform. The Nexus 7k is the new boy on the block. You've probably heard that the 6500 will be getting a new switch fabric/supervisor module which should resolve a lot of the hardware limitations seen in the current EARL (for all intents and purposes, it should be the same EARL being used on the Nexus 7000 series platforms). It probably makes more sense for anyone looking at a new 6500 to consider the Nexus 7000 for a number of reasons, least of which isn't the potential for future 40Gbps and 100Gbps Ethernet support. But Cisco will still get customers for the new fabric, especially existing 6500 folk. 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
[j-nsp] Shutting Down a Network and Selling off Assets
Hello everyone, This might be slightly off topic, but I am shutting down a large network, and selling off the assets. Information is @ www.ronan-online/forsale.html I will be adding items to the list as they come offline, as well as the location of each asset. Email me with any questions or offers. Shane Ronan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Shutting Down a Network and Selling off Assets
www.ronan-online.com/forsale.html On Mar 21, 2010, at 7:10 PM, Shane Ronan wrote: Hello everyone, This might be slightly off topic, but I am shutting down a large network, and selling off the assets. Information is @ www.ronan-online/forsale.html I will be adding items to the list as they come offline, as well as the location of each asset. Email me with any questions or offers. Shane Ronan ___ 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
