February 2014 - Test - lists.nanog.org

Re: TWC (AS11351) blocking all NTP?
by Joel M Snyder 04 Feb '14

04 Feb '14

> It seems thata hosts sending large amounts of NTP traffic over the > public Internet can be safely filtered if you don't already know that > it's one of the handful that's in the ntp.org pools or another well > known NTP master. Speaking as one of the 3841 servers in the pool.ntp.org pool, I'm happy to be described as a "handful," something my mother used to say, but I do feel obligated to point out that it's a pretty big handful especially if you want to be fiddling ACLs on an hourly basis which is pretty much what it takes. And, of course, if you're one of that handful, then you've pretty much got to allow that NTP traffic in, although you're also probably, hopefully, clue-full enough not to let random hosts make you a DDoS accelerator. (the other) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

8 9

looking for a tool...
by Mike 04 Feb '14

04 Feb '14

Hello, I was wondering if anyone could point me in the direction of a tool capable of sniffing (or reading pcap files), and reporting on lan station thruput in terms of bits per second. Ideally I'd like to be able to generate a sorted report of the top users and top thruputs observed and so forth. The traffic is pppoe and I need to monitor it at a specific switchport where I can arrange span. Thank you.

5 4

RE: looking for a tool...
by rwebb＠ropeguru.com 04 Feb '14

04 Feb '14

I suggest wireshark also. Not realtime for throughput, but will open pcap files and you can then get the throughput metrics. Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Jonathan Hall <jhall(a)futuresouth.us> Date:02/04/2014 8:49 AM (GMT-05:00) To: Mike <mike-nanog(a)tiedyenetworks.com>,nanog(a)nanog.org Subject: Re: looking for a tool...

1 0

best practice for advertising peering fabric routes
by Eric A Louie 04 Feb '14

04 Feb '14

I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure. All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it "as is", and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric Advantages and disadvantages, pros and cons? Recommendations? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. That's another issue completely from a planning perspective. thanks Eric

24 56

-48VDC supply for home lab?
by Mark Leonard 03 Feb '14

03 Feb '14

Greetings NANOG'ers! I have a small home lab which I mostly use for learning and testing. I'm likely to receive some gear that needs negative 48VDC (ie: positive ground). Mains is a typical 120VAC, 60Hz. Can anyone recommend a power supply, reasonably priced, to go from 120VAC down to -48VDC@10Amps? Something that fits in a two post rack would be preferred, but not required. Thanks, Mark

5 4

Do network diagnostic tools need upgrade?
by Ammar Salih 03 Feb '14

03 Feb '14

Hello NANOG list members, I have a question for you, are you happy with the current network diagnostic tools, like ping, trace route .. etc, don't you think it's time to have an upgraded version of icmp protocol? from my side there is a lot that I can NOT do with current tools and protocols, here are few scenarios, and I would like to hear yours: First scenario: To be able to troubleshoot advanced networks with complex QoS and policy-based routing configuration, where ping, traceroute and other network diagnostic tools do not provide accurate readings, for example, you are troubleshooting a web server with ping, and it looks functioning quite well (packet loss and round trip time is all good), but web services are still significantly slow, the fact is icmp and tcp:80 might have different priorities and bandwidth limits on each router along the path between the client and the server, in this case, network admins usually use telnet applications like (Paping), well it may help if the forward and return path of all packets are exactly the same. Second scenario: So another possible scenario is that you need to determine readings for forward and return paths, TraceRoute for example gives you forward path only using icmp. But what if you need to troubleshoot a VoIP server for example, assuming that packets return path might not be the same as forward path. Third scenario: One of the most common problems in networking, is that you don't have access to all equipment between client and server, but you have to troubleshoot the path between them and to understand where the problem exactly is in order to contact the right person without having the privilege to check the configuration on each router. Fourth scenario: Also, with trace route you can't determine the actual path, for example, the router may direct http traffic to proxy server while leaving other traffic going through a different hop.

6 5

[NANOG-announce] NANOG On The Road - San Diego
by Betty Burke <betty＠nanog.org> 03 Feb '14

03 Feb '14

Colleagues: In partnership, the American Registry for Internet Numbers (ARIN) and the North American Network Operators Group (NANOG) will bring ARIN+NANOG on the Road to San Diego, CA on Tuesday, February 25, 2014. The one day event will be held at the Handerly Hotel & Resort. Please pass along this information to those who would benefit from attending a free event featuring educational sessions, great discussions, and networking opportunities! Morning sessions will get attendees up to speed on Internet number resource management, ARIN technical services, current policy discussions and more. Afternoon sessions will feature NANOG Tutorials on Network Security, IPv6, Traceroutes, BGB, including an update on the NANOG Best Current Operational Practice (BCOP) project. Complete information and meeting links are available on the NANOG website<https://www.nanog.org/meetings/road2/home> . Should you have any questions, please feel free to send them to nanog-support(a)nanog.org. Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

2 1

BGP peer traffic monitoring
by Dennis Burgess 03 Feb '14

03 Feb '14

I have a router with about 20 peers, most are all on a single port (local exchange), how is everyone monitoring traffic to individual peers? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call> -- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace

3 2

BGP multihoming
by Baldur Norddahl 03 Feb '14

03 Feb '14

Apologies for a RIPE question on NANOG, although I believe this issue will soon enough to be relevant for the ARIN region as well. I had a customer ask if we could provide him with BGP such that he could be multihomed. He already has 128 IP addresses from another ISP. Obviously a /25 is a non go for multihoming as everyone are going to ignore his route. I would then need to help him with acquiring a /24 PI. Which appears to be impossible as RIPE does no longer assign PI space and PI can not be reassigned and thus be bought. Is assigning a /24 from my own PA space for the purpose of BGP multihoming considered sufficient "need"? Could he get some PI from another region, such as ARIN? How does others handle this situation? Regards, Baldur

5 5

Re: BCP38.info
by Nick Olsen 03 Feb '14

03 Feb '14

Correct, The assumption is that NAT was in use here. After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was "Spoofed". However, Explained further in detail about what he sees from other IP's on that list. And it clicked when he pointed out how many times 8.8.8.8 and 4.2.2.1..etc. pop up as the src of the reply. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Mark Andrews" <marka(a)isc.org> Sent: Tuesday, January 28, 2014 4:40 PM To: "Jared Mauch" <jared(a)puck.nether.net> Cc: nick(a)flhsi.com, "NANOG" <nanog(a)nanog.org> Subject: Re: BCP38.info Jarad is correct. There is lack of BCP38 filtering in the CPE ASN. Either the packet has gone "probe" -> CPE ->(*) recursive server -> "probe" or "probe" -> CPE -> recursive server -> CPE ->(*) "probe" (*) indicates the packet that should have been blocked depending apon how the NAT worked. In either case the CPE ASN had failed to check the source address of a packet. In the first case the source address of the query to the recursive server. In the second case the source address of the reply back to the probe after it had been through the NAT process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

2 1