August 2015 - Test - lists.nanog.org

A perl script to find IP and network addresses in a text file (config, ACL, etc) and annotate them with various bits of information
by Jesse McGraw 18 Aug '15

18 Aug '15

(This is me scratching an itch of my own and hoping that it might be useful to others on this list. Apologies if it isn't) All, I was working my way through a very long ACL, trying to clean out old cruft, and I found myself thinking that surely I could make this somewhat easier. So, I wrote a small script that will go through a text file(or files), find anything that looks like a host IP or subnet (with subnet mask, wildcard mask, or mask length), dig up information about them (DNS name, ping responsiveness, host count etc) and then spit out an HTML version of the input file with color coded info. General info is blue Hosts that are reachable and networks that have a specific route are GREEN (see networks note below) Hosts that are non-responsive and networks that use default route are RED Individual script is: https://github.com/jlmcgraw/networkUtilities/blob/master/annotate_hosts_and… Repository is: https://github.com/jlmcgraw/networkUtilities To get the whole repository: git clone https://github.com/jlmcgraw/networkUtilities.git This repository includes the necessary modules for this script and some other small utilities that network folks might be interested in (If for some reason included modules don't work for you see setup.sh for easy ways to install them under Debian-derived Linux. I've tested the script under Linux and Windows, but not OS X) Please let me know if you use this utility and encounter anything that doesn't work right. I'm also interested in incorporating any changes/improvements so feel free to send a pull request! -Jesse Note: If you've got a BGP speaking router that you can query via SNMP, you should be able to use bgp_asn_path_via_snmp.pl <https://github.com/jlmcgraw/networkUtilities/blob/master/bgp_asn_path_via_s…> to create a table of known routes to use along with this utility

2 1

Fwd: [c-nsp] Peering + Transit Circuits
by Tim Durack 18 Aug '15

18 Aug '15

---------- Forwarded message ---------- From: Tim Durack <tdurack(a)gmail.com> Date: Tue, Aug 18, 2015 at 9:53 AM Subject: Re: [c-nsp] Peering + Transit Circuits To: Rolf Hanßen <nsp(a)rhanssen.de> Cc: "cisco-nsp(a)puck.nether.net" <cisco-nsp(a)puck.nether.net> On Tue, Aug 18, 2015 at 9:45 AM, "Rolf Hanßen" <nsp(a)rhanssen.de> wrote: > Hi, > > you forgot "do some interface-ACL-magic that drops peer-traffic that does > not have a destination IP in my cool-networks-whitelist". > Yup, valid option. I am trying to avoid anything that involves maintaining lists. -- Tim:>

1 0

Re: [c-nsp] Peering + Transit Circuits
by Tim Durack 18 Aug '15

18 Aug '15

On Tue, Aug 18, 2015 at 9:38 AM, Gert Doering <gert(a)greenie.muc.de> wrote: > Hi, > > On Tue, Aug 18, 2015 at 09:32:53AM -0400, Tim Durack wrote: > > > (It would be cool if Cisco would understand that hardware forwarding > > > platforms need useful netflow with MAC-addresses in there... ASR9k at > [..] > > At the risk of introducing religion, I will mention sFlow... > > Yes... and this is helping exactly why...? Given the overwhelming > support for sFlow in (Cisco-) hardware routers used as peering edge? :-) I ask Cisco for sFlow support on a regular basis. Cisco typically respond with some variation of NIH syndrome. Anyway, back to my question :-) -- Tim:>

1 0

Re: [c-nsp] Peering + Transit Circuits
by Tim Durack 18 Aug '15

