Re: BGP history in enterprise?
On Wed, 8 Feb 2012, Andrey Khomyakov wrote: Looking for something to keep track of BGP route changes in a large enterprise. Found http://www.ibgplay.org/, but I can't seem to get in touch with them to obtain that free license needed to start the service. Does anyone know of something that would do what bgplay does or alternatively how to get in touch with the ibgplay folks for that license... If you're looking for changes that make it into the global BGP view, try http://bgplay.routeviews.org/ jms
RE: 10G switchrecommendaton
-Original Message- From: Brent Jones [mailto:br...@brentrjones.com] Sent: 27 January 2012 06:33 To: Rodrick Brown Cc: nanog list Subject: Re: 10G switchrecommendaton On Thu, Jan 26, 2012 at 8:40 PM, Rodrick Brown rodrick.br...@gmail.comwrote: Not to mention Arista's cli runs a busybox Linux inside! Sent from my iPhone Last I checked, Arista used Fedora Linux, with x86 dual-core CPUs and 4GB RAM. Their CLI was written in Python or Perl as well, and they encourage hacking it for cool new things. Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing. So a couple of evals on the way... -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: 10G switchrecommendaton
Cisco has finally release a new 10G switch, Catalyst 4500-X: http://www.cisco.com/en/US/products/ps12332/index.html Does anyone know the price range, or the FCS date for this ?
Re: Slow IN-ADDR.ARPA responses
On Feb 8, 2012, at 6:03 PM, John Levine wrote: I'm seeing surprisingly slow responses from some of the IN-ADDR servers, like 300ms or more. Are they being attacked by script kiddies of something? R's, John We operate B.* and we don't see anything unusual in our locations. thanks Mehmet
RE: 10G switchrecommendaton
Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing. So a couple of evals on the way... -- Leigh It's pretty good gear. The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.
Re: Slow IN-ADDR.ARPA responses
We operate B.* and we don't see anything unusual in our locations. Seems to have been routing problems with C. The B server looks fine from here, too. Thanks, all. R's, John
Re: 10G switchrecommendaton
On Thu, Feb 9, 2012 at 10:31 AM, Leigh Porter leigh.por...@ukbroadband.com wrote: Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing. So a couple of evals on the way... Let us know how the eval goes if you would. Thanks, Elliot
Re: 10G switchrecommendaton
On Fri, Feb 10, 2012 at 7:24 AM, George Bonser gbon...@seven.com wrote: It's pretty good gear. The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs. IGMP should work just fine with MLAG. IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish. cheers, lincoln. (l...@aristanetworks.com)
RE: 10G switchrecommendaton
Feb 9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs) SJC-AGS-01#sho ver Arista DCS-7124S-F Hardware version:06.02 Serial number: JSH10130054 System MAC address: 001c.7308.752f Software image version: 4.6.4 Architecture: i386 Internal build version: 4.6.4-434606.EOS464 Sure, we can discuss it. From: lincoln dale [mailto:l...@interlink.com.au] Sent: Thursday, February 09, 2012 1:13 PM To: George Bonser Cc: Leigh Porter; nanog list Subject: Re: 10G switchrecommendaton On Fri, Feb 10, 2012 at 7:24 AM, George Bonser gbon...@seven.commailto:gbon...@seven.com wrote: It's pretty good gear. The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs. IGMP should work just fine with MLAG. IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish. cheers, lincoln. (l...@aristanetworks.commailto:l...@aristanetworks.com)
Re: 10G switchrecommendaton
hi George, IGMPv3 snooping has been supported since EOS 4.7. Its enabled by default in EOS 4.8.x. In terms of specifics, there is support for both IGMPv3 snooping IGMPv3 querier. There isn't currently support for IGMPv3 snooping querier. cheers, lincoln. On Fri, Feb 10, 2012 at 8:17 AM, George Bonser gbon...@seven.com wrote: Feb 9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs) ** ** SJC-AGS-01#sho ver Arista DCS-7124S-F Hardware version:06.02 Serial number: JSH10130054 System MAC address: 001c.7308.752f ** ** Software image version: 4.6.4 Architecture: i386 Internal build version: 4.6.4-434606.EOS464 ** ** Sure, we can discuss it. ** ** ** ** ** ** *From:* lincoln dale [mailto:l...@interlink.com.au] *Sent:* Thursday, February 09, 2012 1:13 PM *To:* George Bonser *Cc:* Leigh Porter; nanog list *Subject:* Re: 10G switchrecommendaton ** ** On Fri, Feb 10, 2012 at 7:24 AM, George Bonser gbon...@seven.com wrote: It's pretty good gear. The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs. IGMP should work just fine with MLAG. IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish. cheers, lincoln. (l...@aristanetworks.com)
RE: 10G switchrecommendaton
Hi, Lincoln, *sigh* Ok, I see what happened. We just went through a software upgrade cycle on that unit and it got upgraded to the end of 4.6 instead of being upgraded to the latest release version of EOS. Looks like another upgrade needs to be done, probably to 4.8.3 Thanks. George From: lincoln dale [mailto:l...@interlink.com.au] Sent: Thursday, February 09, 2012 1:47 PM To: George Bonser Cc: Leigh Porter; nanog list Subject: Re: 10G switchrecommendaton hi George, IGMPv3 snooping has been supported since EOS 4.7. Its enabled by default in EOS 4.8.x. In terms of specifics, there is support for both IGMPv3 snooping IGMPv3 querier. There isn't currently support for IGMPv3 snooping querier. cheers, lincoln. On Fri, Feb 10, 2012 at 8:17 AM, George Bonser gbon...@seven.commailto:gbon...@seven.com wrote: Feb 9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs) SJC-AGS-01#sho ver Arista DCS-7124S-F Hardware version:06.02 Serial number: JSH10130054 System MAC address: 001c.7308.752f Software image version: 4.6.4 Architecture: i386 Internal build version: 4.6.4-434606.EOS464 Sure, we can discuss it. From: lincoln dale [mailto:l...@interlink.com.aumailto:l...@interlink.com.au] Sent: Thursday, February 09, 2012 1:13 PM To: George Bonser Cc: Leigh Porter; nanog list Subject: Re: 10G switchrecommendaton On Fri, Feb 10, 2012 at 7:24 AM, George Bonser gbon...@seven.commailto:gbon...@seven.com wrote: It's pretty good gear. The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs. IGMP should work just fine with MLAG. IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish. cheers, lincoln. (l...@aristanetworks.commailto:l...@aristanetworks.com)
Re: Firewalls in service provider environments
I'm an end user but I refer to these from time to time: http://www.ietf.org/rfc/rfc3013.txt http://www.ietf.org/rfc/rfc3871.txt I suppose the salient question is what kind of customers are we talking about. Best wishes.
Re: UDP port 80 DDoS attack
On 2012.02.08 14:23, Drew Weaver wrote: Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =) I firmly believe in this recourse, amongst others... If you know that your provider allows spoofed traffic, let the community know about it. In all aspects of life, a problem must be 'fixed' at the source. All of the small-medium size ops have to connect to the big-boys somewhere, and what I've seen in this industry is that the big-boys are generally compliant. Steve
Middlebox Report and Thank You!
Hello NANOG! I emailed you a few months ago asking for help understanding typical middlebox deployments in enterprise networks. 57 of you responded - thank you so much! Several of you asked if I'd share the data post-study; I've put together a brief report on our findings here: http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf If you have any questions, comments, or feedback, please don't hesitate to contact me. Thanks again for your help and support for our research! Best, Justine
Re: Middlebox Report and Thank You!
Thank you Justine! your research recalled me to a recent middlebox-related publication: An Untold Story of Middleboxes in Cellular Networks by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and Ming Zhang, Proceedings of SIGCOMM 2011. (http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf) In the news: MIT Technology Review http://www.technologyreview.com/communications/38435/?a=f Slashdot http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones cnet news http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/ Keep on your good work! Cheers, Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 est...@cpqd.com.br www.cpqd.com.br On Thu, Feb 9, 2012 at 23:01, Justine Sherry just...@cs.washington.edu wrote: Hello NANOG! I emailed you a few months ago asking for help understanding typical middlebox deployments in enterprise networks. 57 of you responded - thank you so much! Several of you asked if I'd share the data post-study; I've put together a brief report on our findings here: http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf If you have any questions, comments, or feedback, please don't hesitate to contact me. Thanks again for your help and support for our research! Best, Justine -- Christian
Re: Middlebox Report and Thank You!
Look how much time people waste with those all in one devices :) As soon as I get the feeling something is very appliancey I run the other direction On Thu, Feb 9, 2012 at 8:20 PM, Christian Esteve chest...@gmail.com wrote: Thank you Justine! your research recalled me to a recent middlebox-related publication: An Untold Story of Middleboxes in Cellular Networks by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and Ming Zhang, Proceedings of SIGCOMM 2011. (http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf) In the news: MIT Technology Review http://www.technologyreview.com/communications/38435/?a=f Slashdot http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones cnet news http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/ Keep on your good work! Cheers, Christian -- Christian Esteve Rothenberg, Ph.D. Converged Networks Division (DRC) Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087 est...@cpqd.com.br www.cpqd.com.br On Thu, Feb 9, 2012 at 23:01, Justine Sherry just...@cs.washington.edu wrote: Hello NANOG! I emailed you a few months ago asking for help understanding typical middlebox deployments in enterprise networks. 57 of you responded - thank you so much! Several of you asked if I'd share the data post-study; I've put together a brief report on our findings here: http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf If you have any questions, comments, or feedback, please don't hesitate to contact me. Thanks again for your help and support for our research! Best, Justine -- Christian
Re: UDP port 80 DDoS attack
2012/2/8 Steve Bertrand steve.bertr...@gmail.com On 2012.02.08 14:23, Drew Weaver wrote: Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =) I firmly believe in this recourse, amongst others... How do you tell the spoofed packets from the non-spoofed ones? Especially if you have more than one provider. If you know that your provider allows spoofed traffic, let the community know about it. According to a company wide NDA I'm only allowed to disclose that to the best of my knowledge my upstreams permits packets sent from users or other NSP's who may or may not permit or generate packets. The source IP addresses are checked to be valid 32 bit numbers before being sent to my routers. My upstreams to the best of their knowledge have never sent me a single spoofed packet and will refrain from doing so unless they receive written consent from me, in triplicate. ;) In all aspects of life, a problem must be 'fixed' at the source. All of the small-medium size ops have to connect to the big-boys somewhere, and what I've seen in this industry is that the big-boys are generally compliant. As long as compliant means completely indifferent to your concerns and unwilling to change or compromise in any meaningful while sucking money away faster than the government. They are all very very compliant and a pleasure to do business with.
