Re: [j-nsp] EX Switch Question
On Monday, April 01, 2013 05:44:59 PM Pavel Lunin wrote: Well, I'd also really like to have a Juniper box competing against Catalyst ME, but, again, I believe there might be (I don't say there is) some common sense in not even trying to play this game. I can easily imagine sane reasons for which they decided to spend money and time on ACX (PTX, QFabric, WiFi) instead of just trying to catch up Cisco, Extreeme and others in the straightforward ME game. I think if Juniper have decided to consciously not play in this space, that's fine by me. A lot of folk are gung-ho on having a single vendor do everything for them. I prefer to have multiple vendors wherever I can; this just means that for the most part, Cisco will win my business for Metro-E deployments, which is not something I'm entirely happy with, but can live with. Others who are Juniper 100% of the way may not be as pleased, but I guess they'll either pay more to stick with Juniper, or be forced to deploy boxes they would never like to see. To each his own. It's really interesting, that you say 2RU is too much for MX80. I never heard such a claim from a customer. At least, it's never been a serious problem. Much more often they ask whether it fits into a 60 cm deep rack and how much power it eats. I think, the lack of this requirement comes from completely different economics of real estate, access networks structure and all. In many countries (where telecom markets are emerging) access network is often an interconnection of places like this: http://nag.ru/upload/images/20519/1877875733.jpeg In a hell I'd put there something closely priced to MX5, be it 1 or 2 RU height :) So people often come up using something extremely cheap in the PoPs (don't even think MPLS) and aggregate them in a location, where 1 or 2 RU doesn't make much difference. In many deployments I've made, the rack space can also be an issue. In many places, power isn't the only premium in data centres. 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] EX Switch Question
On Tuesday, April 02, 2013 04:34:18 PM Pavel Lunin wrote: I just wanted to note, that from the money point of view at the time when MX80 was under construction, it /could/ be a wise decision to not compete against products like CES/CER and make it more router-alike than a MetroE optimized device. In fairness, the Cisco ME3600X/3800X is really a router. A lot of issues in the beginning mostly based on lack of features due to the software being fresh, but that has mostly been addressed, and only kinky stuff and bug fixes is what's coming in now. I doubt you will find any other switch from Cisco that is claimed as a Metro-E access platform that does the all QoS you'll find on software-based IOS platforms. 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] EX Switch Question
I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. Well, don't get me wrong. MPLS in the access is a lovely thing and I really understand what Mark from Juniper. Moreover I personally hate all the plain ethernet garbages in the access (people tend to insert more tiers on the way from access switch to the MX-like router because they can't connect every basement to an aggregation point and it just breaks the whole idea of access network). I just wanted to note, that from the money point of view at the time when MX80 was under construction, it /could/ be a wise decision to not compete against products like CES/CER and make it more router-alike than a MetroE optimized device. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
31.03.2013 18:18, Mark Tinka wrote: On Friday, January 11, 2013 01:41:47 PM Pavel Lunin wrote: Looks like Juniper just did not much care metro ethernet. BTW, it's sometimes said, that the reason is a lack of such a market in North America (where I've even never been to, thus can't judge whether this sentence is correct :). Another reason (more serious, I would say) is a strong Juniper's position in the MPLS battle, which doesn't allow them to invest much into the plain ethernet metro access technologies to not kill the goose that lays the golden eggs (from the pure engineering point of view there is also some logics in such an approach). Well, Cisco must be seeing some market that Juniper aren't, considering these are both American companies. It was just the story as I heard it. I don't know really how right this statement is (and for me it also seem a bit strange). Generally speaking American company does not mean make most money in the North America though I have no idea how different the ratios of NA/other are for Cisco and Juniper these days. I think more correctly this idea sounds like Juniper don't believe they can earn money on ME market for whatever reason. At least for me, not playing the MetroE game seems to be a conscious decision, not an oversight. Maybe just same story as the VoIP, where Cisco successfully played for ages and Juniper gave up completely after a couple of silly attempts (my special thanks to Juniper for deliverance from the SRX converged services nightmare). When the MX80 was still codenamed Taz, and all we got to test was a board with no chassis, I asked Juniper to rethink their idea about a 1U solution for access in the Metro, especially because Brocade had already pushed out the CER/CES2000, Well, as I involved into selling both Juniper and Brocade, from this perspective I can say, Juniper's decision was just right :) I love CES/CER but when it comes to real competition with MX5-80, there are really few chances for Brocade. Small MX usually costs about the same in a comparable configuration. A bit more expensive, but Brocade is by far #3 in terms of MPLS features and all. Some exceptional niches exist, also Brocade is going to launch a 4×10GE ports CER, but generally it's really hard to position CER against MX/ASR and CES against Catalyst ME or, say, Extreme X460. and Cisco were in the final stages of commissioning the ME3600X/3800X, at the time. Well, I'd also really like to have a Juniper box competing against Catalyst ME, but, again, I believe there might be (I don't say there is) some common sense in not even trying to play this game. I can easily imagine sane reasons for which they decided to spend money and time on ACX (PTX, QFabric, WiFi) instead of just trying to catch up Cisco, Extreeme and others in the straightforward ME game. Epic fail on Juniper's part to think that networks will still go for too big boxes for small box deployments. The ERBU head promised that they were looking at a 1U MX80 box that would rival the Cisco and Brocade options in the access, but I think they thought coming up with the MX5, MX10 and MX40 were far better ideas :-\. It's really interesting, that you say 2RU is too much for MX80. I never heard such a claim from a customer. At least, it's never been a serious problem. Much more often they ask whether it fits into a 60 cm deep rack and how much power it eats. I think, the lack of this requirement comes from completely different economics of real estate, access networks structure and all. In many countries (where telecom markets are emerging) access network is often an interconnection of places like this: http://nag.ru/upload/images/20519/1877875733.jpeg In a hell I'd put there something closely priced to MX5, be it 1 or 2 RU height :) So people often come up using something extremely cheap in the PoPs (don't even think MPLS) and aggregate them in a location, where 1 or 2 RU doesn't make much difference. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Epic fail on Juniper's part to think that networks will still go for too big boxes for small box deployments. The ERBU head promised that they were looking at a 1U MX80 box that would rival the Cisco and Brocade options in the access, but I think they thought coming up with the MX5, MX10 and MX40 were far better ideas :-\. It's really interesting, that you say 2RU is too much for MX80. I never heard such a claim from a customer. At least, it's never been a serious problem. Much more often they ask whether it fits into a 60 cm deep rack and how much power it eats. I think, the lack of this requirement comes from completely different economics of real estate, access networks structure and all. In many countries (where telecom markets are emerging) access network is often an interconnection of places like this: http://nag.ru/upload/images/20519/1877875733.jpeg In a hell I'd put there something closely priced to MX5, be it 1 or 2 RU height :) So people often come up using something extremely cheap in the PoPs (don't even think MPLS) and aggregate them in a location, where 1 or 2 RU doesn't make much difference. I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On 2 April 2013 09:06, Ben Dale bd...@comlinx.com.au wrote: I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. When the ex2200C came out, I considered it as a Metro-E CPE / demarc device. It was missing to many features for that role at the time and lost out to devices targeted for that market such as the T-marc 340 or an ADVA FSP(?). As much as disliked working on the T-marcs, they were cheap and it was easy enough to dump a template on it and never touch them again. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On Friday, January 11, 2013 01:41:47 PM Pavel Lunin wrote: Looks like Juniper just did not much care metro ethernet. BTW, it's sometimes said, that the reason is a lack of such a market in North America (where I've even never been to, thus can't judge whether this sentence is correct :). Another reason (more serious, I would say) is a strong Juniper's position in the MPLS battle, which doesn't allow them to invest much into the plain ethernet metro access technologies to not kill the goose that lays the golden eggs (from the pure engineering point of view there is also some logics in such an approach). Well, Cisco must be seeing some market that Juniper aren't, considering these are both American companies. Needless to say, Cisco have a healthy support for both MPLS- based and MEF-/Carrier Ethernet-based Metro-E solutions in their latest platforms targeted at this space. With the launch of ACX series things might change and a reasonably cheap JUNOS-based metro ethernet-over-MPLS solution might become available, but this is a deal of a few quarters ahead, as I understand. When the MX80 was still codenamed Taz, and all we got to test was a board with no chassis, I asked Juniper to rethink their idea about a 1U solution for access in the Metro, especially because Brocade had already pushed out the CER/CES2000, and Cisco were in the final stages of commissioning the ME3600X/3800X, at the time. Epic fail on Juniper's part to think that networks will still go for too big boxes for small box deployments. The ERBU head promised that they were looking at a 1U MX80 box that would rival the Cisco and Brocade options in the access, but I think they thought coming up with the MX5, MX10 and MX40 were far better ideas :-\. I think Juniper will get with the program, but the damage will have long been done (especially, as we have now come to expect, you can't just roll-out current code on new boxes - it takes a while to break them in even with basic parity). It's for the same reason I can't fathom why they still have no answer to Cisco's ASR1000. Even just for route reflection, I'd be very hard-pressed to choose a US$1 MX480 with a 16GB RE over a Cisco ASR1001 costing ten thousand times the price. C'mon, Juniper. 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] EX Switch Question
On Sunday, March 31, 2013 05:28:02 PM Jeff Wheeler wrote: Just problem #1 clearly demonstrates that upper-management has no idea what they are doing. They are managing their inventory like they're making automobiles with razor-thin margins, not I.T. products which sell for many multiples of the manufacturing and logistics cost. Not only that, but they have no systemic way for customers to expedite orders (and generate revenue / additional margin from such expedites), which is just leaving money on the table. I suffered this exact issue last December. 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] EX Switch Question
On Sun, Mar 31, 2013 at 10:18 AM, Mark Tinka mark.ti...@seacom.mu wrote: no answer to Cisco's ASR1000. Even just for route reflection, I'd be very hard-pressed to choose a US$1 MX480 with a 16GB RE over a Cisco ASR1001 costing ten thousand times the price. These are all symptoms of Juniper's incompetent management. * inability to manage supply chain logistics, leading to 6 month lead times on incredibly high-margin products * essentially no software Q/A * consistently failing to deliver on software commitments / roadmap * big gaps in the product line that could be fixed easily, but aren't * far worse TAC than competitors * refusal to admit basic, obvious, and huge bugs exist so they can be fixed * widespread ineptitude in the sales and sales-support force * misplaced RD efforts * basic features that customers require missing from products *by choice* while competitors have those features Just problem #1 clearly demonstrates that upper-management has no idea what they are doing. They are managing their inventory like they're making automobiles with razor-thin margins, not I.T. products which sell for many multiples of the manufacturing and logistics cost. Not only that, but they have no systemic way for customers to expedite orders (and generate revenue / additional margin from such expedites), which is just leaving money on the table. They cannot even solve the basic, easily-fixed problems with their business. I have little faith in Juniper's long-term future. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
So is there anything reasonably priced in the Juniper lineup for this kind of situation or do we look at Cisco/other? If a bunch of MX5's doesn't fit the price expectation, than, I would say, Cisco/other. Looks like Juniper just did not much care metro ethernet. BTW, it's sometimes said, that the reason is a lack of such a market in North America (where I've even never been to, thus can't judge whether this sentence is correct :). Another reason (more serious, I would say) is a strong Juniper's position in the MPLS battle, which doesn't allow them to invest much into the plain ethernet metro access technologies to not kill the goose that lays the golden eggs (from the pure engineering point of view there is also some logics in such an approach). With the launch of ACX series things might change and a reasonably cheap JUNOS-based metro ethernet-over-MPLS solution might become available, but this is a deal of a few quarters ahead, as I understand. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX Switch Question
Hi folks.. We have a customer that has a Cisco 6500 - very old and they want to retire it out of service (12+ years old). The customer is a municipal fiber provider and their main business is providing connectivity (vs providing Internet). They have approached us about a Juniper replacement and I've been thinking about EX series but looking for some input please. Their requirements are what would seem fairly basic: 40-50 switch ports supporting up to 1G (all copper today as they use media converters and wish to continue using them) Dot1q support on each port (yup, easy enough) Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) When I have looked at the EX2200,3300,4200 series (which I'm reasonably familiar with) I don't see a way to do this. Our Juniper SE says the issue is ingress bandwidth control and that the rest of the criteria is easily met. As they also would prefer and are also used to having a chassis level box with power redundancy, switch processor redundancy etc then this has me looking at EX6200/8200 series. The EX6200 seems to be pretty much EX4200 modules so not sure if it solves my problem - thinking more towards EX8200 but not familiar enough to know if it will meet this criteria especially ingress *and* egress per VLAN bandwidth controls. Any thoughts are much appreciated ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Just avoid the 4500 if you need anything less than 1G copper. The ports on the 4500 won't negotiate to 10 or 100. I was told by the sales engineer that this switch is a top of rack switch so it doesn't support anything less than 1G. I found that funny since I have a whole rack of Avaya gear that Avaya insists must have the switch set to 100/Full. - Original Message - From: Tobias Heister [mailto:li...@tobias-heister.de] Sent: Thursday, January 10, 2013 08:31 AM To: Paul Stewart p...@paulstewart.org Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ 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] EX Switch Question
Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul -Original Message- From: Per Granath [mailto:per.gran...@gcc.com.cy] Sent: January-10-13 9:18 AM To: Paul Stewart; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] EX Switch Question The general idea is to do: Policing (firewall filter) on ingress Shaping (CoS) on egress http://www.juniper.net/us/en/local/pdf/implementation-guides/8010073-en.pdf Shaping is typically per port, and I am not sure if you can do that per VLAN. But the feature guide say there is CoS support on RVIs... https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/conc ept/ex-series-software-features-overview.html#cos-features-by-platform-table In that case, the EX4200 virtual chassis seems good. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, January 10, 2013 3:04 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX Switch Question Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thanks - yup, we are just deploying some EX4500 at a customer site and ended up keeping their EX4200's just for 100 meg ports ;( -Original Message- From: James S. Smith [mailto:jsm...@windmobile.ca] Sent: January-10-13 9:00 AM To: 'li...@tobias-heister.de'; 'p...@paulstewart.org' Cc: 'juniper-nsp@puck.nether.net' Subject: Re: [j-nsp] EX Switch Question Just avoid the 4500 if you need anything less than 1G copper. The ports on the 4500 won't negotiate to 10 or 100. I was told by the sales engineer that this switch is a top of rack switch so it doesn't support anything less than 1G. I found that funny since I have a whole rack of Avaya gear that Avaya insists must have the switch set to 100/Full. - Original Message - From: Tobias Heister [mailto:li...@tobias-heister.de] Sent: Thursday, January 10, 2013 08:31 AM To: Paul Stewart p...@paulstewart.org Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ 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] EX Switch Question
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, January 10, 2013 9:23 AM To: 'Per Granath'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I personally would not use the EX series in a metro ethernet deployment, as that's not where they are positioned to be. Perhaps the MX80 would work? You can get 40 ports of copper (using SFPs) into a single box, with both shaping/policing on a per-port/per-vlan basis. I don't think you can do this with an MX80-48T, though. The other option would be an MX240 with -X-Q or 3D-Q/EQ modules, but those can get rather expensive. Honestly, if you're looking for metro ethernet switches, I'd continue on with Cisco, primarily due to price compared with the MX80, and features specifically positioned for Metro-E compared with the EX series. ME3600 and ME3800 seem to be great switches with tons of features. This is an area where I think Juniper really needs to catch up on (vlan translation, swapping, QoS, MPLS, REP, etc.). -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Paul Stewart p...@paulstewart.org writes: Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Hello, Tobias Heister (Thu 2013-01-10 14:31:40 +0100) : We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) I don't know for the OP needs but for shure EX4200 does not have: - syslog in firewall filters - tcp flags (e. g. established) in firewall filters in egress (physical or VLAN interface). Juniper confirmed that this is a hardware limitation. That was the reason we went MX. Cheers, -- Emmanuel Halbwachs Observatoire de Paris Resp. Réseau/Sécurité 5 Place Jules Janssen tel : +33 1 45 07 75 54 F 92195 MEUDON CEDEX véhicules : 11 av. Marcellin Berthelot ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thank you - yes, both of those issues you highlighted have created problems for us especially lack of tcp established Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Emmanuel Halbwachs Sent: January-10-13 9:59 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Hello, Tobias Heister (Thu 2013-01-10 14:31:40 +0100) : We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) I don't know for the OP needs but for shure EX4200 does not have: - syslog in firewall filters - tcp flags (e. g. established) in firewall filters in egress (physical or VLAN interface). Juniper confirmed that this is a hardware limitation. That was the reason we went MX. Cheers, -- Emmanuel Halbwachs Observatoire de Paris Resp. Réseau/Sécurité 5 Place Jules Janssen tel : +33 1 45 07 75 54 F 92195 MEUDON CEDEX véhicules : 11 av. Marcellin Berthelot ___ 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] EX Switch Question
Thanks We have a 6500 installation running hybrid IOS/CatOS and the CatOS component does it quite well. On another installation with MSFC2 supervisors and native IOS we also have it working... both installations are very ancient 10+ years :) Paul -Original Message- From: Benny Amorsen [mailto:benny+use...@amorsen.dk] Sent: January-10-13 9:41 AM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Paul Stewart p...@paulstewart.org writes: Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
On 01/10/2013 10:21 AM, Paul Stewart wrote: Thank you - yes, both of those issues you highlighted have created problems for us especially lack of tcp established note also that (i believe still) packets which would pass through the box (when it's doing L3 things) but expire on the box... must be accounted for in the loopback filter, if you want to see ttl-expired messages. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Just don't go there. EX is in no way a metro SP switch. Very common case, we've been discussing it with many customers, who their-selves want a Juniper metro SP solution, maybe once a week since the EX series was launched. After all that I am 100% sure this is not what EX is all about. 10.01.2013 18:23, Paul Stewart wrote: Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Thanks Pavel... So is there anything reasonably priced in the Juniper lineup for this kind of situation or do we look at Cisco/other? Cheers, Paul -Original Message- From: Pavel Lunin [mailto:plu...@senetsy.ru] Sent: January-10-13 11:32 AM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX Switch Question Just don't go there. EX is in no way a metro SP switch. Very common case, we've been discussing it with many customers, who their-selves want a Juniper metro SP solution, maybe once a week since the EX series was launched. After all that I am 100% sure this is not what EX is all about. 10.01.2013 18:23, Paul Stewart wrote: Thanks but this is pure layer2 deployments (typically). I should have clarified that some of the VLAN's have IP but most are to link buildings together within a metro etc Really, this is more of a metro ethernet type of environment. I'll read up again on this but I'm comparing this against a tried and true Cisco solution we've used many times and it just worked (rather simply too). with what I've seen/read so far on the Juniper front, this is going to be a problem to implement - really hoping someone can prove me wrong though ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
