- Test - lists.nanog.org

Netscout experiences
by Blake Dunlap 20 Aug '13

20 Aug '13

Greetings, Anyone out there have experiences with Netscout or any of their nGenius products and wish to share impressions? Currently looking at them in comparison to say Netbrain, NetQoS, smarts, etc. -Blake

4 3

AS174 - cogent - someone without denial syndrome please
by Chris Conn 19 Aug '13

19 Aug '13

Any BGP admins from AS174 monitoring NANOG? I would appreciate a quick email exchange regarding access to www.cogentco.com from some prefixes. Thanks, Chris

1 0

Third Party Software Audit
by Aaron D. Osgood 19 Aug '13

19 Aug '13

I apologize for seeming to waste bandwidth - we have been asked to recommend an firm that does 3rd party software audits. This is a first for me - Suggestions? Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 MOBILE: 207-831-5829 ICQ: 206889374 GVoice: 207.518.8455 GTalk: aaron.osgood <mailto:AOsgood@Streamline-Solutions.net> AOsgood(a)Streamline-Solutions.net <http://www.streamline-solutions.net/> http://www.streamline-solutions.net Introducing Efficiency to Business since 1986.

1 0

mail.mil contact?
by Antonio Querubin 19 Aug '13

19 Aug '13

Wondering if anyone else is receiving reports of email to mail.mil addresses being delayed or refused? The mail.mil mx appear to be selectively refusing mail. If anyone has good (non-email) contact info for the mail.mil operators please send it my way. Thanks. Antonio Querubin e-mail: tony(a)lavanauts.org xmpp: antonioquerubin(a)gmail.com

2 1

BGP Route Issues
by Christopher Karel 19 Aug '13

19 Aug '13

Good evening, I'm hoping you guys might be able to offer some advice or insight into a BGP problem I've got. I've noticed some strange routes between our network, AS27270, and AS22943. It looks like both our networks are dual homed. One ISP as the primary, and the other used as a backup, with path prepending to prevent it from actually being used except in an outage. However, our route to 22943 appears to be using their backup link. (27270 4323 7018 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943 22943) Which is strange, because we can reach their primary ISP without any such rigmarole. Playing around with Looking Glass servers indicates that Cogent (AS174) has a similar backup route to our network. (174 22402 27270 27270 27270 27270 27270 27270) Everywhere else I check seems perfectly sane. But since Cogent is essentially in-between the two networks I'm troubleshooting, I would assume that the other network has a similar route. But Cogent won't talk with me about this, since I'm not a customer. So as far as advice goes, is there a common issue that might result in such poor routes in both directions? Any further troubleshooting that I should be doing? Or any ideas on how to help remedy things that appear to be outside our network/ISP? Or are we doing something so wrong that this is all my fault? I'd really appreciate any input on this.

6 6

Comcast security NOC/contact
by Richard Hesse 19 Aug '13

19 Aug '13

Can someone from Comcast please contact me over what appears to be an ill-conceived nullroute or block regarding one of our content IP's. This issue is limited only to Comcast and only to a single IP. Please contact me to get this resolved. I'm guessing that someone wanted us offline but couldn't do it directly. So they attacked you using our spoofed IP, and your automated systems put a block in place. It would also be nice to have an actual, real NOC number listed in your whois. -richard

1 1

Re: [Paper] B4: Experience with a Globally-Deployed Software Defined
by freedman＠freedman.net 18 Aug '13

18 Aug '13

No, people never use *flow controllers* for anything. People have been doing SDN since before Google was around. OK, so it was horrible expect scripts but it worked. Avi > Unpossible. I heard that no one really uses sdn for anything. > > :) > > T

6 6

[Paper] B4: Experience with a Globally-Deployed Software Defined WAN
by staticsafe 18 Aug '13

18 Aug '13

"We present the design, implementation, and evaluation of B4, a pri- vate WAN connecting Google’s data centers across the planet." - http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. Please don't CC! I'm subscribed to whatever list I just posted on.

3 2

morning giggle
by Randy Bush 18 Aug '13

18 Aug '13

