- Test - lists.nanog.org

a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
by Josh Karlin 10 Jun '06

10 Jun '06

Check out the IAR for "Potential Prefix Hijacks" and if you're coming to this more than 24 hours after the post, do a search on AS 23520 as the hijacking AS. I don't know how long the routes were announced, but they seem to be gone now. Or maybe the IAR is horribly broken, in which case I will be lynched :) IAR: http://cs.unm.edu/~karlinjf/IAR/ Josh

9 11

2006.06.05 NANOG-NOTES BGP tools BOF notes
by Matthew Petach 10 Jun '06

10 Jun '06

(ok, last set of notes for tonight, and then it's off to bed for 90 minutes of sleep before heading back to the convention center. ^_^; --MNP) 2006.06.05 Welcome to the 4th BGP Tools BOF! [slides are at http://www.nanog.org/mtg-0606/pdf/lixia-zhang.pdf Nick Feamster GeorgeTech Dan Massey CUS Mohit Lad and Lixia Zhang, UCLA The Goal sharing some tools develop from our research efforts. hopefully will be useful for operations community. Also to collect input on new tools we would like to see so they can develop them. Routing Configuration Checker Nick Feamster O-BGP data organization tool Dan Massey [slides are at http://www.nanog.org/mtg-0606/pdf/dan-massey.pdf The Datapository by Nick Feamster [I'm sorry, that just sounds *far* too much like something you do *NOT* want your bedside nurse administering...--MNP] Visualizing BGP dynamics using Link-Rank by Mohit Lad Open discussions and demos Nick Feamster Network Troubleshooting: rcc and beyond rcc: router configuration checker proactive routing configuration analysis idea: analyze configs before deployment many faults can be detected with static analysis. rcc implementation. http://nms.csail.mit.edu/rcc/ preprocessor -> parser -> relational database (mySQL), constraints <-> verifier <-> faults verifier is a template checker and set of constraints your configs are checked against. He's looking for GUI developers. very bare-bones command line right now. Parsing configurations--shows some output. He shows examples of the abilene configs, which are non anonymized. show all routers peering with a given AS, can look at route maps in each direction, etc. After running rcc on it, you get a web output which shows relationships--oh, pictures don't matter, with some more grease could be a reasonable representation of your network. Q: Randy Bush asks if it could show which peering sessions are missing? A: Not yet, but it could be added, thank you! Shows processing and errors; you get a page that summarizes the things RCC thinks are errors. Signalling partition? that's a missing iBGP session; he needs some better lingo in places. Also shows anomalous imports, could be intended for traffic engineering; that's "inconsistent policy" in ISP speak. Some of the names will get fixed to make Randy Bush happy. Yes, but surprises happen! link failures node failures traffic volumes shift network devices "wedged" ... two problems detection localization Need to marry static config analysis with dynamic information (route is configured but isn't in the dynamic table) he skips a closer look, just some jargon. Detection: analyze routing dynamics; drill down on interesting operational issues. idea: routers exhibit correlated behaviour blips across signals may be more operationally interesting than any spike in one signalling system. How do you spot things in the churn? Detection three types of events single-router bursts correlated bursts multi-router bursts <---common; and commonly missed using simple thresholds Localization: joint dynamic/static which routers are "border routers" for that burst topological properties of routers in the burst. proactive analysis -> deployment -> dynamic -> reactive detection -> diagnosis/correction -> static -> By going back to the configs, lets you see if it's something happening inside the network, or on the edge. Specific Focus: firewall configuration difficult to understand and audit configs subject to continual modifications roughly 1-2 touches per day federated policy, distributed dependencies each department has independent policies local changes may affect global behaviour (These are pulled from Georgia Tech; 130 firewall configs. Builds static connectivity matrix.) Reactive monitoring...use probes from subnets to verify reachability/connectivity. (immediate) open issues reachability and reliability of controller service-level probes diagnostic tools != service-level happiness policy conformance. Q: can it give suggested remediation, or provide config templates for new routers being added? A: Good idea! OK, over to next presenter. Helps with understanding BGP data. BGP data collection and organization (OBGP) Tool Colorado state university/university of Arizona/UCLA BGP data collection takes lots of BGP data, from RIPE RIS, etc. ISP BGP peer router -> update oreg -> rib+update -> feeds into gigabytes of data, different formats, potential errors enter in, and severe lack of metadata. Other tools can use it, LinkRank, BGP-Inspect, and a bunch of people cite it in reports and research. OBGP motivation Large Volume of Data data from many sources (RIPE, RV, private data) Long time scales and very recent (real-time?) data Slightly different formats RIPE/RV use different naming conventions different dump intervals different timezones for older data Lack of MetaData would like to only see desired peers and desired update types Possible errors in the data are updates missing due to log errors? what is lost due to session failures? So, OBGP is the "thing" in the middle. A simple perl script called oBGP that simplifies data. Features: Uniform data organization consistent and easy to use for scripts consistent view of multiple monitoring points annonatations/labels can be stripped, help locate useful data easily table transfer detection distinguish updates from data collection peering Data inconsistency detection and correction understand and fix possible data errors Uniform data organization Uniform naming and organization conventions for all monitoring points RIB and update data split by peer One rib and update file per peer per day, dumped at beginning of the day. Labels and Annotations are more interesting Existing format labels update as announce (A) or Withdraw (W) also includes some STATE messages OBGP enhances the labels Adds a status message Adds an update type More STATE messages route table dump table transfers A:INC:DPATH (shows it's an announcement, it's incremental, and it's updating the destination path OBGP Added labels |<original update type:<status info>:<OBGP udate type>| <orginal update type> add E for error correction <status infor> INC incremental update TT table transfer update RIB: correction update <OBGP update type> new announcement duplicate announcement change in AS path (DPATH) change in other attribute (not ASpath) withdraw duplicate withdraw If you don't need this, it's just a few extra characters in your log; but could be useful. Using Labels to filter data example: find suballocation hijacks Only need new announcements and withdraws so 83% of the update data can be ignored. Is the collected data accurate? May lose updates due to data collection errors start with an accurate RIB apply updates in log should match the next RIB dumped by the router modulo some race conditions near dump time does this clearly work with RouteViews? 85 of 111 peers from RV suffered inconsistencies in 2006 May About 25 were rock solid right on. One peer had 378,998 inconsistencies in one day. Is this evenly distributed? Not really. Inconsistencies and session failures session down: RIB-IN drops to empty session up: table transfer (failure to recognize a session dropping) look for table transfer, can estimate where sessions went down and came back up. How long does an error persist? Lifetime of correction updates can last 43 days! If you miss an update, you can have bad data for a long, LONG time!! Correction updates added by OBGP E:RIB updates; figure a change in RIB had to happen due to a routing update that was missed. Summary: consistent format adds label to easily sort and limit adds additional state messages identifies and corrects update error messages http://netsec.cs.colostate.edu/tools.html [NOTE URL at end of slide deck is WRONG --MNP] If you're using RouteViews or RIPE RIS, consider using this tool, and give feedback! Randy is using it to check propagation of his prefixes, and for research. RIPE NCC--performance of these tools? With multiple collectors, perl didn't scale. Perl is mainly demonstration. He pulls data from RIPE and has it stored, hopes to make it public some day. he has stacks of disks with text format data for easy search; considering binary format for it. Randy--on that subject: Matt Rowan, he's spent half his life getting the data out of the system; make it in funny format and sticking it back in, Disk is cheap! Look at raw data. With binary data, what tools are there? Hard enough to look at router configs. One tool to look at binary data, lots of tools to look at text. Q: Matt asks how much space it takes to store data A: Takes about 1TB to store all the RIS data. Q: Are they planning to make it available to the public? A: Well, he'd like to host it at route-views or ripe, rather than create a new site. How long does it take to process the RIPE data? Need a fast CPU, will take a couple of days to process the data. Q: can it deal with live updates? It can keep up with route-views and RIPE, but that's not live; there is a lag; route-views is every 15 minutes. The update files sometimes take 8 hour lags to show up on the site. The Datapository Nick Feamster and David Anderson? Architecture: raw data -> compute engines-> storage and DB plus archival storage ->analysis. Very alpha right now datapository.net NOT realtime! inserting data in greedy approach; when he needs it, he inserts it, and starts running queries. You can see a list of feeds, he has abilene but not route-views yet. Can restrict it, look at neighbor ASes, etc. see it in graphical form, or list form can diagnose issues, has an XML query engine and output for programatically accessing it. If you use matlab, could be interesting to throw this into a multidimensional time series. Randy Bush notes all his tools take MRT output. Oh, he can spit out sparse matrices He could spit out MRT format; he has python that speaks MRT format. he'll look at adding that. Do spammers hijack BGP routes? Theory: 1 announce BGP route for mail server 2 send lots of spam 3 withdraw route, becoming invisible reality? let's check! export formats Web interface XML/RPC text-based output programmatic interface output to matlab and per Randy Bush, MRT format would be good too! BGP-Inspect vs this tool? this has additional datasets beside BGP, like active probes, traffic, etc. This has a better collection setup as well; unified formats. Mohit will do last one, Link-Rank show the dynamics Visualizing BGP dynamics with Link-Rank constructing rank-change graphs closest to BGPlay. weight is number of prefixes reached across that link. weight changes are on specific links, can do easy root-cause analysis. Activity bar--routing activity across time. http://linkrank.cs.ucla.edu/ green shows gains, red shows losses, sums all gains, sums all losses. visualization graph of where prefixes gained and lost. again, green are links that gain, red are links that lost. other observation points highlighted in orange May 23rd, instability 293 flapping from 1239 to 3356 for multiple observation points, dashes are lost, solids are gains. highlight sources and sinks cutting one link explains most of the errors 3561 to 4134 link issue case II, one node that sucks in all the flows, no single link, 3356 Ongoing work, automated root cause identification min-cut scheme characterizing Can look at destination link-rank graphs, see how the rest of the internet change going to you. connectivity issues to 7018 should show your prefix hijackings moving from one link to another. Could simplify this to BGPlay if you wanted. open source http://linkrank.cs.ucla.edu/ current version download client, configure... Future version work with any BGP data Q: Matt asks when we'll be able to use our own BGP data; A: about 4-5 months, hopefully! Haven't looked at netflow yet. Q: Randy Bush. Common problem we all face. I'm at 42 peering points; my neighbors are X. I have route views dumps, I have my BGP dumps. I have my netflow data. Want a whatifatron that shows what happens to my traffic if depeer someone, or add someone, or peer with SingTel in singapore, or stop peering with Joe in SF. That's a question many operators ask every day. A: Matt notes that if they can solve that question/write something that does all that, they'll have Arbor and others beating on their door. ^_^ Panel wraps up at 1728 hours Pacific time.

