Re: Mechanisms for a multi-homed host to pick the best router
When the server sends TCP traffic for that same connection back to host A, it needs to pick one of the N routers, in other words, it needs to pick an outbound interface from its N interfaces. ... The problem is that some routers are better than other routers in the sense that they are closer to the final destination address A. (For example, each router could be connected to a different ISP.) One way for the server to pick the optimal downstream router, is to run stub BGP between the server and each of the routers. ... While this approach would certainly allow the server to pick the optimal downstream router in all cases, I would prefer not to run routing protocols on this server for a number of reasons: It's probably good to keep in mind that this would be optimal, not optimal. As far as I know the best you would get is to minimize the number of AS hops, which is probably correlated with, but definitely not the same as, metrics you actually care about like latency. All in all, running BGP does seem like an awful lot of work just to let you optimize for the wrong metric. Here's another thought, though. You don't need to run BGP to get the data that BGP will give you. There exist approximate maps of the Internet at the router or AS level with IP prefixes attached. It would be possible to periodically obtain one of these graphs, e.g. from CAIDA, and then run a shortest-paths algorithm on that graph to decide based on the destination IP address which router is best. Not only does this let you avoid running BGP, it also saves memory since you need only one copy of the graph, rather than one copy for each of the N BGP sessions. Of course, it's not real-time data, but if all you need is a good guess as to which of the outbound interfaces is best, it might be sufficient. Does anyone actually do something like this in practice? (I'm guessing no) Someone suggested an idea to me which seems almost to simple to work, but I cannot find any good reason why it would not work. The idea is the server simply sends all outbound traffic for the TCP connection out over the same interface over which the most recent TCP traffic for that connection was received. So the underlying idea here is that the source (or its ISP) has effectively done the work of picking a good path, and by replying on the same interface, you use the reverse of that path, which is also likely to be pretty good. Some of the assumptions in that reasoning seem imperfect: - There's a good chance the forward path (i.e. the one the source picked) isn't the best. - Asymmetry, as you noted: Even if the forward path was the best, the reverse of it is not necessarily the best. - A different asymmetry: Even if the forward was best and the reverse of it is best, the path followed by sending on the same interface is not necessarily the reverse of the forward path. So I understand that this heuristic could perform pretty well in practice, and certainly better than sending on a random interface (in terms of latency, not traffic engineering). But I can't see how it's the optimal strategy. I think there are commercial products that solve this problem the right way, by automatically and dynamically monitoring path quality and availability, and selecting paths for you. I think the Avaya Converged Network Analyzer is one. I recall speaking with an operator from a major content provider who said that they use an intelligent route selection product similar to this for their outbound traffic. I'd be personally interested to hear what other operators typically use. ~Brighten Godfrey
Anyone have experience with Alcatel 9500MXC?
Hi all. I have several of these units deployed, they are all running fine, but I am looking for information about them, specifically SNMP related. Our Alcatel contacts have given us a collection of MIBs, from which I cant really get anything useful out of the radios. Other than that they dont seem too hell bent on providing much further help on this subject. Hoping someone else on here might have experience with these units and can share some information about how to get useful information out of them via SNMP, like traffic and error counters, signal parameters, alarm status, etc. Cheers, Tom
Re: Anyone have experience with Alcatel 9500MXC?
Tom Storey wrote: Hi all. I have several of these units deployed, they are all running fine, but I am looking for information about them, specifically SNMP related. Our Alcatel contacts have given us a collection of MIBs, from which I cant really get anything useful out of the radios. Other than that they dont seem too hell bent on providing much further help on this subject. Hoping someone else on here might have experience with these units and can share some information about how to get useful information out of them via SNMP, like traffic and error counters, signal parameters, alarm status, etc. Excuse my ignorance (never touched such a device) but would doing an snmpwalk over the device not help? MIB's for traffic on interfaces should be fairly standard unless Alcatel smoked their socks.
Sprint/Cogent Peering Issue?
Hi, We are seeing traffic getting dropped between our Cogent and Sprint connect DC's. One of them is getting shutdown, so we just have a Cogent link there :| Anyone seeing anything similar? From: 91.102.40.18 traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte packets 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms 0.744 ms 0.740 ms 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 ms 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms 0.450 ms 0.483 ms 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 ms 0.934 ms 9 * From 208.91.188.138 traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte packets 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms 0.236 ms 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 ms 1.232 ms 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 ms 2.485 ms 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms 2.472 ms 2.485 ms 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 ms 2.735 ms 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms 50.720 ms 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 ms 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms 13 * * * Thanks, craig Craig Holland Rhythm NewMedia Sr. Director Operations Integration YIM: cholland
Re: Sprint/Cogent Peering Issue?
No apparent problems from Cogent in Northern Virginia : tme$ traceroute ops1.scc.rnmd.net traceroute to ops1.scc.rnmd.net (208.91.188.136), 64 hops max, 40 byte packets 1 dmz-mct2 (63.105.122.1) 0.754 ms 0.278 ms 0.485 ms 2 gi0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.741 ms 0.612 ms 0.753 ms 3 gi2-1.3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 14.444 ms 0.756 ms 0.728 ms 4 te3-1.ccr02.dca01.atlas.cogentco.com (154.54.3.158) 0.980 ms 1.067 ms 0.978 ms 5 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) 46.711 ms te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) 2.400 ms te7-3.mpd01.dca02.atlas.cogentco.com (154.54.6.26) 1.863 ms 6 vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 1.935 ms vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) 1.968 ms vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 1.618 ms 7 gi9-0-0.core01.iad01.atlas.cogentco.com (154.54.3.221) 1.578 ms gi14-0-0.core01.iad01.atlas.cogentco.com (154.54.5.57) 1.840 ms gi2-0-0.core01.iad01.atlas.cogentco.com (154.54.5.33) 1.788 ms 8 sprint.iad01.atlas.cogentco.com (154.54.13.62) 1.657 ms 1.693 ms 1.713 ms 9 sl-crs1-rly-0-4-5-0.sprintlink.net (144.232.20.154) 3.725 ms 3.597 ms 3.724 ms 10 sl-crs2-sj-0-5-0-0.sprintlink.net (144.232.20.186) 70.442 ms 70.780 ms 70.417 ms 11 sl-st1-sc-1-1.sprintlink.net (144.232.20.197) 70.672 ms 70.844 ms 70.973 ms 12 sl-rhyth2-158722-0.sprintlink.net (144.228.111.26) 71.197 ms 71.128 ms 70.935 ms 13 208.91.188.68 (208.91.188.68) 71.213 ms 71.381 ms 71.172 ms 14 ops1.scc.rnmd.net (208.91.188.136) 71.412 ms 71.497 ms 71.673 ms Regards Marshall On Sep 19, 2008, at 4:27 AM, Craig Holland wrote: Hi, We are seeing traffic getting dropped between our Cogent and Sprint connect DC's. One of them is getting shutdown, so we just have a Cogent link there :| Anyone seeing anything similar? From: 91.102.40.18 traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte packets 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms 0.744 ms 0.740 ms 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 ms 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms 0.450 ms 0.483 ms 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 ms 0.934 ms 9 * From 208.91.188.138 traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte packets 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms 0.236 ms 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 ms 1.232 ms 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 ms 2.485 ms 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms 2.472 ms 2.485 ms 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 ms 2.735 ms 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms 50.720 ms 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 ms 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms 13 * * * Thanks, craig Craig Holland Rhythm NewMedia Sr. Director Operations Integration YIM: cholland
Re: Sprint/Cogent Peering Issue?
I'm seeing issues with traceroutes dying at Sprint in London, too. From our site here in the UK (transit from NTL Telewest Business) I can't reach cisco.com (but I know cisco.com is up - I can reach it from elsewhere). Apparently customers of XS4ALL in the Netherlands are seeing similar behaviour. -roy 1 c1-cam-gi-0-0-100 (172.16.128.2) 0.839 ms 0.470 ms 0.405 ms 2 ntl-gw1-fa-0-0 (82.1.12.129) 1.975 ms 1.804 ms 1.517 ms 3 nrth-lam-1-multilink26.network.virginmedia.net (62.253.60.221) 11.926 ms 4.612 ms 3.921 ms 4 nrth-t3core-1a-so-700-0.network.virginmedia.net (213.106.255.25) 5.102 ms 11.540 ms 9.283 ms 5 nth-bb-a-so-210-0.network.virginmedia.net (212.43.162.237) 4.833 ms 7.680 ms 5.126 ms 6 gfd-bb-b-so-010-0.network.virginmedia.net (62.253.185.98) 9.787 ms 7.746 ms 8.956 ms 7 sl-gw11-lon-11-0.sprintlink.net (213.206.156.101) 15.766 ms 12.921 ms 9.373 ms 8 sl-bb21-lon-11-0.sprintlink.net (213.206.128.58) 19.495 ms 9.444 ms 10.447 ms 9 * * * 10 * * * 11 * * *
Re: Sprint/Cogent Peering Issue?
On Fri, Sep 19, 2008 at 06:02:37AM -0400, Marshall Eubanks wrote: No apparent problems from Cogent in Northern Virginia : Fine from Cogent in DC. Not so fine from Cogent in the Netherlands. traceroute to ops1.scc.rnmd.net (208.91.188.136), 64 hops max, 40 byte packets 1 38.105.91.2 (38.105.91.2) [AS174] 0 ms 0 ms 0 ms 2 gi0-1.na32.b001806-1.dca01.atlas.cogentco.com (38.104.30.101) [AS174] 1 ms 1 ms 2 ms 3 te9-3.3596.ccr02.dca01.atlas.cogentco.com (38.20.37.209) [AS174] 0 ms 0 ms 0 ms 4 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) [AS174] 1 ms te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) [AS174] 25 ms 94 ms 5 vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) [AS174] 1 ms te1-2.ccr02.iad01.atlas.cogentco.com (154.54.7.158) [AS174] 1 ms te2-2.ccr02.iad01.atlas.cogentco.com (154.54.7.162) [AS174] 1 ms 6 gi9-0-0.core01.iad01.atlas.cogentco.com (154.54.3.221) [AS174] 1 ms gi0-0-0.core01.iad01.atlas.cogentco.com (154.54.3.225) [AS174] 1 ms 1 ms 7 sprint.iad01.atlas.cogentco.com (154.54.13.62) [AS174] 1 ms 1 ms 1 ms 8 sl-crs2-rly-0-1-3-0.sprintlink.net (144.232.20.188) [AS1239] 3 ms 4 ms 3 ms 9 sl-crs2-sj-0-0-0-2.sprintlink.net (144.232.8.145) [AS1239] 70 ms 71 ms 70 ms 10 sl-st1-sc-1-1.sprintlink.net (144.232.20.197) [AS1239] 71 ms 71 ms 71 ms 11 sl-rhyth2-158722-0.sprintlink.net (144.228.111.26) [AS1239] 71 ms 71 ms 71 ms 12 208.91.188.68 (208.91.188.68) [NONE] 71 ms 71 ms 71 ms 13 ops1.scc.rnmd.net (208.91.188.136) [NONE] 71 ms 71 ms 71 ms traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 40 byte packets 1 lid-br1-g0-2-10.ops.theveniceproject.com (89.251.0.1) [AS42072] 0.428 ms 0.373 ms 0.368 ms 2 gi4-10.ccr01.ams05.atlas.cogentco.com (149.6.128.125) [AS174] 1.474 ms 1.415 ms 1.420 ms 3 te3-4.ccr01.ams03.atlas.cogentco.com (130.117.0.85) [AS174] 1.668 ms 1.734 ms 1.617 ms 4 gi2-0-0.core01.ams03.atlas.cogentco.com (130.117.0.33) [AS174] 1.573 ms 1.620 ms gi10-0-0.core01.ams03.atlas.cogentco.com (130.117.0.237) [AS174] 1.618 ms 5 sprint.ams03.atlas.cogentco.com (130.117.14.122) [AS174] 1.606 ms 1.617 ms 1.569 ms 6 sl-bb21-ams-15-0-0.sprintlink.net (217.149.32.34) [AS1239] 1.673 ms 1.721 ms 1.571 ms 7 sl-bb23-lon-4-0.sprintlink.net (213.206.129.143) [AS1239] 9.562 ms 9.500 ms 9.456 ms 8 sl-bb21-lon-13-0.sprintlink.net (213.206.128.55) [AS1239] 9.660 ms 9.628 ms 9.601 ms 9 * * * 10 * * * HTH Andrew On Sep 19, 2008, at 4:27 AM, Craig Holland wrote: Hi, We are seeing traffic getting dropped between our Cogent and Sprint connect DC's. One of them is getting shutdown, so we just have a Cogent link there :| Anyone seeing anything similar? From: 91.102.40.18 traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte packets 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms 0.744 ms 0.740 ms 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 ms 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms 0.450 ms 0.483 ms 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 ms 0.934 ms 9 * From 208.91.188.138 traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte packets 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms 0.236 ms 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 ms 1.232 ms 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 ms 2.485 ms 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms 2.472 ms 2.485 ms 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 ms 2.735 ms 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms 50.720 ms 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 ms 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms 13 * * * Thanks, craig
BGP Update Report
BGP Update Report Interval: 18-Aug-08 -to- 18-Sep-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9583 301731 3.8% 226.5 -- SIFY-AS-IN Sify Limited 2 - AS1803 126042 1.6% 94.9 -- ICMNET-5 - Sprint 3 - AS4538 107539 1.3% 21.4 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS569177600 1.0%5969.2 -- MITRE-AS-5 - The MITRE Corporation 5 - AS815176788 1.0% 31.8 -- Uninet S.A. de C.V. 6 - AS638967460 0.8% 15.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS905165154 0.8% 407.2 -- IDM Autonomous System 8 - AS209 51813 0.7% 10.8 -- ASN-QWEST - Qwest 9 - AS14593 50458 0.6% 50458.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS10396 46699 0.6% 667.1 -- COQUI-NET - DATACOM CARIBE, INC. 11 - AS17488 44961 0.6% 30.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS418443385 0.5% 21692.5 -- STORTEK-WHQ - Storage Technology Corporation 13 - AS886639604 0.5% 123.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS20115 38076 0.5% 21.4 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS18231 36058 0.5% 146.0 -- EXATT-AS-AP IOL NETCOM LTD 16 - AS701835690 0.5% 24.2 -- ATT-INTERNET4 - ATT WorldNet Services 17 - AS666335173 0.4% 286.0 -- EUROWEBRO Euroweb Romania SA 18 - AS919834983 0.4% 152.1 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 19 - AS475533910 0.4% 19.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS645831107 0.4% 70.2 -- Telgua TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS14593 50458 0.6% 50458.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS418443385 0.5% 21692.5 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS8266 9569 0.1%9569.0 -- NEXUSTEL Nexus Telecommunications 4 - AS299108235 0.1%8235.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS569177600 1.0%5969.2 -- MITRE-AS-5 - The MITRE Corporation 6 - AS381805727 0.1%5727.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 7 - AS432994606 0.1%4606.0 -- TELECONTACT-AS Telecontact Ltd. 8 - AS4557 7873 0.1%3936.5 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 9 - AS23082 18900 0.2%3780.0 -- MPHI - Michigan Public Health Institute 10 - AS11971 21651 0.3%3093.0 -- PFIZERNET-GROTON - PFIZER INC. 11 - AS30969 23119 0.3%2311.9 -- TAN-NET TransAfrica Networks 12 - AS239172160 0.0%2160.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 13 - AS244911774 0.0%1774.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 14 - AS441941590 0.0%1590.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 15 - AS320111577 0.0%1577.0 -- JOHO-NYC - Joho Capital, LLC 16 - AS974712268 0.1%1533.5 -- EZINTERNET-AS-AP EZInternet Pty Ltd 17 - AS253211249 0.0%1249.0 -- G4S-NET GROUP 4 SECURITAS Prague 18 - AS262765529 0.1%1105.8 -- TIMKEN-USA - The Timken Company 19 - AS398432156 0.0%1078.0 -- RATECOM-AS Joint Stock Company Ratecom 20 - AS3944 4275 0.1%1068.8 -- PARTAN-LAB - Partan Partan TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 77527 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 59162 0.7% AS9583 -- SIFY-AS-IN Sify Limited 3 - 194.126.143.0/24 57735 0.7% AS9051 -- IDM Autonomous System 4 - 210.214.151.0/24 55122 0.6% AS9583 -- SIFY-AS-IN Sify Limited 5 - 12.8.7.0/24 50458 0.6% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 6 - 210.210.112.0/24 44322 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 221.135.80.0/24 44047 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.251.0/24 42813 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 83.228.71.0/2430651 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - 221.128.192.0/18 27373 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 11 - 72.50.96.0/20 24360 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 12 - 199.117.144.0/22 21694 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 13 - 129.80.0.0/16 21691 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 14 - 12.18.36.0/24 21381 0.2% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 15 - 196.42.0.0/20 21180 0.2%
Re: Sprint/Cogent Peering Issue?
FWIW, the Sprint routing issues we were seeing seem to have been resolved now, AFAICS. -roy
RE: Level(3) Issues
Can you post a couple of IP's ? We're out of Level(3) Detroit node and don't see anything towards Disney.com etc Paul -Original Message- From: James Baldwin [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2008 8:01 AM To: nanog@nanog.org Subject: Level(3) Issues Is anyone else experiencing increased latency or packet loss through the Level3/Broadwing network? I have seen sporadic packet loss to several locations nationally over the last several hours. The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
RE: Level(3) Issues
No issues Tampa to San Fran. Robert D. Scott [EMAIL PROTECTED] Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -Original Message- From: Paul Stewart [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2008 9:17 AM To: James Baldwin; nanog@nanog.org Subject: RE: Level(3) Issues Can you post a couple of IP's ? We're out of Level(3) Detroit node and don't see anything towards Disney.com etc Paul -Original Message- From: James Baldwin [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2008 8:01 AM To: nanog@nanog.org Subject: Level(3) Issues Is anyone else experiencing increased latency or packet loss through the Level3/Broadwing network? I have seen sporadic packet loss to several locations nationally over the last several hours. The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
virbl.bit.nl, A list of virussending IP's
Hi All, Some of you might have heard about or suffered a listing on virbl.bit.nl. Virbl is a dns-list with IP's of which we (BIT) or one of the contributors [1] have received a email with a virus. We will list an IP after it has sent two virus-emails to one of our sources. We will remember that you sent those emails for seven days. IP's will only be listed as long as the last time we 'saw' the IP sending virusses is less than 24 hours and the total sent emails is greater than two, in the last seven days. The goal is to stop infected machines from sending virusses, and stop relaying-servers from forwarding, bouncing and otherwise deliver virusses. It does definitely help in preventing the use of useless cou cycles for scanning mail in your mailsetup. AS Administrators can login at [2]. A password will be emailed to a address you select. We look for addresses in the whois-info for your AS. You can see evidence, suspend hosts from the list and see stats about your AS. We are working on notifications, which will also be configurable in the login-interface. We currently use dnswl and the nlwhitelist (a list with the relay-servers for Dutch ISP's) as a exclude list. If anyone knows another trustworthy whitelist with relayservers from ISP's, please let me know so we can think about using that too. Also, if you're interested in contributing to Virbl, please email me off list. We prefer consumer ISP's, with some million messages per day. If you're using MailScanner or Amavisd-new, that would be great. Offcourse, the use of Virbl is free. See [3] on howto use it. Thanks, Links to http://virbl.bit.nl/ [1] http://virbl.bit.nl/contributors.php [2] https://virbl.bit.nl/login/ [3] http://virbl.bit.nl/usage.php -- Mark Schouten, Unix/NOC-engineer BIT BV | [EMAIL PROTECTED] | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF signature.asc Description: This is a digitally signed message part
Level3 must have changed a lot on East Coast...any info?
Does anyone have more info as to what Level3 changed last night during their maintenace window? Also I am going through either WashDC or Atlanta it seems, on most traceroutes. Here is a weird traceroute from this morning (note the first 4 traces): traceroute cwlabs.com (used as an example) traceroute to cwlabs.com (208.113.235.175), 30 hops max, 40 byte packets 1 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 142.747 ms 105.051 ms 106.480 ms 2 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 54.189 ms 52.121 ms 55.308 ms 3 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 52.709 ms 52.413 ms 53.878 ms 4 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 54.447 ms 55.481 ms 50.730 ms 5 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 55.489 ms 50.655 ms 54.116 ms 6 ae-7.ebr3.Dallas1.Level3.net (4.69.134.21) 75.441 ms 73.117 ms 69.460 ms 7 ae-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 99.071 ms 102.945 ms 109.537 ms 8 ae-82-82.csw3.LosAngeles1.Level3.net (4.69.137.26) 109.883 ms 106.218 ms 108.255 ms 9 ae-31-89.car1.LosAngeles1.Level3.net (4.68.20.131) 98.933 ms 100.706 ms 97.177 ms 10 INTERNAP-NE.car1.LosAngeles1.Level3.net (4.71.140.54) 97.548 ms 98.300 ms 97.674 ms 11 border20.po2-20g-bbnet2.lax.pnap.net (216.52.255.101) 102.012 ms 101.854 ms 98.889 ms 12 newdream-8.border20.lax.pnap.net (216.52.220.146) 97.053 ms 98.325 ms 97.547 ms 13 ip-66-33-201-66.dreamhost.com (66.33.201.66) 98.530 ms 101.100 ms 98.141 ms 14 basic-dap.marvin.dreamhost.com (208.113.235.175) 97.895 ms 97.204 ms 97.296 ms --Patrick
Paging a RIM/Blackberry email staffer
Since postmaster@ is bouncing... (If you are not a RIM employee, you can stop reading now) Due to yahoo's DNS servers deciding to say, this morning, that my MX records point to email.vicimarketing.com.115, in that popular new .115 gTLD... I moved the zone service inhouse. In the process, the email gateway recursors at Blackberry appear to have negative cached that my domain doesn't exist, and carbon copies to *all* of my various BIS BBs are bouncing 55 5.1.8 domain of sender address [EMAIL PROTECTED] does not exist. Anyone listening who can restart those recursive servers? Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)
Weekly Routing Table Report
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 [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 20 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 269427 Prefixes after maximum aggregation: 129901 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131012 Total ASes present in the Internet Routing Table: 29274 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25443 Origin ASes announcing only one prefix: 12385 Transit ASes present in the Internet Routing Table:3831 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 558 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 60 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:755 Number of addresses announced to Internet: 1921880352 Equivalent to 114 /8s, 141 /16s and 145 /24s Percentage of available address space announced: 51.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.6 Total number of prefixes smaller than registry allocations: 132145 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:62233 Total APNIC prefixes after maximum aggregation: 22899 APNIC Deaggregation factor:2.72 Prefixes being announced from the APNIC address blocks: 59152 Unique aggregates announced from the APNIC address blocks:26429 APNIC Region origin ASes present in the Internet Routing Table:3387 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix:905 APNIC Region transit ASes present in the Internet Routing Table:537 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 376338720 Equivalent to 22 /8s, 110 /16s and 121 /24s Percentage of available APNIC address space announced: 80.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:122394 Total ARIN prefixes after maximum aggregation:64619 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks:91649 Unique aggregates announced from the ARIN address blocks: 35095 ARIN Region origin ASes present in the Internet Routing Table:12444 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix:4804 ARIN Region transit ASes present in the Internet Routing Table:1200 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364358112 Equivalent to 21 /8s, 183 /16s and 169 /24s Percentage of available ARIN address space announced: 74.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153
Re: Anyone have experience with Alcatel 9500MXC?
--- [EMAIL PROTECTED] wrote: From: Tom Storey [EMAIL PROTECTED] I have several of these units deployed, they are all running fine, but I am looking for information about them, specifically SNMP related. Our Alcatel contacts have given us a collection of MIBs, from which I cant really get anything useful out of the radios. Other than that they dont seem too hell bent on providing much further help on this subject. Hoping someone else on here might have experience with these units and can share some information about how to get useful information out of them via SNMP, like traffic and error counters, signal parameters, alarm status, etc. -- You might try over on alcatel-nsp as well. scott
Re: LoA (Letter of Authorization) for Prefix Filter Modification?
Stephen Sprunk [EMAIL PROTECTED] writes: Azinger, Marla wrote: I use RWHOIS for proof of who we assign and allocate address space to. How is _you_ showing information in an RWHOIS server that _you_ control in any way proving that the holder of a address block is authorizing _you_ to advertise it on their behalf? At least in my case, it's not *my* rwhois server. My first ISP lists me as the owner/user/whatever in *their* rwhois server, and my second ISP considers that authoritative. seph