for your morning, or whatever time of day it is to you, giggle From: "Jeffrey L. Roberts" <jeffrey.l.roberts(a)gmail.com> Subject: DNS Zone File Access Request To: Randy Bush < randy(a)psg.com> Date: Sat, 17 Aug 2013 21:56:02 -0400 Greetings, My name is Jeff and I hope you're having a great day. I am the CIO of the Trademark Police. We would like to know what forms we need to fill out to receive credentials to access your dns zone files. Please contact me at your earliest convenience at Jeffrey.L.Roberts(a)gmail.com, or feel free to call me at 1-305-815-1155 Thank you! - Jeffrey L. Roberts

5 4

Re: [Paper] B4: Experience with a Globally-Deployed Software Defined
by freedman＠freedman.net 18 Aug '13

18 Aug '13

> On Sat, Aug 17, 2013 at 2:32 PM, Avi Freedman <freedman(a)freedman.net> wrote: > > > No, people never use *flow controllers* for anything. > > > People have been doing SDN since before Google was around. > > OK, so it was horrible expect scripts but it worked. > > Not really. Note I am talking about flow controllers in my first point. (And I was trying to be funny to match Todd's tone, though I guess it's dangerous to try to copy the master) Re: flow controllers - The idea of centralized decision makers doing something (typically per flow) has been proposed, in my experience, by those with little operational experience or those with extraordinarily constrained topoligies, types of traffic, and usually external filtering to constrain the types of traffic one could face. Because... There have been no proposals that I have seen (or that those who are at the Major Vendors who follow it more closely tell me about when I ask a few times/year) to actually deal with the every-packet-is-a-flow problem we saw first with 7206VXRs and that remain a real possibility for Internet- connected networks. Distributing flow controllers and making them hierarchical doesn't seem to help in the architectures that I've seen proposed. So it seems to be of use only for very tiny networks or for very constrained and filtered or non Internet-connected topologies. I'd be interested to be shown otherwise. > Automatic reconfiguration of routers is not what a software-defined network is. > > It is one of the things (but not all of the things) that SDN provides. > > A software defined network is one where the forwarding behavior can be > completely defined > in software running outside of the devices that perform the forwarding. That said, I wince every time someone starts talking about (not suggesting you are here but many do) making the routing engineer or designer in a box that sits on the bottom or besides the network. Those who have experience and/or run larger infrastructure usually say words like "of course we have to worry about feedback loops" but many don't. I think innovation is great but I don't think there are that many shops that are better off writing their own control pane (centralized, distribtued, whatever) right now. It's worth remembering that Google is a software company. They are far ahead in software defined everything. > You can write expect scripts all day; but you cannot turn your basic switch > into a Load balancer or stateful firewall with one. > or decide in real time exactly which destination Ethernet ports a packet > coming in a certain port is going to touch, without having structured > VLANs and static MAC tables on the switches ahead of time. > > Changing device configurations with expect scripts is a limited tiny subset > of what SDN is. True, but the number of production environments that are going to be more stable or scalable by having people build their own control logic is pretty small in my experience. And being able to debug and reach out to a community of operators with a common set of experience of what to do, not to do, and how to debug is extraordinarily valuable for production networks. When I look at most of the non-Google big guys, SDN means pushing the vendors for better control plane instrumentation and ability to program (but more on the instrumentation side as where the gaps have been), and potentially to get some cross-provider way of doing the above. + having merchant silicon one can get/use for cheap, typically for more constrained topologies, doing pretty dumb switching and/or routing stuff. > -JH Where I see the delta a lot given the customer conversations I have is in the magic provisioning of cloud network infrastructures. New school SDN is that everything is a tunnel, magic software maps things, commercial providers doing this uniformly have to aggressively rate- limit their clients, and performance for content delivery is limited because the hypervisors must be briding and can't do PCI passthrough or SR/IOV. Old school SDN (not really that old school) is API-based provisioning of network devices with vendor support (let's say Juniper) to do filtering, VLANs, and shaping and tunnels where needed. It'll definitely be interesting to see where things go over the next few years. I know tens of companies who have run away from cloud providers with new(er) school SDN-ish infrastructures for the simplicity of just having some high performance dedicated machines/hypervisors with dead simple switching infrastructure. Anyway, innovation is great but I just see few companies with the understanding to go build their own control plane software to connect to the Internet with. And those vendors who do build it will get borged by one of the routing/switching vendors and things will become product features, differentiated by providers, most likely. (Though I hope not) Avi

2 1