3 2

2006.06.07 NANOG-NOTES TCP Anycast--don't spread the FUD!
by Matthew Petach 10 Jun '06

10 Jun '06

(this was one of the coolest talks from the three days, actually, and has gotten me *really* jazzed about some cool stuff we can do internally. Huge props to Matt, Barrett, and Todd for putting this together!! --Matt) 2006.06.07 TCP anycast, Matt Levine, Barrett Lyon with thanks to Todd Underwood TCP anycast, don't believe the FUD Todd Underwood is in Chicago Barrett Lyon starts off. [slides may eventually be at: http://www.nanog.org/mtg-0606/pdf/tcp-anycast.pdf IPv4 anycast from a network perspective, nothing special just another route with multiple next-hops services exist on each next-hop, and respond from the anycast IP address. It's the packets, stupid perceived problem: TCP and anycast don't play together for long-lived flows. eg, high-def porn downloads [do porn streams need to last more than 2 minutes?] some claim it exists, and works... yes, been in production for years now. Anycast at CacheFly deployed in 2002 prefix announced on 3 continents 3 POPs in US 5 common carriers (transit) + peering be sensible to who you peer with Effective BGP communities from upstreams is key keep traffic where you want it. Proxy Anycast proxy traffic is easy to anycast! move HTTP traffic through proxy servers. customers are isolated on a VIP/virtual address, which happens to exist in every datacenter. Virtual address lives over common carriers allowing even distribution of traffic state is accomplished with custom hardware to keep state information synchronized across proxies. Node geography anycast nodes that do not keep state must be geographically separated Coasts and countries work really well for keeping route instability largely isolated. Nodes that are near by could possibly require state between them if local routes are unstable. IP utilization "Anycast is wasteful" people use /24's as their service blocks; use 1 /32 out of a whole /24. Really? How much IP space do you need to advertise from 4 sites via unicast? Carriers and Peering for content players, having even peering and carriers is key. you may cause EU eyeballs to go to CA if you're not careful with where you peer with people. having an EU centric transit provider in the US without having the same routes in EU could cause EU traffic to home in the US Use quality global providers to keep traffic balanced. When peering... keep in mind a peer may isolate traffic to a specific anycast node Try to peer with networks where it makes sense; don't advertise your anycast to them where they don't have eyeballs! Try to make sure your peers and transit providers know your communities and what you're trying to do, and make sure you understand their communities well! Benefits of Anycast. for content players moving traffic without major impact or DNS lag provides buffers for major failures allows for simplistic traffic management, with a major (potential) performance upside. it's BGP you don't control, though, so not much you can do to adjust inbound wins. HTTP has significant cost to using DNS to try to shift traffic around; six or more DNS lookups to acquire content; anycast trims those DNS lookups down significantly! Ability to interface tools to traffic management. No TTL issues! Data, May 9, 2006 Renesys: monitored changes in atomic-aggregator for a CacheFly anycast prefix AS path changes and pop changes Keynote: monitored availability/performance of 30k file Revision3: monitored behavour of "longlived" downloads of DiggNation videocast--over 7TB transferred. Renesys data: 130BGP updates for may 9th; low volume day stable prefixes 34 distinct POP changes based on atomic aggregator property on prefixes 130 updates is considered a stable prefix. SJC issue: thirty-five minute window, 0700 to 0735 UTC, saw: 98 updates, 20 actual pop changes based on atomic aggregator changes, all from one san jose provider, fail from SJC to CHI back to SJC unable to correlate these shifts with any traffic changes; mostly likely we don't have a big enough sample size. possibly just not a lot of people using those routes. BGP seems stable--what about TCP flows? AVG time between SJC and CHI and back again was about 20 seconds; very quick on the trigger to go back to SJC; would break all TCP sessions happening at the time. For the most part, TCP seems stable. Keynote: 30k download from 31 locations every 5 minutes, or average of 1 poll per 9.6 seconds compared against 'Keynote Business 40' data collected on May 9, 2006 represents short-lived TCP flows, though. Orange line is Keynote business 40 pegged 100% availability load time was lower than the business 40. (0.2s vs 0.7s for business 40) Revsion 3 data monitored IPTV downloads for 24 hours (thanks, jay!) span port; analyzed packet captures look for new TCP sessions not beginning with SYN compare that against global active connection table. looked for sessions that appeared out of nowhere. Long-lived data 683,204 TCP sessions. anything less than 10 minutes thrown out 23,795 sessions lasted longer than 10 minutes. average file size for the day was 300MB 4 TCP sessions moved between POPs. 0.0006% total pop switch 'failure' rate 0.017% for long-lived (more than 10 minutes) sessions. only looking for sessions that starts in A, moves to B; they dropped 0 of them, due to their state preservation mechanism. you would have dropped 4 out of 23,795 connections with this without state preservation mechanism. Anycast gotchas. large scale changes in provider policies can impact your traffic, up to you to figure out what happened. "Things that are bad" become much, much worse, notably per-packet load balancing across provider or topologicl boundries. eg customer with 2 T1s between Anaheim and Dallas Sprint POPs. per-packet load balancing across the two, before the anycast nodes shared state information between nodes was probably still seeing performance issues. conclusion: stateful anycast is not inherently unstable, and failure/disconnect rates are inline with offering unicast services this is counter-intuitive to some published conclusions from previously published data. some other company did work in this; is there other failure rate data available? Verisign said to not do TCP anycast, but they didn't publish failure rates for TCP. Need to see where TCP really, really breaks. "Trust us, it works" widespread failures cause havok; however, internet doesn't go crazy *that* often. Transitioning to IPv6: as for the move to IPv6, there *is* a plan for it; plan is to hope they're dead by the time customers actually demand v6. what you can do stop telling people TCP doesn't work if you haven't tried it yourself! Just makes them mad to hear it. if your application doesn't handle TCP/IP failures gracefully, don't run anycast, in fact don't run it on the internet at all. SMTP and HTTP work well; browsers support reset and retries, for example Experiment with other applications share your experiences--want to know if their results are anomalous, if they're crazy, or if this really does just work. Q: Mark Kosters, Verisign: did one presentation. It depends on client base; their client base was very far flung, many problems in far reaches of internet and per-packet load balancing showed up in their data. How big a clientele spread do you want to reach, do you hit core, or far edge? A: they try to reach customers where they get money for the material being served; not necessarily geared for global connectivity. Yes, unicast in outlying cases will be more robust, but doesn't scale as well. Q: Randy Bush, IIJ, 10th anniversary of much of the Anycast UDP deployment. Response of "it's good if you engineer it" applies to most things. They wanted to narrow peering and topology; Randy says there are exactly cases where that is exactly NOT true. In 1996, they needed to shed traffic off their backbone; had to support streaming, they did TCP from all anycast to all peers, exact opposite of what they were calling for. A: This talk is specific to content they deal with directly, was engineered for their customer's content and needs. Main point is that it's not as bad as people claim, and benefits can be substantial. And yes, you will need to engineer it to your particular case. Q: Bill Woodcock: over past 10-12 years, many have seen long-lived TCP connections with 0.01% failure rates; Mark's results with j-root were suprisingly different. Methodologies were sound, so why might we be seeing these bimodal results? A: different results trying to be achieved. Streaming video vs universal reachability for DNS. Perhaps worth looking at the specific needs being aimed for? Dalnet runs with very long lived TCP connections, some last for months, they're not picky about who they get transit from, and they're anycasting their IRC servers. Q: Danny McPherson, 10 years ago people were using this to try to pass stuff faster to try to make Keynote numbers look better. Origin AS, announcing prefixes from multiple places, may trigger security, prefix hijacking alerts; the state sharing they do may have helped considerably. A: Not as scary as people thinks it is. some open source state synchronization tools would be nice. If someone can do some work in that area, they'd love to support it. Q: Michael ?, UCB: thanks, good to see studies like this! Not all applications/protocols can handle this; hard to necessarily then generalize this to "TCP" in general like that. A: they meant application more than protocol. Q: TCP has methods of dealing with out-of-order packets. not many people use per-packet load balancing; you don't know what might change in future, though. Q: Matt Peterson, can you give description of size of files being moved around? Also, state mechanisms--you mentioned open source--is it something you might consider releasing? A: content, don't remember exactly, look at Revision3, see their show. Average file size was 350Mb, range from 200-650MB. For their state, they hacked stuff together themselves; they'd be happier to support something community based, rather than release their code. any more Q ask them offline, we HAVE to keep moving to get out of the convention center ontime!!

