Re: ARIN Lawsuit - Comments anyone?
My question is whether the number resource including IP address is trading item or not. In my understanding, IP address is allocated from ARIN based on use right, not as an asset. If one network is acquired by somebody else, IP address is transfer to new guy based on network engineering plan, not by the money itself. So I think the court itself is not valid. The court considered it as asset, but it is not. It is same as the phone number. If the phone number is assigned to A, and A has debt to B, the court can not order B to have that number unless B has actual phone line AND follow the procedure for those transfer. I think it applies same to IP address resource. So I think ARIN should not deal with Mr. Kremen in private talk. ARIN should go with upper court authority to make it annulled. Otherwise, if people think and agree that IP address is asset, which can be traded, ARIN should sell it, and doesn't need to go through justification process. Hyun Senior Network Engineer/Apps Engineering Norlight Telecommunications * This is my private opinion, and doesn't represent my employer, Norlight official position. Chris Jester wrote: Im wondering how people feel about the response by Mr Ryan, ARIN's legal arsenal. I was forwarded this and would love to know how the networks out there feel about it. Is a long read, but certainly a worthwile one considering the outcome of the case may change IP's as we know them today. I am leaning toward ARINS point of view on the matter, however there are always changes I would hope they make to the way they do things. At the same time, I do believe there has to be an ARIN keeping things in order for the rest of us. So my vote is 60% with RYAN and ARIN. Yours? Vote please in the court of public opinion. --snip-- MR. RYAN: So why is your lawyer talking to you? Let me tell you that there's been a development that we wanted to share with you. As we were leaving Montreal at the last meeting, on the evening that we were flying home, ARIN was sued in California, and we wanted to share some of the information about that with you. This has been the first time literally that we could do so in a meeting capacity; and so as part of our open and transparent processes, we thought we'd let you know that we had been sued in a major way. And let me talk briefly about what has occurred and what we're doing about that. The story is actually a little bit convoluted. It begins in 1998. There was a man named Richard Kremen who is a cyber squatter who had squatted on a name called Sex.com, among other things that he owned. His Sex.com domain name was stolen according to him by a man named Cohen. Mr. Cohen hijacked that and disappeared to Israel and other places in the world, and a lawsuit between these two gentlemen ensued. Mr. Kremen was the person aggrieved. In 2001, unknown to ARIN and without any notice to us, on a day in the course of this lawsuit, the United States District Court in San Jose issued an order, ordering ARIN to turn over certain IP resources that Cohen or people that Mr. Kremen and the court believed were associated with Cohen had obtained from ARIN. No one has ever said that ARIN acted improperly in issuing resources, but what they were, in essence, saying in the court order is that Cohen used money that had been Kremen's to obtain the resources, and in lieu of the money, we were to transfer the resources to Mr. Kremen. So if you've got that, Cohen is the bad guy, according to the court. The court issues an order without ARIN being there. A court order tells you to do something. Well, in 2003, in December of 2003, I had been General Counsel for you about 30 days at that point. We received the order approximately two years after it had been issued. It was provided to us in a formal way, and Mr. Kremen asked us to obey the order. That is, to revoke the IP resources that were held by Mr. Cohen and transfer them to Mr. Kremen. We agreed to do so, so long as Mr. Kremen would do what all of you have done since ARIN began in 1998, which is apply for the resources and sign the normal RSA. Mr. Kremen refused to do that and has refused to the current date. His theory is that he doesn't have to do that because he has a court order, and our theory is that we have a certain set of rules and requirements, and that you have to obey the rules and requirements of the community, and we don't read the court order as giving Mr. Kremen a permanent pass from the rules that all of you obey. We've tried to be very cordial with Mr. Kremen. We believe that Mr. Kremen may have been badly treated by Mr. Cohen, but he certainly has never been badly treated by us. During the time that we've been negotiating with him, we agreed to what was called a standstill order, that there would be no court activity while we negotiated. We turned over thousands of pages of documents within ARIN's control to help him find assets that Mr. Cohen might have had. We revoked resources that were
problem with BGP or I am an Idiot
To all, Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? How is this possible? I have the following filters but I removed them and it seems to not make a diff. OUTBOUND - ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* INBOUND - ip as-path access-list 2 permit .* Philip Sponsored Link $420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre
Re: problem with BGP or I am an Idiot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Lavine wrote: To all, Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? How is this possible? I have the following filters but I removed them and it seems to not make a diff. OUTBOUND - ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* INBOUND - ip as-path access-list 2 permit .* Loop protection. Throw away any route I hear from someone else with my AS. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXc3VE1XcgMgrtyYRAkUqAJ0WYsnAikAZnQc4tldqthD9f4TtBwCg8aUO OE57J9SYPYPRwue7VCUPvec= =3Cki -END PGP SIGNATURE-
Re: problem with BGP or I am an Idiot
On Nov 17, 2006, at 9:57 AM, Bruce Pinsky wrote: Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? How is this possible? I have the following filters but I removed them and it seems to not make a diff. OUTBOUND - ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* INBOUND - ip as-path access-list 2 permit .* Loop protection. Throw away any route I hear from someone else with my AS. As long as you are hearing default your transit providers (you do have at least two, right? if you only have one, you don't need BGP and are just polluting the routing table), it won't matter if you can hear the prefix from your other location. -- TTFN, patrick
Re: problem with BGP or I am an Idiot
On Fri, Nov 17, 2006 at 06:44:11AM -0800, Philip Lavine wrote: To all, Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? How is this possible? I have the following filters but I removed them and it seems to not make a diff. OUTBOUND - ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* INBOUND - ip as-path access-list 2 permit .* you will not accept a route with your AS in teh path you can override it (on cisco) with allow-own-as Steve
Re: problem with BGP or I am an Idiot
Philip Lavine wrote: To all, Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. Don't do that then. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? The reason is that a BGP router won't accept a route containing its own AS from an external peer. You can add a static route on both routers to the other network with the gateway of your ISP. A floating static default may also work. Or get a different AS for the other end. -- Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED] Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: ARIN Lawsuit - Comments anyone?
So, what happened on 23 October, since you're putting this up for examination? -- Joe Yao --- This message is not an official statement of OSIS Center policies.
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 18 Nov, 2006 Analysis Summary BGP routing table entries examined: 203977 Prefixes after maximum aggregation: 110635 Unique aggregates announced to Internet: 99054 Total ASes present in the Internet Routing Table: 23714 Origin-only ASes present in the Internet Routing Table: 20668 Origin ASes announcing only one prefix:9968 Transit ASes present in the Internet Routing Table:3046 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: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 1 Unregistered ASNs in the Routing Table: 3 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space: 7 Number of addresses announced to Internet: 1636930476 Equivalent to 97 /8s, 145 /16s and 147 /24s Percentage of available address space announced: 44.2 Percentage of allocated address space announced: 62.7 Percentage of available address space allocated: 70.5 Total number of prefixes smaller than registry allocations: 103463 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:45034 Total APNIC prefixes after maximum aggregation: 18334 Prefixes being announced from the APNIC address blocks: 42613 Unique aggregates announced from the APNIC address blocks:18655 APNIC Region origin ASes present in the Internet Routing Table:2761 APNIC Region origin ASes announcing only one prefix:779 APNIC Region transit ASes present in the Internet Routing Table:411 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 269241056 Equivalent to 16 /8s, 12 /16s and 74 /24s Percentage of available APNIC address space announced: 84.2 APNIC AS Blocks4608-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:101463 Total ARIN prefixes after maximum aggregation:59963 Prefixes being announced from the ARIN address blocks:74702 Unique aggregates announced from the ARIN address blocks: 28353 ARIN Region origin ASes present in the Internet Routing Table:11159 ARIN Region origin ASes announcing only one prefix:4256 ARIN Region transit ASes present in the Internet Routing Table:1032 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 31032 Equivalent to 18 /8s, 135 /16s and 201 /24s Percentage of available ARIN address space announced: 68.6 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 Blocks24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 41751 Total RIPE prefixes after maximum aggregation:27478 Prefixes being announced from the RIPE address blocks:38656 Unique aggregates announced from the RIPE address blocks: 25768 RIPE Region origin ASes present in the Internet Routing Table: 8794 RIPE Region origin ASes announcing only one prefix:4639 RIPE Region transit ASes present in
ietf-bcp38bis mailing list [Was: RFC2827-bis comments solicitation]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a follow-up to my previous message re: RFC2827-bis comments solicitation, we now have a dedicated mailing list for discussion of bringing BCP38 up-to-date: [snip] ietf-bcp38bis mailing list The ietf-bcp38bis mailing list is for discussing an update to BCP 38, Network Ingress Filtering. To subscribe to the mailing list, send a message to: [EMAIL PROTECTED] ...with the single word 'subscribe' in the body of the message. [snip] The web site for this mailing list is sponsored by the VPN Consortium. If you have any suggestions for additions or corrections to this web page, please send them to paul.hoffman(at)vpnc.org. Many thanks to Paul Hoffman for hosting the list. - - ferg First, sorry for any duplicates, but we wanted to reach all interested parties. After several discussions with many different folks last week at IETF 67 in San Diego, as well as various people over the course of the past few months, Dan Senie and I have decided to undertake an effort to update RFC2827/BCP38 [1]. I know that I'm not the only person who has heard various discussions in the past couple of years that concluded that (paraphrased), BCP38 needs to be updated. Now is your chance to speak up. :-) We would very much like to solicit comments suggestions from the community-at-large on areas where you feel BCP38 is lacking, or in areas where you feel it does not properly address with regards to prohibiting source-spoofed traffic from any given administrative network boundary, given that some technical aspects of the Internet may have changed since it's publication. While we acknowledge that a uniform application of a source address verification architecture/ingress filtering scheme will not mitigate _all_ unwanted traffic [2] in the Internet, it will most certainly address the issue of hosts which attempt to source-spoof traffic into the Internet. I have not set up a mailing list for this yet, but if there is enough discussion/input, I will make an effort to do so (or perhaps the SAVA mailing list [3] might be a good place for discussion). In the interim, you can contact me or Dan directly: Paul Ferguson: fergdawg(at)netzero.net Dan Senie: dts(at)senie.com Thanks, fergie dan p.s. Also, for anyone who might be interesting in related work, there is an effort to bring some additional work into the IETF called SAVA, or Source Address Validation Architecture [4]. [1] http://www.rfc-editor.org/rfc/rfc2827.txt [2] http://www.iab.org/about/workshops/unwantedtraffic/index.html [3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava [4] http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/04.html -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFXgK9q1pz9mNUZTMRArqOAKDzeVk2VCfD/Ru0OtrgtNLyJ90MqACePChS 2dqaaWAbXonj185jAtwnZ8Q= =jieX -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: Cisco SLA data access via SNMP?
Ray, Do you have an example of accessing the SLA data via SNMP? I've just got interested in those things, I've found the OIDs required, but its all a bit of a maze ... I could really use some jitter information in a couple of places right about now ... A number of people have asked for how I did the Cricket/SLA thing. I have a description of the configuration at: http://www.oneunified.net/blog/OpenSource/Debian/Monitoring/Cricket/installa ndconfig.article On one of the systems I'm getting a cricket error of: illegal attempt to update +using time 1163791808 when last update time is 1163791808 (minimum one second step) I'm not sure if it affects other systems. I have to check. Anyway, once I get this thing fixed, I think everything should be good to go. Let me know if you have similar problems. Ray http://www.oneunified.net/blog/ -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
Cogent and Sprint peering history?
I've not watched here closely for a number of years, but I now have a Sprint connected customer who is hating life and Cogent seems to be part of the equation. Can someone fill me in on the history of their relationship? I never thought Sprint would ever renew its relationship with Sprint: Tracing the route to portus.netsecdesign.com (66.6.208.6) 1 sl-bb24-rly-9-0.sprintlink.net (144.232.14.122) 0 msec 0 msec 0 msec 2 sl-st22-ash-6-0.sprintlink.net (144.232.20.189) 0 msec 4 msec 0 msec 3 p15-2.core01.iad01.atlas.cogentco.com (154.54.13.61) [AS 174] 4 msec 4 msec 0 msec 4 v3492-mpd01.iad01.atlas.cogentco.com (154.54.3.222) [AS 174] 16 msec 80 msec 196 msec 5 v3497.mpd01.dca01.atlas.cogentco.com (154.54.5.65) [AS 174] 4 msec 4 msec 4 msec 6 t9-3.mpd01.iah01.atlas.cogentco.com (154.54.2.222) [AS 174] 44 msec 44 msec 48 msec 7 t2-3.mpd01.lax01.atlas.cogentco.com (154.54.3.186) [AS 174] 72 msec 72 msec 72 msec 8 g2-0-0.core01.lax01.atlas.cogentco.com (154.54.2.101) [AS 174] 72 msec 72 msec 72 msec 9 g49.ba01.b002698-1.lax01.atlas.cogentco.com (66.250.12.130) [AS 174] 72 msec 72 msec 72 msec 10 PAJO-Networks.demarc.cogentco.com (38.112.9.190) [AS 174] 72 msec 76 msec 72 msec 11 dcap04.pcap.lax01.tierzero.net (216.31.128.14) [AS 11509] 72 msec 76 msec 72 msec 12 mmic-gw.dcap6.lax.us.tierzero.net (216.31.188.94) [AS 11509] 76 msec 80 msec 80 msec 13 dazedandconfused.netsecdesign.com (66.6.208.4) [AS 11509] 84 msec 84 msec 88 msec 14 portus.netsecdesign.com (66.6.208.6) [AS 11509] 84 msec 84 msec 88 msec Next I will see pigs flying :) Wonder how long it will last based on Cogent's past behavior as noted here. Edward Ray - This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com -
Re: Cogent and Sprint peering history?
neal, all, On Fri, Nov 17, 2006 at 05:46:43PM -0600, nealr wrote: I've not watched here closely for a number of years, but I now have a Sprint connected customer who is hating life and Cogent seems to be part of the equation. Can someone fill me in on the history of their relationship? they used not to peer and cogent reached sprint via ntt america (verio). now they are directly connected (at least in north america for north american routes). the routing situation is evolving and may have changed since last i wrote about it at: http://www.renesys.com/blog/2006/11/sprint_and_cogent_peer.shtml (there's some path detail in that posting including stuff about when the most recent change took place and what kind of prefixes are carried on the adjacency. there's nothing in there about the quality of either network or the capacity of the interconnection). t. -- _ todd underwood +1 603 643 9300 x101 renesys corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: problem with BGP or I am an Idiot
SW Date: Fri, 17 Nov 2006 15:56:53 + SW From: Stephen Wilcox SW you can override it (on cisco) with allow-own-as s/allow-own-as/allowas-in/ Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Drone Armies CC Report - 17 Nov 2006
This is a periodic public report from the ISOTF's affiliated group 'DA' (Drone Armies (botnets) research and mitigation mailing list / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. For purposes of this report we use the following terms openthe host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 4189 unique, domains (or IPs) with port suspect CCs. This list is extracted from the BBL which has a historical base of 13405 reported CCs. Of the suspect CCs surveyed, 649 reported as Open, 947 reported as closed, and 755 issued resets to the survey instrument. Of the CCs listed by domain name in the our CC database, 5847 are mitigated. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. Percent_ ASN Responsible Party Total OpenResolved 19318 NJIIX-AS-1 - NEW JERSEY INTERN117 27 77 13301 UNITEDCOLO-AS Autonomous System of102 30 71 16265 LEASEWEB AS55 38 31 23522 CIT-FOONET 46 33 28 8560 SCHLUND-AS 40 25 38 30058 FDCSE FDCservers.net LLC 38 12 68 4766 KIXS-AS-KR 33 5 85 15083 IIS-129 Infolink Information Servic31 0100 174 Cogent Communications 30 25 17 33597 InfoRelay Online Systems, Inc. 29 0100 13213 UK2NET-AS UK-2 Ltd Autonomous Syste26 0100 9318 HANARO-AS 25 7 72 12832 Lycos Europe 24 0100 1659 ERX-TANET-ASN1 24 6 75 24611 AS24611 Datacenter Luxembourg S.A. 23 0100 7132 SBC Internet Services 23 4 83 30083 Server4You Inc.22 8 64 4314 IIS-64 I-55 INTERNET SERVICES 22 2 91 19166 Alpha Red, INC 19 5 74 30407 Velcom.com 19 3 84 Top 20 ASNes by number of active suspect CCs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. Percent_ ASN Responsible Party Total OpenResolved 16265 LEASEWEB AS55 38 31 23522 CIT-FOONET 46 33 28 13301 UNITEDCOLO-AS Autonomous System of102 30 71 19318 NJIIX-AS-1 - NEW JERSEY INTERN117 27 77 8560 SCHLUND-AS 40 25 38 174 Cogent Communications 30 25 17 30058 FDCSE FDCservers.net LLC 38 12 68 30315 Everyones Internet 13 8 38 15516 DK-ARROWHEAD9 8 11 9800 UNICOM 19 8 58 30083 Server4You Inc.22 8 64 12322 PROXAD AS for Proxad ISP 10 8 20 28753 NETDIRECT AS NETDIRECT Frankfurt 13 8 38 3786 ERX-DACOMNET 14 8 43 36263 forona.11 7 36 9318 HANARO-AS 25 7 72 3462 HINET 13 7 46 34305 EUROACCESS Euroaccess 9 7 22 6140 ImpSat 8 6 25 1659 ERX-TANET-ASN1 24 6 75 A version of this report with addition rankings can be found via the isotf.org home page. Randal Vaughn Gadi Evron Professor ge at linuxbox.org Baylor University Waco, TX (254) 710 4756 randy_vaughn at baylor.edu
RE: Cisco SLA data access via SNMP?
On one of the systems I'm getting a cricket error of: illegal attempt to update +using time 1163791808 when last update time is 1163791808 (minimum one second step) There was a problem with a number of Tunnel interfaces not getting processed. Things are good now. Cisco QoS and SLA's are indeed viewable with Cricket. Ray http://www.oneunified.net/blog/ -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
Re: Cisco SLA data access via SNMP?
### On Sat, 18 Nov 2006 01:25:50 -0400, ### Ray Burkholder [EMAIL PROTECTED] casually decided to expound upon ### nanog@merit.edu ### the following thoughts about RE: Cisco SLA data access via SNMP?: RB On one of the systems I'm getting a cricket error of: RB illegal attempt to update +using time 1163791808 when last RB update time is RB 1163791808 (minimum one second step) RB RB RB There was a problem with a number of Tunnel interfaces not getting RB processed. Things are good now. Cisco QoS and SLA's are indeed viewable RB with Cricket. There are also a bunch of Cacti templates available as well... I'm using modified versions of these. http://forums.cacti.net/about4136-0-asc-0.html -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