18 Aug '15

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert(a)greenie.muc.de> wrote: > Hi, > > (It would be cool if Cisco would understand that hardware forwarding > platforms need useful netflow with MAC-addresses in there... ASR9k at > least got working MAC-accounting, but more fine grained telemetry would > certainly be appreciated. Software IOS can do it, Sup720 cannot do it > due to hardware constraints, Sup2T exports MAC addresses taken from random > caches in the system but not the inbound packets, XR doesn't do it at all, > hrmph) > At the risk of introducing religion, I will mention sFlow... -- Tim:>

1 0

Drops in Core
by Glen Kent 18 Aug '15

18 Aug '15

Hi, Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has "entered" the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side. Is this correct? Glen

12 21

RE: Cogent revisited
by Adam Greene 17 Aug '15

17 Aug '15

Thank you to those who replied off-list, for the helpful replies! The feedback basically ranged from neutral (maybe a little positive) to really negative. The main emphasis being on: use them only if you are redundant. Seems like things haven’t changed much since 2012. Thanks! On Aug 11, 2015 19:32, "Adam Greene" <maillist(a)webjogger.net <mailto:maillist@webjogger.net> > wrote: Hi all, We are getting ready to renew our fiber contract with our incumbent provider (Lightower, ASN 46887). We are happy with them, but are looking for alternatives. At the location in question we need about 200M. Cogent recently contacted us, and I shied away a bit, based on this conversation a few years ago: http://mailman.nanog.org/pipermail/nanog/2012-May/048181.html Have opinions changed since then? Or is Cogent still the "budget alternative to have in your mix, but better to stay away from if you need high-performance, reliable, mostly standalone bandwidth" (which is how I would summarize the consensus in 2012)? Thanks, Adam

4 3

China Telecom / China Unicom IP Transit Pricing
by James Braunegg 17 Aug '15

17 Aug '15

Dear All Just wondering if anyone can share with me target IP Transit pricing they have been able to achieve with China Telecom and China Unicom delivered to LA or AMS, after rounds of negations. Capacity Required (1G to 10G) Bonus points if you have contact information for someone who can provide competitive pricing Kindest Regards James Braunegg P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg(a)micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666 W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21 Follow us on Twitter<http://www.twitter.com/micron21> for important service and system updates. [M21.jpg] 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.

2 1

net neutrality peering dispute between CenturyTel/Qwest and Cogent in Dallas
by Jordan Hamilton 16 Aug '15

16 Aug '15

I have several customers that are having packet loss issues, the packet loss appears to be associated with a Cogent router interface of 38.104.86.222. My upstream provider is telling me that the packet loss is being caused by a net neutrality peering dispute between CenturyTel/Quest and Cogent in Dallas. I did some quick googling to see if I could come up with any articles or something like that I could provide to my customers and did not see anything. Anyone know any details? Thanks Jordan Hamilton Senior Telecommunications Engineer Empire District Electric Co. 720 Schifferdecker PO Box 127 Joplin, MO 64802 Ph: 417-625-4223 Cell: 417-388-3351 -- Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. -- This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited.

9 15

Re: Drops in Core
by alif.terranson (IMAP) 16 Aug '15

16 Aug '15

Sean Donelan Opined Thusly, "Generally I don't believe ISPs that claim 100% uptime or 0% packet loss." I have seen a "perfect score" on a Keynote evaluation, while we had a rather nasty outage outside a preststed maintenance window. When we objected that the outages was a planned maintenance that somehow escaped publication, it was ignored by Keynote - how generous! I doubt anyone here would deny the difficulty of maintaining a five 9's record, going above and beyond to claim no packet loss just tells you who they really are... -- Yours, /s/ Alif Sent from my 100% uptime, packet loss-free digital carrier pigeon.

1 0

Re: Drops in Core
by Rafael Possamai 15 Aug '15

15 Aug '15

That was just an example, that list has to be completed on a specific network or scenario, it changes dramatically. Imagine you were to create a list for a DoD network instead of public peering based network, it would change dramatically. On Sat, Aug 15, 2015 at 12:28 PM, Glen Kent <glen.kent(a)gmail.com> wrote: > Why do you say that Layer 1 issues in the last mile would be very high? > How is it any different from the first mile? > > On Sat, Aug 15, 2015 at 10:56 PM, Rafael Possamai <rafael(a)gav.ufsc.br> > wrote: > >> Hi Glen, >> >> If you first list the causes of a dropped packet, then you can figure out >> how likely they are at different points in time (first\last\peer\etc) by >> making some assumptions. >> >> Here's an **example**: >> >> *Cause | Location | Likelihood* >> Congestion | Last mile | Low >> Congestion | First mile | Low >> Congestion | Peering | Medium >> Layer 1 | First mile | Low >> Layer 1 | Core | Low >> Layer 1 | Last mile | High >> >> You can even go as far as drawing a cause and effect diagram for each >> location. Then you can collect real world data and fine tune your >> assumptions. >> >> >> Rafael >> >> >> On Sat, Aug 15, 2015 at 11:47 AM, Glen Kent <glen.kent(a)gmail.com> wrote: >> >>> Hi, >>> >>> Is it fair to say that most traffic drops happen in the access layers, or >>> the first and the last miles, and the % of packet drops in the core are >>> minimal? So, if the packet has made it past the first mile and has >>> "entered" the core then chances are high that the packet will safely get >>> across till the exit in the core. Sure once it gets off the core, then >>> all >>> bets are off on whether it will get dropped or not. However, the key >>> point >>> is that the core usually does not drop too many packets - the probability >>> of drops are highest in the access side. >>> >>> Is this correct? >>> >>> Glen >>> >> >> >

1 0