Re: Cyclops Down?
Hi all, We're having an issue with an UPS here at UCLA where one of the Cyclops servers is connected to. It should be fixed very soon, will keep you posted.. Thanks, --Ricardo On Dec 15, 2009, at 8:00 AM, sjk wrote: Is anyone else seeing cyclops down -- or is it just me? mtr -c10 -r 131.179.96.253 4. osh-2828-peer.onshore.net 0.0%101.3 1.3 1.2 1.6 0.1 5. ip65-47-181-105.z181-47-65.c 0.0%101.4 2.0 1.3 3.7 0.8 6. ge11-1-4d0.mcr2.chicago-il.u 0.0%102.1 1.7 1.4 2.1 0.3 7. ae1d0.mcr1.chicago-il.us.xo. 0.0%102.7 11.8 1.8 34.9 13.4 8. 216.156.0.161.ptr.us.xo.net 0.0%10 62.2 62.3 62.0 62.8 0.3 9. te-3-2-0.rar3.dallas-tx.us.x 0.0%10 61.1 61.8 61.0 64.2 1.0 10. 207.88.12.46.ptr.us.xo.net0.0%10 61.6 61.6 60.7 63.8 1.1 11. 207.88.12.158.ptr.us.xo.net 0.0%10 60.7 61.0 60.7 61.7 0.4 12. lax-px1--xo-ge.cenic.net 0.0%10 60.5 60.8 60.4 61.4 0.4 13. dc-lax-core1--lax-peer1-ge.c 0.0%10 61.5 61.5 61.1 62.1 0.4 14. dc-lax-agg1--lax-core1-ge.ce 0.0%10 61.1 61.6 60.8 63.5 0.9 15. dc-ucla--lax-agg1-ge-2.cenic 0.0%10 62.0 62.6 61.7 65.1 1.3 16. border-2--core-1-ge.backbone 0.0%10 62.4 62.4 61.8 63.4 0.5 17. core-1--mathsci-10ge.backbon 0.0%10 61.9 61.7 61.4 62.1 0.2 18. ??? 100.0100.0 0.0 0.0 0.0 0.0
Re: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd
It seems Team Cymru needs to update its whois db to use 4-byte ASNs and remove AS_TRANS (23456) --Ricardo On Oct 12, 2009, at 11:41 PM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm a bit confused (nothing really new here) with this BGP announcement, but following up on some cyber crime activity I stumbled on this: [Querying v4.whois.cymru.com] [v4.whois.cymru.com] AS | IP | AS Name 23456 | 91.213.29.250| -Reserved AS- Is this legitimate? route-views2.routeviews.org sho ip bgp 91.213.29.250 BGP routing table entry for 91.213.29.0/24 Paths: (42 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 6939 9002 40965 196804 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external Last update: Mon Oct 12 17:18:08 2009 13030 9002 40965 196804 213.144.128.203 from 213.144.128.203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:1 13030:1016 Last update: Mon Oct 12 13:10:14 2009 14608 4323 9002 40965 196804 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external Community: no-export Last update: Mon Oct 12 08:06:19 2009 286 9002 40965 196804 134.222.87.3 from 134.222.87.3 (134.222.85.108) Origin IGP, metric 0, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:50 2009 1299 3549 9002 40965 196804 213.248.83.252 from 213.248.83.252 (213.248.83.252) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:43:18 2009 3303 9002 40965 196804 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 1120:2 3303:1004 3303:1006 3303:3056 Last update: Thu Oct 8 15:06:42 2009 2905 702 9002 40965 196804 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external Last update: Thu Oct 8 15:42:42 2009 31500 3267 9002 40965 196804 95.140.80.254 from 95.140.80.254 (1.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Last update: Tue Oct 13 00:33:35 2009 1221 4637 3549 9002 40965 196804 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:32 2009 5056 1239 3549 9002 40965 196804 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:10:31 2009 7660 2516 3549 9002 40965 196804 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 Last update: Thu Oct 8 14:44:01 2009 6762 3549 9002 40965 196804 195.22.216.188 from 195.22.216.188 (195.22.216.188) Origin IGP, metric 100, localpref 100, valid, external Community: 6762:31 Last update: Thu Oct 8 14:43:28 2009 16150 9002 40965 196804 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 Last update: Thu Oct 8 14:43:26 2009 6453 3549 9002 40965 196804 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:25 2009 2152 11164 9002 40965 196804 137.164.16.12 from 137.164.16.12 (137.164.16.196) Origin IGP, localpref 100, valid, external Community: 2152:65299 2152:65506 11164:1130 11164:7880 Last update: Sat Oct 10 13:52:50 2009 6453 3549 9002 40965 196804 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:22 2009 3277 3267 9002 40965 196804 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 Last update: Thu Oct 8 14:43:51 2009 852 3561 9002 40965 196804 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Thu Oct 8 14:43:21 2009 3356 9002 40965 40965 196804 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 Last update: Tue Oct 13 06:09:59 2009 701 3549 9002 40965 196804 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:48 2009 8492 9002 40965 196804 85.114.0.217 from 85.114.0.217 (85.114.0.2) Origin IGP, localpref 100, valid, external Community: 8492:1101 9002:0 9002:64677 Last update: Thu Oct 8 14:43:16 2009 5413 9002 40965 196804 62.72.136.2 from
Re: Use of Default in the DFZ: banned in philly, see it now on the net!
Hi, The classification we have is one possible classification, it's hard (if not impossible) to capture the diversity of the network in 4 classes without having mislabels. We noticed that there were a considerable number of networks with special arrangements (i.e. a very small number of local downstreams mostly non-profit), specially in academic campus networks. Because these networks are not ISPs in the traditional sense (not their main business), we relaxed the stub threshold at the cost of including some other cases of networks that are actual ISPs (e.g. Jack Bates). Looking forward to see Randy's survey results to see how often this happened. Thanks, --Ricardo On Jun 24, 2009, at 12:26 PM, Pete Templin wrote: Lixia Zhang wrote: On Jun 24, 2009, at 11:04 AM, Pete Templin wrote: In (your) theory, your paper may hold up. In practice, your definition of stub network is most likely considered wrong, and that likely shifts a lot of the assumptions in your paper. But I also believe that there are a few common practical patterns that cover majority of reality. We need to be mindful of diversity in real world but also capture basic common patterns (I'd agree that the paper perhaps should have said a few more words about the former). Skimming the paper turns up a key sentence, Stub networks, on the other hand, do not forward packets for other networks. What part of that led you to think that stub networks forward packets for 1-4 downstream ASNs? pt
Re: how many BGP routers, how many ASes
you might want to have a look at: http://irl.cs.ucla.edu/topology --Ricardo On May 13, 2009, at 8:53 AM, Irfan Zakiuddin wrote: Hi all, I have scouted around for this information, but not get very far. I'm hoping someone will have answers at hand. What I want to know is roughly how many : 1. ASes there are in the world today? 2. BGP routers there are, for intra-domain as well as inter-domain routing, in total in the world? 3. BGP routers do the largest ASes have? Really interesting would then be to say either how fast the above numbers are growing, or to give estimates for what the answers to 1-3 will be in 5 years time. An Internet source that provides the above information would be most useful - though I can't seem to find it with google. I'd be grateful for answer to be sent to me directly, whether you also post to NANOG is up to you. thanks in advance. irfan
Re: Anomalies with AS13214 ?
Hi all, First, thanks for using Cyclops, and thanks for all the Cyclops users that drop me a message about this. It seems some router in AS13214 decided to originate all the prefixes and send them to AS48285 in the Caymans, all the ASPATHs are 48285 13214. The first announcement was on 2009-05-11 11:03:11 UTC and last on 2009-05-11 12:16:32 UTC, there were 266,289 prefixes leaked (they were withdrawn afterwards) As indicated in the Cyclops alerts, only a single monitor(AS48285) in route-views4 detected this leak. I checked on other neighbors of AS13214 and they seem fine, so it seems it was only a single router issue. This incident shows the advantage of having a wide set of peers for detection, it seems Cyclops was the only tool to detect this incident. Given the amount of banks and financial institutions in the Caymans, i would otherwise have raised a red flag, but it seems this case was an unintentional misconfig by AS13214. Would appreciate any further comment on the tool, and happy cyclopying! --Ricardo the Cyclops guy http://cyclops.cs.ucla.edu On May 11, 2009, at 8:30 AM, Jay Hennigan wrote: We're getting cyclops[1] alerts that AS13214 is advertising itself as origin for all of our prefixes. Their anomaly report shows thousands of prefixes originating there. Anyone else seeing evidence of this or being affected? [1] http://cyclops.cs.ucla.edu/ -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Can you see these AS links:)
And you might want to have a look at: http://www.cs.ucla.edu/~rveloso/papers/completeness.pdf http://www.cs.ucla.edu/~rveloso/papers/completeness_tr.pdf --Ricardo On Mar 31, 2009, at 7:56 PM, Kai Chen wrote: Hello folks, As part of a research project here at Northwestern, we have found quite a few unexpected AS-level links that do not appear in public available BGP tables. We really need your help in validating them; for anyone who knows links associated with any AS, if you can assist us with this please contact us off list. Thanks! - Kai
Cyclops: an open eye to your network (beta release)
Hi, Just to let you know about Cyclops (beta for now), a tool for topology visibility and real-time routing anomaly detection/alerting for service providers and enterprise networks. Cyclops uses real time data from hundreds of vantage points of route-views, ripe-ris, packet clearing house and Univ. of Colorado bgpmon to assess how the rest of the world is reaching your network. Cyclops features include: - real-time alerting of prefix hijacks and misconfigured announcements - alerting of next-hop changes, AS in the middle (transit) and new prefix - alerting of new AS neighbor (false link announcement/leakages) - Global visibility on AS connectivity and prefix origins - Monitoring of routes to critical infrastructure, e.g. DNS TLDs - Anomaly listings (anomalous depeerings, bogus ASNs, bogon prefixes, long/short prefixes) To register for Cyclops please visit: http://cyclops.cs.ucla.edu/?l=reg To start configuring your network go to: http://cyclops.cs.ucla.edu/?v=matab=1 (need to be logged in) You need to tell cyclops what are your prefixes, your ASNes and your neighbor ASNs. Please do not hesitate to contact me in case you have questions/ comments/bug reports. Thanks for being a Cycloper! --Ricardo In name of the Cyclops Team
Road Runner DNS servers
Is there anyone clueful in this list from Road Runner(Time Warner Cable) that can explain what's going on with their DNS servers - just contacted their tech support and heard their DNS servers have been under attack over the last 3 days.. thanks, --Ricardo
Re: Global Blackhole Service
Nuno et all, Count me in for this.. Cheers, --Ricardo http://www.cs.ucla.edu/~rveloso On Feb 13, 2009, at 8:41 AM, Nuno Vieira - nfsi telecom wrote: Ok, however, what i am talking about is a competelly diferent thing, and i think that my thoughts are alligned with Jens. We want to have a Sink-BGP-BL, based on Destination. Imagine, i as an ISP, host a particular server that is getting nn Gbps of DDoS attack. I null route it, and start advertising a /32 to my upstream providers with a community attached, for them to null route it at their network. However, the attacks continue going, on and on, often flooding internet exchange connections and so. A solution like this, widelly used, would prevent packets to leave their home network, mitigating with effective any kind of DDoS (or packet flooding). Obviously, we need a few people to build this (A Website, an organization), where when a new ISP connects is added to the system, a prefix list should be implemented, preventing that ISP to announce IP addresses that DON'T belong to him. The Sink-BGP-BL sends a full feed of what it gots to Member ISP's, and those member ISP's, should apply route-maps or whatever they want, but, in the end they want to discard the traffic to those prefixes (ex: Null0 or /dev/null). This is a matter or getting enough people to kick this off, to build a website, to establish one or two route-servers and to give use to. Once again, i am interested on this, if others are aswell, let know. This should be a community-driven project. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vie...@nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ - Valdis Kletnieks valdis.kletni...@vt.edu wrote: How do you vet proposed new entries to make sure that some miscreant doesn't DoS a legitimate site by claiming it is in need of black-holing? Note that it's a different problem space than a bogon BGP feed or a spam-source BGP feed - if the Cymru guys take another 6 hours to do a proper paperwork and background check to verify a bogon, or if Paul and company take another day to verify something really *is* a cesspit of spam sources, it doesn't break the basic concept or usability of the feed. You usually don't *have* a similar luxury if you're trying to deal with a DDoS, because those are essentially a real-time issue. Oh, and cleaning up an entry in a timely fashion is also important, otherwise an attacker can launch a DDoS, get the target into the feed, and walk away...
Re: question on BGP aggregation
the ASes in the AS_SET resulted from merging 2 or more AS_PATHS, you
only know at least one of them is connected to AS3 ...
more details at rfc4271:
http://www.ietf.org/rfc/rfc4271.txt
An AS_SET implies that the destinations listed in the NLRI can
be reached through paths that traverse at least some of the
constituent autonomous systems. AS_SETs provide sufficient
information to avoid routing information looping; however,
their use may prune potentially feasible paths because such
paths are no longer listed individually in the form of
AS_SEQUENCEs. In practice, this is not likely to be a problem
because once an IP packet arrives at the edge of a group of
autonomous systems, the BGP speaker is likely to have more
detailed path information and can distinguish individual paths
from destinations.
--Ricardo
On Oct 22, 2008, at 8:17 PM, Kai Chen wrote:
Hi,
I observe some BGP AS paths collected from Routeview having the AS-set
in the last hop. According to my understanding, this is BGP route
aggregation. However, my question is as follows:
Suppose, there is a path AS1 AS2 AS3 {AS4 AS5 AS6}, how AS4 AS5 AS6
connect to AS3?
Does it necessarily mean that AS4 AS5 AS6 are direct neighbors of AS4,
and AS4 aggregate the routes from AS4 AS5 AS6 then exporting outside.
or, it could be other cases such as AS4 aggregate AS5 AS6 first, and
then AS3 aggregate AS4?
Thanks in advance,
Re: why not AS number based prefixes aggregation
Topological aggregation based on ASN is often too course granularity, see this paper: http://www.cs.ucla.edu/~rveloso/papers/giro.pdf specifically Fig4 is a good example, and sec 4C. Cheers, --Ricardo On Sep 8, 2008, at 6:20 AM, yangyang. wang wrote: Hi, everyone: For routing scalability issues, I have a question: why not deploy AS number based routing scheme? BGP is path vector protocol and the shortest paths are calculated based on traversed AS numbers. The prefixes in the same AS almost have the same AS_PATH associated, and aggregating prefixes according to AS will shrink BGP routing table significantly. I don't know what comments the ISPs make on this kind of routing scheme. -yang
Re: BGP Scalability Simulation
Moazzam, Do you have something specific in mind you want to measure? e.g. convergence times, table size, update count, etc? the scope of your study seems to broad as you describe it.. Cheers, --Ricardo On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: Thanks Stefan for your reply. Basically the goal of this testing is to study the BGP scalability issues in the internet sometime in future lets say 10 years from now and try to find out what problems it could face . I am trying to use ns2 as my simulation environment. Can you suggest how I can set up the envrionment for this kind of study and what parameters should I try to caputre. Regards MAK On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan [EMAIL PROTECTED]wrote: Topology and setup of these kinds of tests largely depend on whether you are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight forward as you are almost always testing reconvergence of the BGP next-hop. iBGP testing scenarios on the other hand can be quite a bit more complex as you may also be testing the reconvergence of the underlying IGP if the BGP next-hop remains unchanged. Can you describe your testing goals and environment in a bit more detail? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D - Original Message - From: Moazzam Khan [EMAIL PROTECTED] To: nanog@nanog.org nanog@nanog.org Sent: Mon Sep 01 15:37:19 2008 Subject: BGP Scalability Simulation Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK
Re: BGP Scalability Simulation
The topos you mentioned are synthetic (e.g. generated based on math), you might want to check these ones instead, based on bgp tables from public sources: http://irl.cs.ucla.edu/topology/ Also, i don't think using a full internet topology is the way to go to do measure convergence time. The reason is that convergence time is highly dependent on ibgp architecture, router timers, etc and modeling things as one router per AS is at most unrealistic for this purpose. I would suggest to look at a small yet realistic topology of a few ISPs, e.g. as given by rocket fuel: http://www.cs.washington.edu/research/networking/rocketfuel/ For routing table size, you just need to grab the existing available routing tables, e.g. http://www.routeviews.org/ and do an extrapolation of the number of prefixes in RIB n years from now --Ricardo On Sep 2, 2008, at 10:43 AM, Moazzam Khan wrote: Hi Ricardo, Basically I want to measure the Convergence times and routing table sizes. But I am not able to find a good topology of internet which I can utilize for my experimentations. I am looking at GT-ITM, BRITE and IGen but don't know what kind of abstraction they provide and if these topologies are feasible to test the above mentioned parameters. What challenges I can face if I want to measure all those parameters convergence times ,table sizes , update count, signal sizes etc. Regards Moazzam On Tue, Sep 2, 2008 at 1:35 PM, Ricardo Oliveira [EMAIL PROTECTED] wrote: Moazzam, Do you have something specific in mind you want to measure? e.g. convergence times, table size, update count, etc? the scope of your study seems to broad as you describe it.. Cheers, --Ricardo On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: Thanks Stefan for your reply. Basically the goal of this testing is to study the BGP scalability issues in the internet sometime in future lets say 10 years from now and try to find out what problems it could face . I am trying to use ns2 as my simulation environment. Can you suggest how I can set up the envrionment for this kind of study and what parameters should I try to caputre. Regards MAK On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan [EMAIL PROTECTED]wrote: Topology and setup of these kinds of tests largely depend on whether you are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight forward as you are almost always testing reconvergence of the BGP next-hop. iBGP testing scenarios on the other hand can be quite a bit more complex as you may also be testing the reconvergence of the underlying IGP if the BGP next-hop remains unchanged. Can you describe your testing goals and environment in a bit more detail? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D - Original Message - From: Moazzam Khan [EMAIL PROTECTED] To: nanog@nanog.org nanog@nanog.org Sent: Mon Sep 01 15:37:19 2008 Subject: BGP Scalability Simulation Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK
