November 2013 - Test - lists.nanog.org

Weekly Routing Table Report
by Routing Analysis Role Account 22 Nov '13

22 Nov '13

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 23 Nov, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet Complete listing at http://thyme.rand.apnic.net/current/data-badAS Complete listing at http://thyme.rand.apnic.net/current/data-dsua Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos End of report

1 0

prefix filtering per IRR - practices
by Frank Habicht 22 Nov '13

22 Nov '13

Hi, I have a question regarding what's the most common practice [1] for transit ASs to filter prefixes from their BGP customers when using IRR data. (which of course everyone does...) Would many/most/all/none : a) accept only the prefixes listed in route objects or b) accept these and anything "upto /24" (or "le 24") I was hoping / assuming the latter but I start getting a different impression. Yep, and apart from the current status, the tendency would be of interest. Thanks, Frank [1] after "my network, my rules"

3 2

Super Computer 13: GPUs would make terrific network monitors
by Eugen Leitl 22 Nov '13

22 Nov '13

http://www.networkworld.com/news/2013/112113-sc13-gpus-would-make-terrific-… Super Computer 13: GPUs would make terrific network monitors An off-the-shelf Nvidia GPU is able to easily capture all the traffic of a 10Gbps network, Fermilab research finds By Joab Jackson, IDG News Service November 21, 2013 02:50 PM ET Sponsored by: IDG News Service - A network researcher at the U.S. Department of Energy's Fermi National Accelerator Laboratory has found a potential new use for graphics processing units -- capturing data about network traffic in real time. GPU-based network monitors could be uniquely qualified to keep pace with all the traffic flowing through networks running at 10Gbps (gigabits per second) or more, said Fermilab's Wenji Wu. Wenji presented his work as part of a poster series of new research at the SC 2013 supercomputing conference this week in Denver. Network analysis tools face an extreme challenge in keeping up with all of the traffic of today's larger networks, he said. Adding to the strain, network administrators increasingly expect to inspect operational data in real-time, as it is happening. For processing, today's commercial monitoring appliances typically rely on either standard x86 processors or customer ASICs (application specific integrated circuits). Both architectures have their limitations, Wenji noted. CPUs don't have the memory bandwidth or the compute power to keep pace with the largest networks in real time. As a result, they can drop packets. ASICs can have sufficient memory bandwidth and compute power for the task, but their custom architecture is difficult, and expensive, to program. Nor do they offer the ability to split processing duties into parallel tasks, which is becoming increasingly necessary for watching high-speed networks. GPUs can offer all of these capabilities, Wenji said. They have "a great parallel execution model," he said, noting that they offer high memory bandwidth, easy programmability, and can split the packet capturing process across multiple cores. As their name implies, GPUs were originally designed to render graphics on computer screens. Their architectures, consisting of many processor cores working in tandem, also make them useful as general coprocessors good at inherently parallelizable tasks. In the latest Top500 ranking of the world's most powerful supercomputers, 38 machines used Nvidia GPUs to boost their output. The task of monitoring networks requires reading all the data packets as they cross the network, which "requires a lot of data parallelism," Wenji said. Wenji has built a prototype at Fermilab to demonstrate the feasibility of a GPU-based network monitor, using a Nvidia M2070 GPU and an off-the-shelf NIC (network interface card) to capture network traffic. The system could easily be expanded with additional GPUs, he said. In this setup, Wenji found that packet processing could be considerably accelerated through GPUs. Compared to a single core CPU-based network monitor, the GPU-based system was able to speed performance by as much as 17 times. Compared to a six core CPU, the speed up from using a GPU was threefold. Makers of commercial network appliances could use GPUs to boost their devices' line rates, as well as cut development costs by using pre-existing GPU programming models such as the Nvidia CUDA (Compute Unified Device Architecture) framework, Wenji said. Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab's e-mail address is Joab_Jackson(a)idg.com The IDG News Service is a Network World affiliate.

1 0

rogers.ca contact
by Dennis Burgess 21 Nov '13

21 Nov '13

Got an issue where rogers SWIPed blocks to my customer in prep for BGP peering and advertising, but at the last minute (right before we are to set it up) rogers is saying that we can't advertise it, as they advertise a larger block and that if we advertised it out our other provider it would be considered route hijacking and they would turn OFF the IPs though their network? Off-list is fine ! 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

1 0

ATT Network Security/Mail Admin Team
by Chris Watts 21 Nov '13

21 Nov '13

Hello NANOG, Sorry for the spam, trying to resolve a large issue with AT&T blacklisting my employer (We are a large, well known web security company). Attempts to resolve via the normal channels have failed for the last couple hours and this issue is impacting thousands of AT&T customers and thousands of our own. Emails to my account reps, noc(a)att.com, netsec(a)att.com and tickets go un-responded too. MIS Helpdesk states they have no way to contact the admin team in charge of listings. Would appreciate a off-list contact. Thanks! -Chris

1 0

Issues with Multiple T1's - southwest US
by Khurram Khan 21 Nov '13

21 Nov '13