2 1

2006.06.07 NANOG-NOTES Smart Network Data Services
by Matthew Petach 10 Jun '06

10 Jun '06

(I'm starting to guess I'd finish sending these out faster if I stopped falling asleep on my keyboard so often... --Matt) 2006.06.07 Welcome to Wednesday morning http://www.nanog.org/ click on Evaluation Form Let us know how the M-W vs S-Tu format; next time will be S-Tu due to ARIN joint meeting, but need more feedback! Bill Woodcock, been on program committee And lightning talk people need to send their slides to Steve Feldman!! Elliot Gilliam, ISP community, notifications to Smart Network Data Services [slides are at http://www.nanog.org/mtg-0606/pdf/eliot-gillum.pdf AGENDA postmaster services SNDS problem goal today tomorrow motivation feedback/dialog questions/discussion Postmaster--starting point for any issues you have sending mail into Hotmail/MSN Live. It's like AOL skunkfeed, you can do junk mail reporting. Lets you see what bad stuff is coming from your domain. SenderID Site is at: http://postmaster.msn.com/snds/ Problem: bad stuff on the internet (spam, phishing, zombies, ID theft, DDoS) makes customers unhappy. Solution #1 -- try to stop it before it hits customers doesn't really *solve* the problem Solution #2 -- take what we learn, apply it upstream, get more bang for buck #2: #1 is too low ISP-centric efficiency solution #1, n ISPs have n-1 problems, total is O(n^2) n ISPs have 1 problem (themselves), total is O(n) reduces work of the overall system. Crux today people and ISPs are measured by how much BAD stuff they *receive* Not judged by what they send out. similar to healthcare industry no tight feedback loop to ISP behaviour nice quotes on slides http://www.circleid.com/posts/how_to_stop_spam 7 step program (like 12 step, but shorter) 1: recognize the problem: SNDS 2: believe that someone can help you : Me 3: Decide to do something : You 8: Make an inventory of those harmed : SNDS 9: Make amends to them : Tools 10: Continue to inventory : SNDS 12: Tell others about the program : You What is SNDS Website that offers free, instant access to MSN data on activity coming from your IP space data that correlates with "internet evils" informs ISP to enable local policy decisions Automated authorization mechanism uses WHOIS and rDNS users are people not companies A force multiplier attempt. You can do it on your own, no need to sign up your company officially as long as you're an rWHOIS/WHOIS contact. SNDS goal: provide info which allows ISPs to detect and fix any undesired activity. qualitative and quantitative data "No ISP left behind" stop problems upstream of the destination Bring total cost of remediation to absolute minimum keep service free Make internet a better place. We have data! Windows Live Mail/MSN Hotmail is a spam and spoofing target. 4 billion inbound mails/day 90/10 spam/ham by filtering technologies User reports on spam, fraud, etc. Inbound mail system slide--ugly to read, too dark. SNDS website slide shown. You can see daily aggregated traffic from your network; activity periods, IPs, commands and messages seen on port 25, samples of exchanges. Filter results on your mail rate at which users press "this is junk" on your mail. Trap counts for when IPs hit their junk filters. comments column is catch-all for anything else they might put in; like open proxies, when tested positive. "export to CSV" button, so you can feed the data in to your own systems if you want. Today's Scenario Illustrate magnitude and evidence of a problem. additional resources monitoring infrastructure SNDS Stats 2500 users mostly senders 67 million IPs 10-20% of inbound mail and complaints Output drops by 57% on /24+ when monitored by SNDS SNDS tomorrow Usability signup by ASN better support for upstream providers access transfer Utility programmatic access Data virus-infected emails phishing honeymonkey sample messages Expand the the coverage, try to hit more of the problems on the net. Provide sample messages, compelling evidence when facing customers This hasn't shipped yet, it's what he's hoping to have in a month or two. Tomorrow's Scenarios Lowered barrier to entry recurring "cost" ISP types end-user tier 1/2 monitoring, tier 2/3 directly attack more than just spam virus emails -> infected PCs, outbound virus filters phishing/malware hosting -> takedowns. Is asymmetric routing a sign of people trying to launch hidden abuses of the net? Looking to hit more issues, like spotting virus-laden messages; either infected, or an open relay. Hoping that automation speeds response. Safety Tools Stinger: http://vil.nai.com/vil/stinger Nessus: http://www.nessus.org/ [oy, read the list from his slide, it's long.] green items on the list are free, others are pay-for products. Pay-for isn't necessarily a bad thing if you get benefit! Safety tool breakdown from MSN on next slide. Motivation: Hypothesis: everyone benefits Customers: infected uses get fixed safer, cheaper, better internet experience ISPs solution #1 isn't solving the problem altruistic is the "new" selfish Microsoft only benefits if everyone else does make business case why they're doing this. They need to stop paying costs of trying to deal with spam. Wants to get benefit of being one of the people seeing a cleaner internet ISP Motivation Customers they're unhappy, unsafe they like people who fix that be the hero retain customers win new ones fixing has more benefits than bandaging [bandaging is just sticking fingers in the dike, it doesn't scale, eventually we run out of fingers to stick in the holes] cost reductions bandwidth--slow growth demands support--fewer complaints to your help desk. Community NANOG Motivation alternatives Industry scorecard public recognition public shame Logo ISP program--how clean are you? Business case Some nice quotes from different people around the business case needed here. appeal to cost reduction and revenue generation this is starting to happen. let your sales and marketing people know about this. Boston university business case, students arriving with computers presented danger/load to their help desk. Qwest provides windows/one software to their users. Feedback: usability--how easily can you work with it? utility--what can you do? what's missing tools to aid customer remediation need IPv6 support at some point how do ISPs see cost vs benfits costs, benefits, NANOG aggregation how do we get critical mass? msn-snds(a)microsoft.com Discussion: How does SNDS fit into the larger ecosystem relationship to senderBase.org SCOMP/JMRP REACT adam, rick at support intelligence Yahoo is working on a system like this, Irene Lai is here to work on that, email her if you're interested. Should/how do other ISPs provide this? common schema, authorization, authentication federation, delegation, aggregation Forum bof/track? NANOG/MAAWG? Mailing list: upstream(a)mipassoc.org Conclusion: http://postmaster.msn.com/ http://postmaster.msn.com/snds/ Try it! tell people about it! Q: Matt asks whether Microsoft will point their own systems at it, since Nick Feamster's presentation showed on slide 12 that Microsoft was #10 on the list of spam *sources* that his honeypots saw? A: Yes, he is connecting the systems that track mail sending from Hotmail to this as well, so that they can start making sure they're cleaning their own house as well. on to next talk.

