RE: 2001:590::/32 announced by both AS4436 (nLayer) and AS4474 (Global Village, no contact in whois, but seems to be nLayer...)
Before you started a rant on [EMAIL PROTECTED] about this inconsistent-as problem on an inet6 route, did you think about posting a polite, "Please, someone from nlayer, contact me off-list," message; or how about an email to the inet6 carrier(s) from which you learnt the routes? It seems to me that you've taken an issue which could've been handled in a polite manner, and turned it into an nlayer-bashing thread. You have: 1) encouraged nlayer's peers to depeer them 2) accused nlayer of being spammers 3) forwarded private corrospondence you received from third parties in response to your original post back to [EMAIL PROTECTED] as well as the [EMAIL PROTECTED] role account, as if the ARIN staff have nothing better to do than read your complaint about an AS# they have already marked as having invalid contact information. I think I prefer reading about the IRC packet kiddies. If OseK would care to lend his unique perspective and considerable insight to this thread, I would be most grateful. -- Jeff S Wheeler
Re: Converged Networks Threat (Was: Level3 Outage)
On Wed, 2004-02-25 at 13:34, David Meyer wrote: > Is it that sharing fate in the switching fabric (as > opposed to say, in the transport fabric, or even > conduit) reduces the resiliency of a given service (in > this case FR/ATM/TDM), and as such poses the "danger" > you describe? Our vendors will tell us that the IP routing fabrics of today are indeed quite reliable and resistant to failure, and they may be right when it comes to hardware MTBF. However, the IP network relies a great deal more on shared/inter-domain, real-time configuration (BGP) than do any traditional telecommunications networks utilizing the tried and true technologies referenced above. Yesterday we witnessed a large scale failure that has yet to be attributed to configuration, software, or hardware; however one need look no further than the 168.0.0.0/6 thread, or the GBLX customer who leaked several tens of thousands of their peers' routes to GBLX shortly before the Level(3) event, to show that configuration-induced failures in the Internet reach much further than in traditional TDM or single vendor PVC networks. The single point of failure we all share is our reliance on a correct BGP table, populated by our peers and transit providers; and kept free of errors by those same operators. -- JSW
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Sun, 2004-01-25 at 14:44, Will Hargrave wrote: > I would check the Foundry Fastiron series - maybe the 4802. Everything > I've read appears to indicate they support all 4096 vlans > simultaneously, although you will of course want to verify this. I don't think this is true. Those of you with BigIron units know that (at least in m3 supervisors) they support only 512 vlans at most. I do not think the older, and generally less capable, FastIron switches are likely to support more. The command to check this on BigIron is `show default values`. -- Jeff
Re: Authority
On Wed, 2003-12-10 at 14:34, Christian Malo wrote: > the nanog-l is not WILLIAM LEIBZON's personnal hatered list. If he wants > people to read on his stuff, he can just start his own list. Actually, he has his own mailing list, and it is closed to the public. You can read it at http://archive.humbug.org.au/hijacked/ though this is an unauthorized archive that some dissenting list member populates. They even have little internal witch-hunts to try to find out which of their list members are responsible for information leaks. It's quite novel! -- Jeff
Re: BGP issues
On Wed, 2003-09-17 at 17:29, Peter E. Fry wrote: > Bret Baptist wrote: > [...] > > Right now I have visi.com as one provider (AS8015), and Qwest (AS3908) as the > > other. When I look at the as-paths for my netblocks the ones from visi.com > > look fine, 208.42.20.0/23 and 208.42.104.0/23, the ones from Qwest go through > > visi.com and then on to us, 65.116.186.0/24, 65.121.8.0/23. The Qwest > > networks are the ones that I am having problems reaching hosts from or > > getting to from other networks. [...] > > It's a bit of a long shot and difficult to see, but when I see natural > C blocks without problems and natural A blocks with, I tend to suspect > class-based filtering. This usually occurs if there's no less-specific > route available, but there's 65.112.0.0/12 from Qwest covering both. > This leaves only a few very obscure possibilities, so I wouldn't chase > this except as a last resort. > > Peter E. Fry I did a couple quick RADB queries, and I find no object for as AS30309. In addition there are no objects for the VISI-assigned blocks you mentioned, even with a shorter prefix length. I would strongly recommend a visit to WWW.ALTDB.NET if you already know how to update an IRRd database via email templates; or if not, pay your $500 to MERIT and use WWW.RADB.NET instead. Personally, I have used both ALTDB and RADB, and while it's obvious that "you get what you pay for", and no one should complain if they don't like the free ALTDB service, I have been very pleased with MERIT's responsiveness. -- Jeff S Wheeler
RE: What *are* they smoking?
On Mon, 2003-09-15 at 19:35, ken emery wrote: > According to the article in the link posted from cbronline.com this has > been done by NeuStar who runs the .biz and .us domain registries. The > company which runs this service for NeuStar claims to be able to > differentiate between http and other requests. I'm still waiting to > see how they do this as you can't tell from a DNS request alone. I'm waiting for Illuminet^HVeriSign to add this "feature" to their global title translation database and redirect all non-existant 800 numbers to recorded advertisements. -- Jeff S Wheeler
Re: SNMP OID's for BGP monitoring
On Fri, 2003-09-05 at 11:23, Austad, Jay wrote: > What OID's are people using to monitor/graph BGP stats on Cisco routers? Cisco maintains a very useful SNMP OID search tool which you can access through your favorite web browser. A search for "bgp" yields 135 results. Unfortunately .1.3.6.1.4.1.9.9.187.1.2.4.1.1 is *not* shown in this tool! I wonder how up-to-date this tool typically is? In any case, if that OID is not available on your IOS image, you have the option of retrieving sufficient information from the cbgpRouteEntry table at .1.3.6.1.4.1.9.9.187.1.1.1.1 to count the prefixes received from each peer as well as the prefixes installed into the FIB for each peer (cbgpRouteBest BOOL). This would obviously be a big CPU hit, but there is a great deal of data available via SNMP. http://www.cisco.com/pcgi-bin/Support/Mibbrowser/unity.pl -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: 69/8...this sucks
On Fri, 2003-03-07 at 23:15, Jack Bates wrote: > In defense of ARIN, the ice on a net block has to be broken at some point. > They could wait 3 years and notify every list every hour of every day for > those 3 years and there would still be many networks filtering those > networks. The only way to catch it is to notice the block and make contact > with the network. In many cases, personal contact is necessary as emails are > often misunderstood or ignored. I repeat my suggestion that a number of DNS root-servers or gtld-servers be renumbered into 69/8 space. If the DNS "breaks" for these neglected networks, I suspect they will quickly get enough clue to fix their ACLs. Add Eddy's suggestion that the addresses all end in .0 or .255 and you have a fine machine for cleaning up a few old, irritating problems. -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: Remote email access
On Wed, 2003-02-05 at 04:04, [EMAIL PROTECTED] wrote: > If ARIN, RIPE and APNIC were to find some financial and political support, > then I believe that they could provide a global authoritative database of ARIN has no lack of financial resources. From my perspective, the only thing the ARIN lacks is respect for the wishes and needs of its members. -- Jeff S Wheeler <[EMAIL PROTECTED]>
OT: alex@yuriev.com email issues?
Dear nanog, I apologize in advance for my off-topic posting. I doubt I am alone, though, in saying that Alex Yuriev needs to "slow his roll". Alex, stop sending a follow-up to everything you read. If you really have something to say, please just write a pointed email with a sensible subject and send it. ONCE. I do not intend to flame, but I have mailed similar comments to Alex in private before and it has quite clearly not reduced this behavior. I am not trying to bash his views or his person, only ask him not to post 13 messages in the span of two hours. Again, my apologies for this off-topic posting. -- Jeff S Wheeler <[EMAIL PROTECTED]>
Attacks against Paul Vixie's home network
On Tue, 2003-01-14 at 14:09, Paul Vixie wrote: > i've had absolutely no luck getting the source isp's to care about > the problems i've seen at my home firewall in recent weeks. (see I recommend you blackhole the offending /32s from F. Obviously these worms, connected via unresponsive or incapable networks, are a danger to F and to our national infrastructure. And while you're at it, renumber F into 69/8, preferably with the last octet 0 or 255. -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: AOL & Cogent
On Mon, 2002-12-30 at 06:37, Basil Kruglov wrote: > For my not-so-bright customers I simply want traceroutes to look good when > they run one from Level3-homed site. Obviously a ~5-7 hops to us looks > really disturbing, try to explain to one of them that there is no problem. After some off-list discussion I think I understand the issue. You do not want customers who are doing a traceroute from Level3 or one of their downstreams to see high latency on some of their traceroute hops going toward you, because you cannot control the egress path of those ttl_exceeded packets from cogent's network, even though you can control your own egress. So the obvious solution is to prepend your advertisements toward cogent, which will cause them to carry less of your inbound traffic. This has a negative impact for cogent, because they need that inbound traffic to justify some of their peering agreements (think, ratios). Supposedly this is the reason they couldn't keep the ATDN peering, eh? If all their web host-type customers suddenly start prepending advertisements, it will cause them to bleed inbound traffic. If you want to encourage cogent to build a rich community set so you can prepend only toward Level3, perhaps you should start prepending toward cogent and make the point with your cogent rep that this is going to cause them to lose your inbound traffic, and if they gave you more control over route advertisements, it would not have such an impact. On the other hand, maybe cogent doesn't want web hosts as customers. :-) -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: AOL & Cogent
On Sun, 2002-12-29 at 15:57, Jeff S Wheeler wrote: > Basil, Oops. Obviously, I posted this to the list by mistake. But in any case, for those of you who are "relying upon" cogent pricing to make your business model work, it should be easy to figure out that at some point, you might start getting what you are paying for. If you only have one vendor that can sell you the product you need at the price you need to make your business work, you are putting all your eggs in one basket. Your investors and customers should be concerned. It's time for companies in this situation to stop complaining at cogent or AOL or the double-secret peering cabal, and start realizing that they need to make arrangements with other vendors in order to give themselves the flexibility to avoid problems such as this. Sorry for the accidental post :-) -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: AOL & Cogent
Basil, If you recall, we talked about purchasing cogent access from you quite some time ago, as Five Elements is also in the Switch & Data facility. If you need somewhere to off-load your AOL-bound traffic, we have some excess Aleron transit, and they have AOL peering of some sort right in Chicago. As we have excess capacity right now we could do it for a cost that would be similar to your cogent cost on a month-to-month basis, provided it does not exceed 40Mb/sec or so, and we'll let you know when our excess starts to run out and we start to incur cost on it. Most likely, by that time the Cogent/AOL issue will be resolved anyway, but it protects us from getting into a long-term deal selling below cost, while allowing you to improve network performance while maintaining your current cost structure as long as we have excess that we have to pay for, anyway. I'm not trying to "pitch" you, just help out :-) Here is a traceroute from the router we could put you on. I have a free 100baseT port, or we could put you on a switch if you don't mind. [EMAIL PROTECTED]:~$ traceroute -q1 www.atdn.net # us in switch & data traceroute to atdn.net (64.12.181.62) from 199.166.200.16, 30 hops max, 38 byte packets 1 gige2.mr0.chcgil2.ings.com (199.166.200.2) 0.341 ms # us in equinix 2 ge3-7.as.eqxchiil.aleron.net (205.198.16.141) 0.403 ms 3 ge6-2.ar.eqxchiil.aleron.net (205.198.16.41) 0.365 ms 4 66.185.141.105 (66.185.141.105) 23.778 ms # first AOL TDN hop 5 66.185.148.66 (66.185.148.66) 24.009 ms 6 bb2-vie-P10-0.atdn.net (66.185.152.215) 24.041 ms 7 bb2-rtc-P0-2.atdn.net (66.185.152.116) 24.110 ms 8 bb2-mtc-P8-0.atdn.net (66.185.152.100) 24.661 ms 9 pop1-mtc-P12-0.atdn.net (66.185.143.195) 24.810 ms 10 ow1-mc1-so-0-0-0.atdn.net (66.185.143.202) 24.839 ms 11 172.20.148.22 (172.20.148.22) 25.150 ms 12 172.20.148.22 (172.20.148.22) 25.048 ms !A I hope you don't mind my inquiry. Drop us a line if you think we can help provide a stop-gap measure for the Cogent/AOL thing, or whatnot. -- Jeff S Wheeler <[EMAIL PROTECTED]> On Sat, 2002-12-28 at 21:24, Basil Kruglov wrote: > > Speaking of this whole Cogent/AOL/Level3 mess.. sigh. > > I got tired of trying getting anything out of Cogent. So, here's list of > questions perhaps someone might be able to answer. > > 1. I'm sure some of you are customers of Level3, and I'm sure > you do see 1-2 sec latency w/ Cogent, what's the official Level3 'position' > if/when you contact them? Do they have any plans upgrading capacity with > Cogent, what's their side of this story in general? > > > 2. I think I asked this before, why wouldn't Cogent prepend > customer prefixes to Level3 or set BGP4 community for multihomed sites, > homed w/ Cogent + someone else. > > (This is to control inbound, and please don't go into "this is not-standard > and Cogent won't do it".) > > > 3. Did anyone suggested to Cogent to carry traffic (or some portion of it) > to AOL via MFN to offload its Level3 peering? I couldn't get any straight > answer from Cogent why this can't be done. > > > 4. And another interesting perspective... I'm sure NDAs on peering are > involved, but anyhow -some of us don't really care about AOL that > much, assuming it is only outbound from Cogent into AOL (via Level3) that is > saturated, Cogent may try to push traffic as: > > 16631_174_3356_ excluding AOL' ASN(s) at one peering location > > and keep saturating its Level3 peering connectivity at other locations. Any > thoughts? > > -Basil >
RE: Operational Issues with 69.0.0.0/8...
On Sat, 2002-12-07 at 08:56, Todd A. Blank wrote: > 4) Listen to feedback from the first few people allocated space >and if it still is not properly routed send out another notice >to people and possibly delay additional allocations from the >block for another month. I disagree with this part of your suggestion. Delaying new allocations will only serve to delay acceptance of new spaces. If you implement all the other safeguards you have suggested, the multitude of notices should ensure that clued, well-informed, responsible networks have ample time to make adjustments in their networks. Networks not among those will most likely not respond until their downstream customers complain, and the best way to get those complaints started is to get more folks into those new networks. I suggest moving all of the GTLD name servers into newly allocated blocks as they become available. This will certainly break networks which are low on operational clue, and force them to get fixed. -- Jeff S Wheeler <[EMAIL PROTECTED]> 502-523-6989
Re: Traceroute from A to B
On Fri, 2002-11-15 at 08:39, Minseok Kwon wrote: > Is there a way or tool to find the route between two arbitrary hosts from > one of my local machines? In other words, given two host IP addresses A > and B, I would like to find the route between A and B. I can use a source > route, 'traceroute -g', to approximate the route. I have tried this > option. Lots of routers, however, do not accept source routes. Any help > will be appreciated. Thanks. No. -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: all the mails on Filtering
On Wed, 2002-11-13 at 13:25, Harsha Narayan wrote: > So what happens to multihoming assignments made by the ISP? That means > the multihoming assignment can't be used as a backup. If the customer's This has been rehashed time and time again on this list, and others. The fact is, ISPs have to filter somewhere to keep routing table growth in check. It makes more sense to filter out announcements longer than the longest assignment within an RIR's space than to filter on any arbitrary boundary. I think everyone will agree with that, even if they do not agree that filtering is necessary or good. As an example of why filtering is good, click on this link and visit the CIDR Report AS Summary for an ISP here in Kentucky. They used to have over 50 useless announcements within one /18, for which they had an aggregate announced as well. They seem to have gone to some efforts to reduce the route table pollution the emit, and I applaud their efforts, however you can further reduce the amount of pollution you accept from them, and other ISPs who mistakenly announce from their IGP or for any other reason do not announce blocks as they are assigned by the RIR, simply by filtering on the minimum assignment size. http://bgp.potaroo.net/cgi-bin/as-report?as=11979&view=4637 I think there are very few networks who purposely announce longer networks to control their inbound traffic flow, verses the number who mistakenly do so. Again, everyone will agree. Except, perhaps, Ralph Doncaster. And if you want to spend your FIB entries, and your money, making your bits flow to him in the manner that's most cost-effective for ISTOP, then more power to you. Most folks will agree that is up to Ralph and Ralph's ISP(s) to work out, though. -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: WP: Attack On Internet Called Largest Ever
On Tue, 2002-10-22 at 19:41, Paul Vixie wrote: > > > (Okay Paul - here's your chance to rant about how badly they misquoted > > you! ) > > I think it's clear that editors were involved. > -- > Paul Vixie > I did notice that Paul was quoted as stating essentially that F was not impacted. From my own experience and numerous folks who monitor DNS performance this seems true. However, I did notice that several of the servers which are operated by VeriSign were not responding to at least a large, 50% or greater, fraction of test queries. Even so, VeriSign was good enough to chime in that their root servers were unaffected. Did I mis-perceive this, or is it another bold-faced lie from VeriSign? -- Jeff S Wheeler <[EMAIL PROTECTED]>
Re: the cost of carrying routes
Ron, Many carriers require that you advertise a certain minimum number of routes to them over your peering sessions, or they will not peer with you. This suggests that those carriers see routes carried as a point of value, rather than or in addition to one of cost. I have seen 5,000 routes as a minimum used by more than one transit-less carrier. Is this really an operational value perception at these carriers, or is it simply a means of creating a barrier-to-peering? Are fewer, shorter prefixes seen as more valuable than longer ones, e.g. swamp /24s? Is a University or other entity with a legacy /16 more or less valuable as a peer than a growing ISP with a few /20s, and presumably more eyeballs and/or content behind them? -- Jeff S Wheeler <[EMAIL PROTECTED]> On Mon, 2002-10-14 at 16:47, Ron da Silva wrote: *snip* > Do any ISPs charge based on the number of announcements a customer > advertises? > > If downstream advertisements became mainly smaller prefixes (say /24) > that were not aggregatable by you as their upstream ISP, would you > answer the above question differently?
Re: Major Labels v. Backbones
On Mon, 2002-08-19 at 11:46, Owen DeLong wrote: *snip* > Please, the intent of that sentence is to say that the ISP cannot set > the > destination IP address for the content. The intervening backbones don't > do > that, they merely copy it to the next hop as the MAC addresses are > modified > to send it along it's way. The RECIPIENT is DETERMINED (set) by the > originator of the communication. There are two hosts which could be > argued > to participate in this process, and they are at the ends of the > conversation. > The routers in between do not meet the test. If this is the basis of your argument, multicast backbones would be a legal liability. How about a 1-800 conference circuit? The concept is the same, as is the level of content participation. The difference is the legal protection offered to the voice common-carrier is greater than what is offered to IP carriers. -- Jeff S Wheeler [EMAIL PROTECTED] Software DevelopmentFive Elements, Inc http://www.five-elements.com/~jsw/
