RE: pontification bloat (was 10GE TOR port buffers (was Re: 10G switch recommendaton))
Additionally, ECN is just between hosts, end to end. If an flow is not ECN enabled (neither of the ECN bits set), then the routing gear does what it always has done, drop a packet. Only if one of the ECN bits is already set (meaning the flow is ECN aware, end to end) does the router set the other bit to signal congestion. So enabling this on routing gear would have no impact on user traffic except to allow a better experience for ECN aware flows. In other words, allowing this option in the network gear would have no impact on non-ECN flows and only help flows that negotiated ECN end-to-end at connection setup. These flows would already be known to be trouble-free for ECN else they wouldn't have been able to negotiate it.
RE: pontification bloat (was 10GE TOR port buffers (was Re: 10G switch recommendaton))
> > This sounds a lot like most peoples ipv6 rationale as well. > > > I'm still feeling some scars from last time Ecn was enabled in my > hosts. Many firewalls would eat packets with. Ecn enabled. That was, I believe, nearly 10 years ago, was it not? There has been considerable testing with ECN with the bufferbloat folks and I have done some myself and haven't noticed anyone blocking ECN lately. There might still be a few corner cases out there still, but none that I have noticed. What you will find, according to what I have read by others doing testing is that some networks will clobber the ECN bits (reset them) but pass the traffic. These days at worst you would not be able to negotiate ECN but the traffic wouldn't be blocked. Anyone clearing the entire DSCP byte on traffic entering their network, for example, would clobber ECN but not block the traffic. The key thing here would be to have people NOT clear ECN bits on traffic flowing through their network to allow it to be negotiated end to end by the hosts involved in the transaction.
Re: 10G switchrecommendaton
On Sun, Jan 29, 2012 at 08:02:28PM -0200, Alvaro Pereira wrote: > And note that the Juniper EX2500 does not run JUNOS, it is just an OEM box > from someone else... Blade Networks, now IBM. > > Alvaro > > On Fri, Jan 27, 2012 at 10:23, Tim Vollebregt wrote: > > > 2,5MB shared approximately. > > > > Aggregating 10G with microbursts is definately a no-go on such box. > > > > -Tim > > > > > > On 27-01-12 12:33, James Braunegg wrote: > > > >> How small is the buffer on the EX4500 ?? > >> > >> Kindest Regards > >> > >> James Braunegg > >> W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 > >> E: james.braun...@micron21.com | ABN: 12 109 977 666 > >> > >> > >> This message is intended for the addressee named above. It may contain > >> privileged or confidential information. If you are not the intended > >> recipient of this message you must not use, copy, distribute or disclose it > >> to anyone other than the addressee. If you have received this message in > >> error please return the message to the sender by replying to it and then > >> delete the message from your computer. > >> > >> > >> -Original Message- > >> From: Tim Vollebregt [mailto:t...@interworx.nl] > >> Sent: Friday, January 27, 2012 8:35 PM > >> To: nanog@nanog.org > >> Subject: Re: 10G switchrecommendaton > >> > >> I would not recommend EX4500 as an 10G aggregator switch, it has really > >> small buffers. > >> > >> EX3300 as TOR > >> EX82** as 10G aggregator > >> > >> -Tim > >> > >> On 26-01-12 22:13, Raul Rodriguez wrote: > >> > >>> Juniper EX4500. > >>> > >>> -RR > >>> > >>> On 1/26/12, Deric Kwok wrote: > >>> > Hi all > > I would like to have 10G switchrecommendaton Ipref software can test > around 9.2G but we can have congestion over 6G in single port! > > Thank you > > > > > -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
Re: 10G switchrecommendaton
And note that the Juniper EX2500 does not run JUNOS, it is just an OEM box from someone else... Alvaro On Fri, Jan 27, 2012 at 10:23, Tim Vollebregt wrote: > 2,5MB shared approximately. > > Aggregating 10G with microbursts is definately a no-go on such box. > > -Tim > > > On 27-01-12 12:33, James Braunegg wrote: > >> How small is the buffer on the EX4500 ?? >> >> Kindest Regards >> >> James Braunegg >> W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >> E: james.braun...@micron21.com | ABN: 12 109 977 666 >> >> >> This message is intended for the addressee named above. It may contain >> privileged or confidential information. If you are not the intended >> recipient of this message you must not use, copy, distribute or disclose it >> to anyone other than the addressee. If you have received this message in >> error please return the message to the sender by replying to it and then >> delete the message from your computer. >> >> >> -Original Message- >> From: Tim Vollebregt [mailto:t...@interworx.nl] >> Sent: Friday, January 27, 2012 8:35 PM >> To: nanog@nanog.org >> Subject: Re: 10G switchrecommendaton >> >> I would not recommend EX4500 as an 10G aggregator switch, it has really >> small buffers. >> >> EX3300 as TOR >> EX82** as 10G aggregator >> >> -Tim >> >> On 26-01-12 22:13, Raul Rodriguez wrote: >> >>> Juniper EX4500. >>> >>> -RR >>> >>> On 1/26/12, Deric Kwok wrote: >>> Hi all I would like to have 10G switchrecommendaton Ipref software can test around 9.2G but we can have congestion over 6G in single port! Thank you >
Re: pontification bloat (was 10GE TOR port buffers (was Re: 10G switch recommendaton))
See below Jared Mauch On Jan 27, 2012, at 9:13 PM, George Bonser wrote: >> Router(config)# policy-map pol1 >> Router(config-pmap)# class class-default >> Router(config-pmap-c)# bandwidth per 70 >> Router(config-pmap-c)# random-detect >> Router(config-pmap-c)# random-detect ecn >> >> Requires other bits in the network to be ECN aware, but if they are, >> good stuff. >> >> -- > > +1 > > There is no excuse these days for stuff not to be ECN aware. That GREATLY > mitigates things as it makes hosts aware pretty much immediately that there > is congestion and they don't have to wait for a lost packet to time out. I > brought it up to a Brocade engineer once asking for the option to set ECN > rather than drop the packet and he said "nobody uses it". I told him nobody > uses it because you don't have the feature available. How can anyone use it > if you don't have the feature? > > > This sounds a lot like most peoples ipv6 rationale as well. I'm still feeling some scars from last time Ecn was enabled in my hosts. Many firewalls would eat packets with. Ecn enabled.
RE: Paypal outage?
Out of curiosity, are you using the latest Chrome Beta? I have seen a few complaints this morning of other sites misbehaving with Chrome in general, more with the latest beta. -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Sunday, January 29, 2012 12:34 AM To: nanog@nanog.org Subject: Re: Paypal outage? On Sunday, January 29, 2012 03:09:10 AM Chris wrote: > I switched browsers and it seemed to clear it up. Just never seen an > odd error like that before.. Tried emptying your browser cache and limiting how much it grows over time? This helped solve a similar issue when my browser assumed my bank's Internet banking web site was under maintenance for 2 weeks :-). Mark.
Re: LX sfp minimum range
I once tried an LX-SMF-MMF-LX type setup using mode conditioning patch leads between the SMF-MMF and MMF-LX portions of the span. I would be hesitant to recommend it, simply touching the patch lead on the MMF-LX portion would result in horrendous error counts. Suffice to say, we bit the bullet and got some SMF blown through (tubes ftw). I have also used LX-LX on short SMF runs of a couple of metres, for 1G and 10G, with no issues. On 27 January 2012 16:47, Pierre-Yves Maunier wrote: > 2012/1/27 Steven Tardy > > > On 01/26/12 16:33, Pierre-Yves Maunier wrote: > > > >> > >> > >> It can happends that SX works on singlemode but it can fail anytime. > >> > >> just because you can doesn't mean you should. > > > > we have experience multiple cases where LX-MMF-LX works great for 3-5+ > > years... > > then one day no longer gets link. swapping to a different fiber pair > > restores link. > > can't remember SX-MMF-SX failing after years of service. > > > > > That's why I wrote 'but it can fail anytime' meaning, I strongly recommand > to NOT do it. > > > -- > Pierre-Yves Maunier >