2 2

2006.06.06 NANOG-NOTES MPLS TE tutorial
by Matthew Petach 10 Jun '06

10 Jun '06

(still here, just been really busy at work today; will try to finish sending the notes out tonight. --Matt) 2006.06.06 MPLS TE tutorial Pete Templin, Nextlink [slides are at: http://www.nanog.org/mtg-0606/pdf/pete-templin.pdf http://www.nanog.org/mtg-0606/pdf/pete-templin-exercise.pdf He works in a Cisco shop, no JunOs experience Operator perspective, no logos Traffic engineering before MPLS --the "fish" problem. two parallel paths, one entry router, one exit router, you end up with all traffic taking one path, not using the other path. IGP metric adjustments can lead to routing loops hard to split traffic No redundancy left over if both paths filled, but can be good for using 2 out of 3 paths. MPLS TE fundamentals Packets are forwarded based on FIB or LFIB FIB/LFIBS built based on RIB TE tunnels; TE tunnel interface is a unidirectional logical link from one router to another. Once the tunnel is configured, a label is assigned for the tunnel that corresponds to the path through the MPLS network (LSP) TE tunnel basics Once traffic is routed onto the tunnel, the traffic flows through the tunnel based on the path. Return traffic could be placed onto a tunnel going the opposite direction, or simply routed by IGP Key terms for TE Headend router on which the tunnel is configured Tail destination address of tunnel Midpoint router(s) along the path along the tunnel LSP Basic TE config Global: mpls traffic-eng tunnels IGP: must be OSPF or IS-IS mpls traffic-eng rouer-id Loopback0 mpls traffic-eng <area X | level2> physical interfaces mpls ip mpls traffic-eng tunnels tells IGP to share TE info with other TE nodes interface TunnelX ip unnumbered loopback0 borrow the loopbak's address so we can forward traffic down the tunnel tunnel mode mpls traffic-eng tunnel destination <a.b.c.d> tunnel tail tunnel mpls traffic-eng path-option 10 dynamic find a dynamic path through network best path with sufficient bandwidth will discuss path selection in a bit Where are we at? Tunnels go from headend to tail end through midpoint routers over a deterministic path we know what commands go on a router for the global physical interface tunnel interface commands TE and bandwidth Physical interfaces can be told how much bandwidth can be reserved (used) ip rsvp bandwidth X X TE tunenls can be configured with how much bandwidth they need: tun mpls traff bandw Y Tunnels will reserve Y bw on outbound interfaces, and find a path across the network wth X(unused)>Y BW. This prevents oversubscription, or at least helps control it. You can allow for burst room, but for now we'll stick with static, non-oversubscribed links. TE BW operators can adjust the tunnel bandwidth values over time to match changes in traffic. If tunnels are dynamically placed, the tunnels will dynamically find a path through the network with sufficient bandwidth, or will go down. TE auto-bandwidth magic Tunnels can be configured to watch their actual traffic as in "shw int <blah>| inc rate" every five minutes, and update their reservation to match, at periodic intervals. Dynamic reservations to match the live network Bandwidth is 'reserved' using RSVP but not "saved" for TE Often buys enough time to identify the surge, see where the traffic is coming/going. The number is only a number in control plane; no actual impact on data plane, no shaping, no control on real data flows. tunnel mpls traffic-eng auto-bw frequency Y each auto-bw tunnel does "sh int" to capture its rate every 300* seconds each auto-bw tunnel updates "tunn mpls traff bandwidth X" every Y seconds The config actually changes; this will impact your RANCID tracking. It uses highest measured rate during the interval Y May want to tweak your load-interval, since it's a decaying function over time; 5 minute is a fairly smooth value. May need to tweak config check-in system to avoid getting flooded with bandwidth adjustments. Covered: TE tunnel basics router config basics general concepts about TE and bandwidth In this case, the shortest path that has X BW available for reservation actually, bw X at or below priority Y, but that's later. SPF calculations step 0: create a PATH list and a TENT list step 1: put "self" on PATH list. step 2: step 3: put PATH nodes' neighbors on TENT list step 4: if TENT list is empty, stop. step 5: jump back to step 2: Example exercise -- calculate router A's best path to router D using the handout. CSPF notes No load sharing is performed within a tunnel; as soon as a path is found, it wins CSPF tiebreakers: lowest IGP cost largest minimum available bandwidth lowest hop count top node on the PATH list Creating paths -- can be created dynamically, or statically via static paths. Dynamic: tunnel mpls traff path-option X dynamic Explicit paths paths can be crated manually by explicitly creating a path "ip explicit-path name <name?>" next-address X next-address Y tunnel mpls traff path-option X explicit name blah Paths can be created manually by explicity configuring a path that excludes an address; use any link EXCEPT this one. for backup links, oob links, etc. can't combine exclude-address and next-address on the same explicit path. Q: if all other paths go away, will an excluded path still be used? A: only if you have a fallback option of "dynamic" can't both include and exclude on same path. A TE tunnel can have multiple path options. lowest cost path option is attempted higher-cost paths attempted sequentially until a path can successfully established, or failure Usually best to have a dynamic option as the highest-cost option, to ensure you don't fall back to IGP (and lose traffic matrix accounting!) CSPF checks tunnel path options in sequence for one that has sufficient information. OK, we've got tunnels now--how do we share info around the network? TE info is shared around using IGP available bw per interface eight priority levels high priority tunnels can push low priority tunnels out of the way some dynamics as far as tunnel vs interface sizing administrative weight (TE specific IGP metric Affinity (customizable) You can configure different interfaces with bits that indicate territorial restrictions, or high-latency links, etc. Use the interface affinity bits, and match/exclude tunnel affinity bits to include or exclude certain links. This information is distributed immediately for "significant" changes periodically for "insignificant" changes immediately, if a change causes an error Significant changes occur when available bandwidth on an interface passes preset thresholds customizable with 16 thresholds. (based on percentages) Key points where information is passed from device to device. Insignificant changes flooded every 3 minutes, significant flooded immediately, by default. If a new path (dynamic or static) appears that's better than the current one re-optimize periodically, every hour from tunnel bringup by default manually "mpls traffic-eng reoptimize" event-driven when a link comes up optional: requires "mpls traff reo events link-up" not so good with flapping links, though. If you have a flapping link, TE tunnels will stay off that link for about an hour; you have flap dampening in your network. Up next, how to put IP traffic on tunnels static routes "ip route x.x.x.x y.y.y.y tuZ" policy-based routing route-map PBR permit 20 match ip addr ACL set ip next-hop tunX Autoroute Autoroute treat this tunnel as though it's a logically directly connected link to the tunnel tail updates the local router's RIB/FIB with "tunnelX" in place of the IGP next-hop; preserves the IGP cost all the way to the tail. One line of config per tunnel; it updates the LOCAL router's RIB/FIB; prior routers not made aware of this router as a next-hop for the tunnel tail. This is supported for IS-IS, but can be more difficult; you increase number of links in your IGP pretty quickly. tunn mpls traff autoroute announce autoroute and load-sharing parallel tunnels will load-share inversely proportional to their configured bandwidth auto-bandwith can really muck with these values! load-sharing can be tuned separately with "tunn mpls traff load-share X" Limited to CEF 16 buckets, depending on when it measures, can end with values drifting apart. If you use same "X" on two tunnels, they will load share equally. IGPs can load-share over equal-cost paths BUT TE tunnel cannot load-share over multiple physical interfaces TE diagnostics show ip route X sh run int tuX sh ip rsvp reservation show mpls traff tun suboptimal constr none shows headend tunnels taking suboptimal paths to the tunnel tail (eg, different from IGP best path) show mpls traff tun detailed info for all tunnel headends bandwidth info (auto-bw) MPLS labels, hop by hop path show mpls traff tun role <head|middle|remote|tail> remote is non-headend (not originating or ending on this router) show ip rsvp interfaces shows max allocated bw on an interface. MPLS VPNs if a tunnel tail is not the egress PE, add "mpls ip" to the tunnel configuration PE-P-P-PE-PE --adds another label onto the stack. If the last router VPN isn't on penultimate router, the TE label won't be recognized, it'll be dropped. This adds the TE label back on, keeps the LDP label as well as the VPN label still intact Add "mpls ldp discovery directed-hello accept" to config If you have unidirectional tunnels, that way when you're bringing up tunnels LDP info can be exchanged as you're going. Multicast: RPF calculations are normally based on unicast RIB Unidirectional TE tunnels cause RPF failures add "mpls traffic-engineering multicast-intact" to IGP config Bases RPF checks on RIB BEFORE TE tunnels are substituted Questions? templin at templin.org Swap to looking at operational network for some troubleshooting views. About 150-200Mb traffic aggregate, 4 pops, DAL and Houston, four parallel DS3s, 2 between core1's and 2 between core2's 30mbit IP RSVP reservation; TE kicks in, and moves traffic. Houston intercore links tends to not have traffic unless TE has kicked in. Aggressive 15 minute auto recalculations, since surprises can kick up fairly quickly. Room heads for cookies at 1526 hours Pacific Time

1 1

2006.06.07 NANOG-NOTES DNSSEC bootstrapping with DLV
by Matthew Petach 10 Jun '06

10 Jun '06

(last notes from NANOG37, yay! I definitely fell further behind this time around than in Dallas. Unfortunately, I don't think I'll be allowed to go to St. Louis, so I probably won't be able to provide notes for NANOG38. --Matt) 2006.06.07 Deploying DNSSEC--bootstrap yourself Joao Damas, ISC [notes are at http://www.nanog.org/mtg-0606/pdf/joao-damas.pdf DNSSEC status standard is complete and usable some minor nits with regards to some privacy issues 2 implementations: NSD, BIND at least one DNSSEC aware resolver (BIND 9.3.2 and later) Really, you just need some data. DNSSEC follows a hierarchical model for signatures. sign the root zone get root zone to delegation sign TLDs get TLDs to delegation-sign SLDs, etc. Today, the root zone remains unsigned likely will be this way for some time Very few TLDs have signed their zones and offer delegation signatures .se, .ru, .org DNSSEC provides for local trust anchors you can use trust-anchors clause in BIND problem: if you have too many, it becomes a nightmare to maintain, so it doesn't get used. very manual process Enter DLV, domain lookaside validation it's an implementation feature, not a change to the protocol; matter of local policy enables access to a remote, signed repository of trust anchors, via the DNS implemented in BINDs resolver so far more to follow? unfortunately, requires you to trust remote repository DLV lookup a DLV enabled resolver will try to find a secure entry point using regular DNSSEC; only if it fails is DLV used, if it is configured. [picture of DLV lookup chain] On resolver (BIND) add to named.conf in the options section //DNSSEC conifg dnnssec-enable yes dnssec-lookaside . trust-anchor dlv.isc.org.; get the key from ISC's web: http://www.isc.org/ops/dlv ISC is operating a DLV registry free of charge for anone who wants to secure their DNS Likely some closed orgs will use their own (eg mil) have a look, start using it! Any questions? Q: Mark Kosters, Verisign: Any plans to configure DLV registries per TLD? A: BIND code only allows for one right now. Q: Would be good to allow it to be configured per TLD. Q: Randy Bush, IIJ: some feeling or understanding how IANA, root would validate keys/zones it has keys for; don't understand how ISC proposes to validate keys it would be storing. He suggests they publish the security policy. A: In case of registrars proxying keys; they trust registrar. Otherwise, it's like PGP; show me your face, show me your key. Q: Paul vixie, ISC, following up on Mark Kosters; you can only have one DLV for any point in the namespace; you can specify a different one for a TLD than root; that allows a TLD DLV to be paranoid, like .mil. who doesn't want to trust anyone else with key information. If every TLD wanted to do that, they would find high levels of cut-and-paste fatigue, so ISC will operate a root level DLV server as well. Q: Rick Wesson, runs Alice's Registry, a small registrar. he's considering doing this, he can help DNS holders register their keys if people are interested, and will help get them into the DLV tree. Q: Sam Wiler?, Sparta: concerns from Randy about how ISC will authenticate the entries. Registrars should consider running their own DLV servers, as they have the relationship with the domain holder. Code? Apparently you don't need code... NANOG 37, ending slides. 425 attendees, 118 first timers lots of countries most USA, 11 canada, scattered others. ISP, then NSP, then other categories. top 3 companies represented: Cisco, Juniper, Equinix HUGE thanks to Rodney Joffe and Neustar for puling off a miracle to make this happen at the last minute! Thanks to sponsors, bear, gear, other. Susan R Harris, many thanks to her for all the work she has put in over the years and to make this happen! Also huge thanks to all the other people at Merit And we'll see you in St. Luis, Oct 8-10th, joint meeting with ARIN, things set in stone. Network will go down in 30 minutes or so--pack up and go home! :) I think that was the fastest closing I've seen at a NANOG yet. ^_^;;

1 0

2006.06.07 NANOG-NOTES Anycast benefits for k root server
by Matthew Petach 09 Jun '06

09 Jun '06

Break ends at 11:40, PGP signing will take place, and don't forget to fill out servers. ANYCAST fun for the final sessions. Lorenzo Colitti, RIPE NCC [slides are at: http://www.nanog.org/mtg-0606/pdf/lorenzo-colitti.pdf Agenda: introduction latency client-side server-side Benefit of individual nodes Stability Routing issues Why anycast? root server anycast widely deployed c, f, i j, k, m at least reasons for anycasting provide resiliency: eg contain DOS attacks spread server and network load increase performance but is it effective? measure latency ideally for every given client, BGP should chose node with lowest RTT. does it? from every client, measure RTTs to anycast IP address service interfaces of global nodes (not anycasted) for every client, compare K RTT to RTT of closest global node a = RTTk/min(RTTi) if 1, BGP is picking right node if > 1, BGP picks the wrong node if <1, seeing local node. Latency with TTM: methodology DNS queries from ~100 TTM test boxes dig hostname.bind see which host answers extract RTT take min of 5 queries check paths to service interfaces; is it same as prod IP according to RIS, mostly 'yes' TTM probe locations, mostly in europe Latency with TTM: results (5 nodes) most values are close to one; generally BGP doing pretty good job. from 2 nodes to 5 nodes (2 nodes, April 2005) (5 nodes, April 2006) mostly same results, clustered around one, whether 2 or 5 nodes. consistency of 'a' over time average of that over time. TT103 is outlier calculated over time, threw out that one outlier. results are pretty consistent. average is little higher than one, mostly consistent over time measuring from servers TTM latency measurements not optimal locations biased towards europe limited number of probes (~100) don't reflect k client distribution how to fix? ping clients from servers much larger dataset methodology process packet traces on k global nodes extract list of client IP addreses ping all addresses from all global nodes plot distribution of 'a' 6 hours of data 246,769,005 queries 845,328 unique IP addresses CDF of 'a' seen from servers results not as good as seen by TTM only 50% of clients have a = 1 about 10% are 4x slower/farther. probably due to TTM clustering in europe latency conclusions 5 node result vs 2 node, comparable, at least in TTM non-TTM results not so rosy. How many nodes are needed--is 5 enough? evaluate existing instances how to measure benefit of an instance? Assume optimal instance selection that is, every client sees closest instance this is upper benefit of benefit consistent to see if we've reached diminishing returns for every client, see how much its performance if the chosen node didn't exist. B is loss factor, how much a client would suffer if an instance were knocked out B = RTTknockout/RTT... Graph for LINX; 90% of clients wouldn't see an impact if it went away; 10% would see a worsening. geographic distribution pretty wide AMS-IX about 20% would suffer performance degregation; busiest two nodes, see a lot of clients, important to k deployment. If they plot it for both LINX and AMSIX together, about 65% wouldn't be affected, most of others would see 4x, 10% would be 7x worse. So taken together, the *two* nodes are important. Tokyo; best node for few clients; but those served, BADLY served by others; about 10% who would go more than 7x if it went way, those clients mostly Asia. Miami node at NOTA, moderate benefit for some clients, US and southAm would be badly served by europe or Tokyo. Delhi node is mostly ineffective, most would be served better by other nodes. Condense the graph into one number to get a value for effectiveness of each node. weighted average of B for each client. if benefit value is 1, node doesn't provide any benefit at all. larger numbers show higher benefits. Europe, when taken together, high benefit, as is Tokyo; Miami node not so effective, and Delhi is nearly ineffective. Does anycast provide any value then? knock out all except LINX; dark red curve (pre 1997) 10% wouldn't notice, 85% would get worse, benefit value is 18.8, so anycast does bring value. Stability the more routes competing in BGP with more nodes doesn't matter for single packet UDP exchanges does matter for TCP Look at node switches that occur. collect packet dumps on each node. extract all 53/UDP traffic k nodes only NTP synchronized if IP shows up on two nodes, log a switch. 5 nodes, april 2006, 0.06% saw switches 2830 switchers out of 845,328, 0.33% switchers no big issue with instance switchers. Routing issues k-root structure 5 global nodes (prepended) linkx, amsix, tokyo, mia, del different prepending values no-export causing reachability TT103 has value of 200, the graph axis is cut. tt103 is in Yokohama; Tokyo is 2ms away; but the query goes to Delhi through Tokyo to LA. 416ms vs 2, so value is 208. Thanks to Matsuzaki and Randy Bush, got BGP paths from AS2497 bad interaction of different prepending lengths need to fix prepending on Tokyo node. Delhi had shorter prepending. no-export and leaks local nodes can be worse than global nodes tt89, seeing Denic local node, 30ms instead of going to London. Local node, if no-export is ignored, announced to customer, they are more specific, leak to customers. no-export can lead to loss of reachability http://www.merit.edu/mail.archives/nanog/2005-10/msg01226.html problematic interaction of no-export with anycast use no-export to prevent local nodes from leaking if have an AS whose providers all peer with a local node and honor no-export customer never sees route for k IP address. solution, send out a less specific, covering prefix. Q: Mark Kosters, Verisign--saw much higher switching rates; can he define switching better? A: if an IP is seen at one location, then shifts to a different site, that's one switch; going back to the first node would be a second switch.

1 0

earthlink.net mail admin contact?
by Mark Jeftovic 09 Jun '06

09 Jun '06

Would somebody from earthlink.net mail ops please contact me off-list? thx -mark -- Mark Jeftovic <markjr(a)easydns.com> Founder & President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892

1 0

who runs http://www.networkthinktank.com/ ?
by Paul Vixie 09 Jun '06

09 Jun '06

the web site and whois info are just about as completely anonymous as can be.

4 3

Weekly Routing Table Report
by Routing Analysis Role Account 09 Jun '06

09 Jun '06

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 10 Jun, 2006 Analysis Summary ---------------- BGP routing table entries examined: 190168 Prefixes after maximum aggregation: 104652 Unique aggregates announced to Internet: 93198 Total ASes present in the Internet Routing Table: 22396 Origin-only ASes present in the Internet Routing Table: 19479 Origin ASes announcing only one prefix: 9338 Transit ASes present in the Internet Routing Table: 2917 Transit-only ASes present in the Internet Routing Table: 60 Average AS path length visible in the Internet Routing Table: 3.5 Max AS path length visible: 24 Max AS path prepend of ASN (34527) 16 Prefixes from unregistered ASNs in the Routing Table: 7 Unregistered ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1543668456 Equivalent to 92 /8s, 2 /16s and 130 /24s Percentage of available address space announced: 41.6 Percentage of allocated address space announced: 60.2 Percentage of available address space allocated: 69.1 Total number of prefixes smaller than registry allocations: 94114 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 40710 Total APNIC prefixes after maximum aggregation: 16880 Prefixes being announced from the APNIC address blocks: 38424 Unique aggregates announced from the APNIC address blocks: 18579 APNIC Region origin ASes present in the Internet Routing Table: 2598 APNIC Region origin ASes announcing only one prefix: 747 APNIC Region transit ASes present in the Internet Routing Table: 398 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 227781728 Equivalent to 13 /8s, 147 /16s and 172 /24s Percentage of available APNIC address space announced: 71.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 97710 Total ARIN prefixes after maximum aggregation: 57771 Prefixes being announced from the ARIN address blocks: 71728 Unique aggregates announced from the ARIN address blocks: 26653 ARIN Region origin ASes present in the Internet Routing Table: 10759 ARIN Region origin ASes announcing only one prefix: 4051 ARIN Region transit ASes present in the Internet Routing Table: 993 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 293558272 Equivalent to 17 /8s, 127 /16s and 88 /24s Percentage of available ARIN address space announced: 76.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks 24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 38053 Total RIPE prefixes after maximum aggregation: 25405 Prefixes being announced from the RIPE address blocks: 35075 Unique aggregates announced from the RIPE address blocks: 23703 RIPE Region origin ASes present in the Internet Routing Table: 8129 RIPE Region origin ASes announcing only one prefix: 4266 RIPE Region transit ASes present in the Internet Routing Table: 1342 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 252474756 Equivalent to 15 /8s, 12 /16s and 117 /24s Percentage of available RIPE address space announced: 79.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-41983 RIPE Address Blocks 62/8, 80/5, 88/6, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 11498 Total LACNIC prefixes after maximum aggregation: 3701 Prefixes being announced from the LACNIC address blocks: 9595 Unique aggregates announced from the LACNIC address blocks: 5546 LACNIC Region origin ASes present in the Internet Routing Table: 695 LACNIC Region origin ASes announcing only one prefix: 229 LACNIC Region transit ASes present in the Internet Routing Table: 133 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 27317760 Equivalent to 1 /8s, 160 /16s and 214 /24s Percentage of available LACNIC address space announced: 40.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 189/8, 190/8, 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 2190 Total AfriNIC prefixes after maximum aggregation: 895 Prefixes being announced from the AfriNIC address blocks: 1501 Unique aggregates announced from the AfriNIC address blocks: 961 AfriNIC Region origin ASes present in the Internet Routing Table: 155 AfriNIC Region origin ASes announcing only one prefix: 45 AfriNIC Region transit ASes present in the Internet Routing Table: 25 Average AfriNIC Region AS path length visible: 3.5 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 4113152 Equivalent to 0 /8s, 62 /16s and 195 /24s Percentage of available AfriNIC address space announced: 12.3 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 1242 7204 228 CHINANET-BACKBONE 4755 931 259 74 Videsh Sanchar Nigam Ltd. Aut 9583 903 109 16 Sify Limited 4766 690 4435 304 Korea Telecom (KIX) 1221 613 1668 471 Telstra Pty Ltd 9498 571 211 67 BHARTI BT INTERNET LTD. 7545 544 124 70 TPG Internet Pty Ltd 17488 519 32 10 Hathway IP Over Cable Interne 17676 486 7029 110 Softbank BB Corp. 9443 450 110 81 Primus Telecommunications 18101 414 85 24 Reliance Infocom Ltd Internet 17557 397 31 178 Pakistan Telecom 4802 378 80 167 Wantree Development 17849 359 22 114 Telecommunications Technology 17974 347 129 14 PT TELEKOMUNIKASI INDONESIA 2907 336 1733 312 SINET Japan 9929 326 222 58 China Netcom Corp. 7474 298 211 228 SingTel Optus Pty Ltd 9800 275 410 67 CHINA UNICOM 4837 266 2994 112 chinanet IDC center beijing n ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1480 6151 945 AT&T WorldNet Services 4323 1310 740 259 Time Warner Telecom 721 1014 21998 313 DLA Systems Automation Center 6197 1005 625 471 BellSouth Network Solutions, 174 969 5787 904 Cogent Communications 19029 945 151 108 New Edge Networks 18566 943 272 8 Covad Communications 701 940 6753 776 UUNET Technologies, Inc. 2386 894 557 687 AT&T Data Communications Serv 1239 846 2789 600 Sprint 20115 713 617 381 Charter Communications 209 707 3687 551 Qwest 19262 667 2103 183 Verizon Global Networks 22773 664 1741 40 Cox Communications, Inc. 7011 638 218 415 Citizens Utilities 11492 622 87 22 Cable One 852 584 1084 382 Telus Advanced Communications 19916 563 49 54 OLM LLC 855 550 244 64 Canadian Research Network 5668 529 147 23 CenturyTel Internet Holdings, RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 573 1951 451 UUNET - Commercial IP service 3301 305 1327 292 TeliaNet Sweden 3352 305 1644 30 Ibernet, Internet Access Netw 3320 287 3989 240 Deutsche Telekom AG 8220 274 470 262 COLT Telecommunications 680 245 2025 242 DFN-IP service G-WiN 6746 238 90 212 Dynamic Network Technologies, 3246 236 504 226 Song Networks 8708 216 275 201 Romania Data Systems S.A. 24863 214 42 11 LINKdotNET AS number 3269 201 2182 72 TELECOM ITALIA 3215 200 1680 93 France Telecom Transpac 8551 200 198 24 Bezeq International 30890 193 17 71 SC Kappa Invexim SRL 1257 190 740 166 SWIPnet Swedish IP Network 8866 180 37 15 Bulgarian Telecommunication C 6830 172 781 36 UPC Distribution Services 786 171 1778 171 The JANET IP Service 5400 171 348 140 BT Ignite European Backbone 9121 169 931 28 TTnet Autonomous System LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 705 1082 224 UniNet S.A. de C.V. 22047 419 158 11 VTR PUNTO NET S.A. 11172 352 110 84 Servicios Alestra S.A de C.V 16814 329 20 8 NSS, S.A. 6147 267 134 22 Telefonica Del Peru 14117 201 12 6 Telefonica del Sur S.A. 10481 181 72 8 Prima S.A. 7303 175 81 25 Telecom Argentina Stet-France 6503 136 151 82 AVANTEL, S.A. 21826 133 17 23 INTERCABLE 11556 132 80 4 Cable-Wireless Panama 19169 126 8 26 Telconet 14259 119 10 15 GTD Internet S.A. 14522 115 18 9 SatNet S.A. 23216 114 21 9 RAMtelecom Telecomunicaciones 19429 110 60 44 E.T.B. 6505 109 88 79 Global One Communicaoes Ltda 7910 105 7 10 ANDINET ON LINE 5639 103 12 9 Telecommunications Services o 18822 98 7 9 TELEFONICA MANQUEHUE AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 286 803 234 The Internet Solution 8452 166 60 7 TEDATA 6713 147 135 11 Itissalat Al-MAGHRIB 2018 131 314 105 Tertiary Education Network 5536 121 8 18 Internet Egypt Network 24835 116 48 6 RAYA Telecom - Egypt 33783 104 6 2 EEPAD TISP TELECOM & INTERNET 2905 73 155 66 The Internetworking Company o 15475 61 84 4 Nile Online 20928 59 16 2 Noor Advanced Technologies AS 15706 44 8 3 Sudatel Internet Exchange Aut 5713 39 294 35 Telkom SA Ltd 33774 31 7 21 AS Number for Telecom Algeria 12455 26 6 3 Jambonet Autonomous system 23889 26 8 11 MAURITIUS TELECOM 16637 25 18 23 Johnnic e-Ventures 8524 22 1 5 AUCEGYPT Autonomous System 10798 22 1 13 Standard Bank of South Africa 21280 21 4 4 Swift Global Kenya Ltd.Is an 33766 21 2 1 Nyala Communications Pty Ltd Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 1310 1051 Time Warner Telecom 4134 1242 1014 CHINANET-BACKBONE 18566 943 935 Covad Communications 9583 903 887 Sify Limited 4755 931 857 Videsh Sanchar Nigam Ltd. Aut 19029 945 837 New Edge Networks 721 1014 701 DLA Systems Automation Center 22773 664 624 Cox Communications, Inc. 11492 622 600 Cable One 6197 1005 534 BellSouth Network Solutions, 19916 563 509 OLM LLC 17488 519 509 Hathway IP Over Cable Interne 5668 529 506 CenturyTel Internet Holdings, 9498 571 504 BHARTI BT INTERNET LTD. 855 550 486 Canadian Research Network 19262 667 484 Verizon Global Networks 8151 705 481 UniNet S.A. de C.V. 7545 544 474 TPG Internet Pty Ltd 3602 525 421 Sprint Canada, Inc. 22047 419 408 VTR PUNTO NET S.A. List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65128 PRIVATE 193.110.50.0/24 24652 Juniper Networks, Eu 24409 UNALLOCATED 203.119.29.0/24 9808 Guangdong Mobile Com 64515 PRIVATE 203.126.13.0/25 7610 SINGAPORE ADVANCE RE 64515 PRIVATE 203.126.13.128/26 7610 SINGAPORE ADVANCE RE 65280 PRIVATE 203.197.161.0/24 4755 Videsh Sanchar Nigam 65280 PRIVATE 203.200.14.0/24 4755 Videsh Sanchar Nigam 65280 PRIVATE 203.200.21.0/24 4755 Videsh Sanchar Nigam Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 183.206.196.0/24 2188 FR-RENATER-ASTER 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.84.205.0/24 719 LANLINK autonomous system 192.172.0.0/19 721 DLA Systems Automation Center Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:9 /11:28 /12:92 /13:200 /14:360 /15:704 /16:8855 /17:3247 /18:5351 /19:11723 /20:13263 /21:11524 /22:14724 /23:15902 /24:103048 /25:387 /26:314 /27:182 /28:69 /29:67 /30:51 /31:0 /32:41 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 926 943 Covad Communications 19029 876 945 New Edge Networks 6197 790 1005 BellSouth Network Solutions, 7018 780 1480 AT&T WorldNet Services 9583 733 903 Sify Limited 4323 641 1310 Time Warner Telecom 2386 613 894 AT&T Data Communications Serv 11492 613 622 Cable One 19916 557 563 OLM LLC 7011 547 638 Citizens Utilities 4766 500 690 Korea Telecom (KIX) 855 424 550 Canadian Research Network 5668 412 529 CenturyTel Internet Holdings, 15270 403 434 PaeTec.net -a division of Pae 1239 390 846 Sprint 4755 365 931 Videsh Sanchar Nigam Ltd. Aut 6517 364 395 Yipes Communications, Inc. 17849 359 359 Telecommunications Technology 702 356 573 UUNET - Commercial IP service 6198 354 508 BellSouth Network Solutions, Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:42 11:1 12:1618 13:1 15:15 16:3 17:3 18:4 20:41 24:734 25:1 32:57 38:229 40:54 41:3 44:3 47:6 52:4 55:1 56:3 57:25 58:183 59:217 60:182 61:863 62:775 63:1911 64:3173 65:2181 66:3061 67:613 68:663 69:1531 70:376 71:80 72:756 74:40 80:788 81:647 82:594 83:401 84:387 85:543 86:390 87:358 88:96 89:240 124:295 125:494 128:158 129:190 130:78 131:318 132:33 133:8 134:157 135:48 136:178 137:82 138:206 139:62 140:469 141:130 142:379 143:165 144:223 145:40 146:329 147:136 148:318 149:188 150:112 151:94 152:69 153:107 154:5 155:202 156:98 157:146 158:168 159:173 160:89 161:76 162:245 163:150 164:179 165:208 166:168 167:246 168:491 169:128 170:338 171:14 183:1 190:75 192:5744 193:3368 194:2640 195:1909 196:855 198:3910 199:3214 200:4487 201:978 202:6698 203:7034 204:3901 205:2033 206:2421 207:2901 208:2128 209:3776 210:1973 211:683 212:1259 213:1469 214:364 215:40 216:4177 217:1156 218:291 219:232 220:717 221:360 222:158 End of report

1 0