Hi All, Does anyone know if there are any carrier issues up in Colorado (West Colorado) and New Mexico that would cause a bunch of T1's to go down. We've got a lot of T1's through Level3 and Cenutrylink in that particular area that are impacted. Trying to get a ticket opened through our NOC but the response is slow at the moment. If someone is experiencing a similar issue any input would be appreciated. thank you in advance, khurram

1 0

Dynamic routing through firewall
by Cliff Bowles 20 Nov '13

20 Nov '13

Request for feedback... We have a need for an external partner to dynamically advertise their network to us in two separate data centers. The hitch is that, touching external partners, our edge routers for B2B partners reside in DMZs. Now, to ensure failover from one data center to another when there is a link/device problem, we need to pass dynamic routing updates through each DMZ firewall to core routing at each data center. (yes, the data centers are in sync via backbone routing) We have multiple B2B peers, so we have multiple VRFs on the edge routers that all need to talk to our core routing, but not necessarily with each other... so we are on the hook for both the routing of these tenants as well as the security inspection. The 4 common options we've considered: 1. Routing through the firewall across a tunnel: Pro - relatively simple, Con - occasional MTU issues and the firewalls may not be able to disassemble/reassemble the tunnel packets for policy inpsection. 2. Transparent firewalling: Pro - extremely easy, Con - some vendors cannot support stateful failover in HA pairs, some won't do stateful at all, so you need to open up rules bidirectional (i.e. reply ports GT 1024), plus all the whizbang IDS/IPS goes out the window along with NAT and other stuff, so it will be a very point solution 3. BGP on the firewall: Pro - moderately easy unless the policies get very sophisticated, and firewalls automatically learn where prefixes are automatically; Con - it's BGP on the firewall... neither the network or the security teams are thrilled about it, support calls tend to loop in both teams, a security guy can cause a lot of problems with human error, we've seen some firewalls with memory leak vulnerabilities and experienced issues in the past 4. BGP through the firewall (multihop): Pro - easy to configure, doesn't require routing on the firewall; Con - for every prefix our upstream edge router advertises to our core, we will need statics in the firewall to make sure that it knows where to forward. We can do a default pointing to the edge router with some large summaries pointing back inside (or wherever), but you get the point - the more prefixes that aren't covered by the default, the less scalable it becomes 5. Firewall on a stick: This is untested, but the idea was floated that we could peer the edge router with our core router, but have Policy-routes on every customer VRF setting the next-hop as the firewall. The firewall will apply policy, and (like option 4) use statics to forward to the core. Reverse path traffic would pretty much do the same from Core-to firewall-to edge. It sounds ugly, and we haven't tested it, but we didn't want to toss it. A lot of you work in multi-tenant environments, and some of you are responsible for the security between tenants. I'd like to hear alternatives, if you know of any. And if you use one of the options I mentioned, please say why you chose it and how it works. Finally, if you tried one of the options and it was terrible, please explain. Thanks in advance! CWB ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

2 1

Looking for a Charter Backbone Engineer
by Dylan Ebner 20 Nov '13

20 Nov '13

If there is a Charter backbone engineer on the list could you email me off list. I am having a peculiar issue with a charter connection and support can't seem to figure it out. Thanks Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Minneapolis, MN 55403 ph. 612.573.2236 fax. 612.573.2250 dylan.ebner(a)crlmed.com<mailto:dylan.ebner@crlmed.com> www.consultingradiologists.com<http://www.consultingradiologists.com/>

1 0

Opinions on Fortinet?
by David Hubbard 19 Nov '13

19 Nov '13

Anyone used Fortinet hardware, ideally in both a dual stack and clustered/HA setup, want to share their opinions/experiences with me off list? Looking at some of their stuff. Thanks, David

1 0

Question on routing of Tata AS6453 with their other network AS4755
by Anurag Bhatia 18 Nov '13

18 Nov '13

