Re: Slow IN-ADDR.ARPA responses

[Anurag Bhatia]

Hi John


I have seen similar cases in past with root servers itself. Usually
problems are that local anycasted node here goes down and thus traffic is
redirected to other nearest server in Europe causing high latency. Can you
share traceroute result of a good Vs bad node say A Vs C. Can you see both
coming from within your country?

On Thu, Feb 9, 2012 at 8:16 AM, John Levine  wrote:

> >I checked the traffic graphs for the server we operate
> >(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
> >of any report of issues with the other operators.
>
> Actually, the A server is the only one that's responding quickly,
> viewed from my DSL line hanging off gblx:
>
> A   26ms
> B   83ms
> C  308ms
> D  136ms
> E  248ms
> F   96ms
>
> An acquaintance at LinkedIn tells me that they're seeing the same issue.
>
> Doing a traceroute to the C server, it looks pretty snappy as far as
> London, then slow as soon as it's in Afrinic's network.  I think it's
> usually faster than that.  For the E server, the link between HE in
> California and Australia seems slow.
>
> R's,
> John
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

RE: UDP port 80 DDoS attack

[Sven Olaf Kamphuis]

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. =)

-Drew


yes, very smart idea... which makes it completely impossible to have 
multihomed networks or simply kick out tunnel originated traffic over 
default gateways ... so, no, thanks.


we usually do it the other way around, if providers block "spoofed" 
traffic, we tell them to put their serverfarms somewhere else as thats not 
very optimized for tunnel termination at their facilities :P


(yes leaseweb, that means you ;)




-Original Message-
From: George Bonser [mailto:gbon...@seven.com]
Sent: Wednesday, February 08, 2012 1:27 PM
To: bas; nanog
Subject: RE: UDP port 80 DDoS attack


77% of all networks seem to think so.
http://spoofer.csail.mit.edu/summary.php


And it would be the remaining 23% that really need to understand how difficult 
they are making life for the rest of the Internet.


However the remaining networks allow spoofed traffic to egress their
networks.

When that traffic enters my network, I have no method whatsoever to
differentiate it from any other traffic.


I'm not really thinking about traffic coming from the Internet.  I'm thinking 
about its originating location.  Correct, once it gets into the Internet, you 
really have no way to tell.


I could ask my upstream where they see it coming from, which will be
quite hard if they do not have pretty fancy systems.


At that point the game is really hard, agreed.  And if it is distributed, it 
could be coming from any number of places or from every single one of their 
upstreams.



But if they receive it from a peer, I am as good as lost in trying to
find the culprit.


Agreed.  That's why it is important to stop it at the source.


Bas

Re: BGP history in enterprise?

[Justin M. Streiner]

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

[Leigh Porter]

> -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
> wrote:
> 
> > 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

[Adrian Minta]

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

[Mehmet Akcin]

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

[George Bonser]

> 
> 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

[John Levine]

>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

[Elliot Finley]

On Thu, Feb 9, 2012 at 10:31 AM, Leigh Porter
 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

[lincoln dale]

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser  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

[George Bonser]

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 
mailto: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

[lincoln dale]

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  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  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

[George Bonser]

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 
mailto: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 
mailto: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: Firewalls in service provider environments

[David Walker]

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

[Steve Bertrand]

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!

[Justine Sherry]

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!

[Christian Esteve]

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  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!

[chris]

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  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 
> 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

[Keegan Holley]

2012/2/8 Steve Bertrand 

> 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.