- NANOG - lists.nanog.org

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

18 Aug '15

On 18/08/2015 21:56, Gert Doering wrote: > So how's that stopping one of your bilateral peers from sending you > traffic destined elsewhere? it doesn't: you detect it and depeer them. If they force the situation with static routes, the traffic will be dropped. Nick

1 0

rDNS delegation process question
by Dave Pooser 18 Aug '15

18 Aug '15

At $DAYJOB we have a /24 of PA space that we were allocated by Airband, and when the account was set up they delegated authoritative reverse DNS to our DNS hosting provider. This is 69.26.223.0/24, in ARIN address space. Now, almost a decade later Airband has been acquired by somebody or other who was in turn acquired by GTT.net; we're trying to move our rDNS to Route53 and nobody at GTT.net seems to know how they would go about changing that rDNS delegation. My involvement with the process back in the day was limited to "provide Airband with the name servers we would like to be authoritative for the reverse DNS and wait about 12 hours for them to handle the ticket." Now I'm trying to help my GTT contact get pointed in the right direction, and any assistance would be appreciated. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com

2 2

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