Hello everyone I was looking around and noticed a pretty bad route from DTAG to Tata AS6453 (basically destination was Tata Comm's Indian network on AS4755). I am not able to understand cause for inefficient routing but I am sure I am failing to understand something which is crazy in their IGP. The result is that route from Europe to India is via Europe > US > Singapore > India rather then direct India. There seem to be quite a few prefixes with these problem, but for this mail question, I am picking two prefixes - one which seems to be having good routing. 202.54.82.0/24 has pretty bad routing while 93.183.28.0/24. I see both prefixes have valid route objects and are originated by VSNL AS4755 to Tata AS6453 in India. Now if we compare trace from Tata's own core router say in Paris from their looking glass, I get: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 202.54.82.1 Tracing the route to RAS55.1.ppppun.vsnl.net.in (202.54.82.1) 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 300 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 525297 Exp 0] 260 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 525297 Exp 0] 260 msec 2 if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec if-3-6.tcore1.L78-London.as6453.net (80.231.130.85) [MPLS: Label 523604 Exp 0] 256 msec if-5-2.tcore1.L78-London.as6453.net (80.231.130.1) [MPLS: Label 523604 Exp 0] 264 msec 3 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) [MPLS: Label 728466 Exp 0] 264 msec * if-1-2.tcore2.L78-London.as6453.net <http://if-1-2.tcore2.L78-London.as6453.net> (80.231.130.122) [MPLS: Label 728466 Exp 0] 264 msec 268 msec* * 4 if-20-2.tcore2.NYY-NewYork.as6453.net <http://if-20-2.tcore2.NYY-NewYork.as6453.net> (216.6.99.13) [MPLS: Label 354225 Exp 0] 276 msec 260 msec 260 msec* 5 * if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46) [MPLS: Label 365409 Exp 0] 304 msec if-11-2.tcore1.NYY-NewYork.as6453.net (216.6.99.2) [MPLS: Label 782881 Exp 0] 256 msec 6 if-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1) [MPLS: Label 361921 Exp 0] 264 msec 264 msec if-1-2.tcore1.PDI-PaloAlto.as6453.net (66.198.127.5) [MPLS: Label 670352 Exp 0] 256 msec 7 if-11-3.tcore2.PDI-PaloAlto.as6453.net (66.198.144.57) [MPLS: Label 321233 Exp 0] 256 msec if-2-2.tcore2.PDI-PaloAlto.as6453.net (66.198.127.2) [MPLS: Label 321233 Exp 0] 260 msec * 8 if-9-2.tcore1.TV2-Tokyo.as6453.net (180.87.180.18) 280 msec 260 msec 260 msec 9 if-2-2.tcore2.TV2-Tokyo.as6453.net (180.87.180.2) [MPLS: Label 581761 Exp 0] 252 msec 252 msec 252 msec 10 if-6-2.tcore1.SVW-Singapore.as6453.net (180.87.12.109) [MPLS: Label 710034 Exp 0] 248 msec 244 msec 248 msec 11 if-5-2.tcore1.CXR-Chennai.as6453.net (180.87.12.54) 244 msec 272 msec 252 msec 12 180.87.36.10 272 msec 256 msec 272 msec 13 172.31.19.94 272 msec 252 msec 256 msec 14 * * 172.25.83.142 288 msec 15 172.25.83.134 !H * * while for other prefix, route is: Router: gin-pye-core1 Site: FR, Paris, PYE Command: traceroute ip 93.183.28.1 Tracing the route to 93.183.28.1 1 if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec if-0-0-0-0.tcore1.PYE-Paris.as6453.net (80.231.154.37) [MPLS: Label 519713 Exp 0] 12 msec if-1-0-0-2.tcore1.PYE-Paris.as6453.net (80.231.154.45) [MPLS: Label 519713 Exp 0] 12 msec 2 if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec if-14-2.tcore1.WYN-Marseille.as6453.net (80.231.154.170) [MPLS: Label 302880 Exp 0] 36 msec if-8-1600.tcore1.WYN-Marseille.as6453.net (80.231.217.5) [MPLS: Label 302880 Exp 0] 12 msec *3 if-2-2.tcore2.WYN-Marseille.as6453.net <http://if-2-2.tcore2.WYN-Marseille.as6453.net> (80.231.217.2) 12 msec 12 msec 12 msec* 4 80.231.200.26 140 msec 116 msec 116 msec 5 172.31.16.193 148 msec 140 msec 144 msec * 6 115.114.71.133.static-chennai.vsnl.net.in <http://115.114.71.133.static-chennai.vsnl.net.in> (115.114.71.133) [AS 4755] 140 msec 148 msec 140 msec* 7 172.29.209.82 [MPLS: Labels 301664/7167 Exp 1] 148 msec 144 msec 148 msec 8 172.31.35.138 [MPLS: Labels 4831/7167 Exp 1] 152 msec 152 msec 148 msec 9 121.242.126.205.static-chennai.vsnl.net.in (121.242.126.205) [AS 4755] [MPLS: Label 7167 Exp 1] 148 msec * 140 msec 10 121.242.126.206.static-chennai.vsnl.net.in (121.242.126.206) [AS 4755] 140 msec 148 msec 140 msec 11 * * * 12 * * * Now if I focus on best route entry in router for both prefixes, I see following: Bad Prefix: 4755 tv2-tcore1. (metric 16148) from *hk2-core3.* (hk2-core3.) Origin IGP, valid, internal, best Community: Originator: 66.110.10.113 Good Prefix: 4755 wyn-tcore2. (metric 10050) *from wyn-tcore2.* (66.110.10.109) Origin IGP, valid, internal, best Community: Now as I understand Paris router is getting bad prefix from TV2 which is their Tokyo router while for other prefix with good routing, route is via their other router on cable landing station in France. Can someone explain me what exactly is happening here? Are they missing some iBGP sessions? It's not perfect mesh & missing route reflectors? Probably both prefixes are originated inside India by different routers but as I understand all prefixes get transit from AS6453 and so is it like AS6453 missing some routes (which seem to be direct) to technically downstream AS4755? Curious to hear your thoughts. Note: I am not worried about issue - it's not really impacting me. Just trying to learn what is wrong in the backbone design here. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin <http://in.linkedin.com/in/anuragbhatia21> | Twitter<https://twitter.com/anurag_bhatia> Skype: anuragbhatia.com

4 4