Re: Superfast internet may replace world wide web
On Mon, 7 Apr 2008, Glen Kent wrote: says the solemn headline of Telegraph. http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/04/06/ninternet106.xml So, the internet was created in Switzerland at Cern's particle physics center? Can someone look up Al Gore's passport history and tell us when he spent time there? :) ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: cooling door
On Sat, 29 Mar 2008, John Curran wrote: unit...I know that it would have to be quite a bit before many folks would: 1) introduce another cooling system (with all the necessary redundancy), and 2) put pressurized water in the immediate vicinity of any computer equipment. What could possibly go wrong? :) If it leaks, you get the added benefits of conductive and evaporative cooling. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Customer-facing ACLs
On Tue, 18 Mar 2008, Marshall Eubanks wrote: If it becomes normal for home users to only have 80 and 443, then how can I innovate and design something that needs a new protocol ? What happens to the new voice and video services for example ? The DOD has already been faced with this (I know of some AFB that have instituted this policy). The solution, of course, is to hire consultants (SIBR if possible) to port everything to port 80 ! That's been going on for years. Back when it was common for ISPs to run squid servers and transparently proxy to them (probably around 2000), I ran into a customer using some sort of aviation data in real time app which used port 80 (and wasn't HTTP). I had to special case traffic to that service's IP to get it not to hit squid. When I asked them why they were running a non-HTTP protocol on 80/tcp, the answer was "that gets us through most firewalls." ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Kenyan Route Hijack
On Mon, 17 Mar 2008, Alastair Johnson wrote: Correct. A particularly interesting case, since ORBS' transit provider was also a transit customer of Above.net. Said transit provider would announce their /16s, of which ORBS sat in a /24 or two of, and have their traffic blackholed. IIRC they punched /24s via their other transit providers to partly resolve the issue. But the rest of the story - let's not go there. Why not? We _used_ to be an Above.net OC3 customer. Back around 2003, we ran into issues with Above.net deciding for us which parts of the internet should be accessible. We got customer complaints that certain web sites were unreachable through us, but worked fine on other internet services. I eventually got Above.net to give me a list of the several dozen /24's they were null routing. This was particularly annoying because they had nothing setup to notify customers of these null routes or allow us to choose not to send them traffic they'd null route. To me, this seemed rather inappropriate behavior for a transit provider. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: ISP's who where affected by the misconfiguration: start using IRR and checking your BGP updates (Was: YouTube IP Hijacking)
On Mon, 25 Feb 2008, Hank Nussbacher wrote: For us who actually have customers we care about, we probably find it better for business to try to make sure our own customers can't announce prefixes they don't own, but accept basically anything from the world that isn't ours. You are a distinct minority. My experience has shown that most ISPs don't give a sh*t about filtering what their customers can announce so what has happened, will continue to happen. I've only dealt with a handful of the bigger networks, but every transit BGP session I've ever been the customer role on has been filtered by the provider. From memory and in no particular order, that's UUNet, Level3, Digex, Intermedia, Global Crossing, Genuity, Sprint, Above.net, Time Warner, C&W, MCI, XO, Broadwing, and a few smaller ones nobody's likely to have heard of. As an ISP providing transit, all of our customers get prefix-filtered. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: What is being 'ON NET' good for these days?
On Mon, 18 Feb 2008, William Herrin wrote: "On Net" is like "Tier 1." It has devolved into marketspeak that doesn't mean very much. In your case it seems to mean that you can connect with that particular carrier without first purchasing an ILEC local loop. This is mildly helpful, but only mildly. What it sounds like you're looking for is a "carrier neutral" data center where you can connect with multiple providers and peers. The Equinixes and Switch and Datas of the world fill this niche. It sounds to me like he wants transport to one of those sorts of places, and either his "on-net" providers are unwilling to provide that, or he hasn't asked them properly for it. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Tue, 22 Jan 2008, William Herrin wrote: Right now we rely on ARIN and the RIRs to artificially suppress the growth of the prefix count and with it the availability of PI space. If by artificially suppress, you mean anyone who wants it can't just fill out a form and be handed a portable /24 or other small CIDR sure...but you don't need PI space to multihome or increase the size of the global table. Giving absolutely anyone who wants it PI space would make things much worse...so I wouldn't call that artificial supression. It's more like keeping the model sustainable. If we can determine the cost to announce a prefix then we could develop a market-based solution to the problem... One where instead of suppressing the prefix count and dealing with it as business overhead, we GET PAID for announcing and propagating prefixes. I think you mean "get paid for accepting prefixes" or perhaps "pay into some global pool (for redistribution to the participants) to announce prefixes". Good luck on that one. In how many languages can you say "not gonna happen"? ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Mon, 21 Jan 2008, William Herrin wrote: Hmm. Well, the secondary market is flooded with sup2's right now, with the card at sub-$1k prices and with a 6500+sup2 in the $5k range. There isn't really a comparable availability of the sup720-3bxl although eBay does have a few listed in the $12k range. If we take I started to get into this in the last message and decided not to...but another problem with these comparisons is the 'going rate' for Sup2s is very likely depressed considerably due to their no longer being suitable for full BGP table applications. Go back a couple years, and they were quite a bit more $...probably closer to $10k. Another is that networks having to upgrade now already bought whatever they're upgrading from (i.e. Sup2s) some time ago at prices similar to what the 3bxls go for now. So they're not just having to spend more or the difference...they're having to nearly double their investment in full table routers (some parts such as the chassis and line cards will likely remain in service). I wouldn't want to stand behind those numbers, though. I'm not sure what the error band is, but it has to be huge. The equivalence in the secondary market just isn't there. Nor can we use $12k as the baseline price for the sup720-3bxl. There isn't wide availability at that price, just a few sketchy sellers from Hong Kong. I wonder if those are being faked yet? Is there really any point in trying to put a $ figure on each route? Common sense should tell us that polluting the DFZ will eventually cost every network wanting/needing to participate real money (thousands for smaller networks, hundreds of thousands or millions for larger networks/backbones)...so we really ought to be putting effort into education rather than crunching theoretical numbers to determine exactly how many french fries each route equates to. I know from past experience, that ARIN can step in and 'use their influence' to get transit providers to not accept routes they don't think an ASN should be announcing (acquisition that went way south). I don't know what sort of yearly cash flow surpluses the other RIRs have, but IIRC ARIN is doing quite well. The stats I have from last September suggest the 'ARIN region' is the worst as far as longer than RIR minimum routes being announced. Perhaps ARIN could task one or more people with examining the ARIN portion of the DFZ, and contacting the networks announcing unnecessary deaggregates and when necessary their transit providers, for the purpose of educating and when necessary, leaning on them to clean up their configs. Actually, there are already people doing the first part of that job for free...so all ARIN would have to do is accept & check data that's already been researched and pluck the ARIN member networks from it. I know, BGP Police is not part of ARIN's mission...but they have the $ to put people on the job and the influence to perhaps get people to pay attention. In my limited experience trying that role, I found networks were totally uninterested in cleaning up and it wasn't even possible to get directly in touch with someone who'd understand the issue much less have access to do anything about it. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Mon, 21 Jan 2008, Joe Greco wrote: Given that the 3750 is not acceptable, then what exactly would you propose for a 48 port multigigabit router, capable of wirespeed, that does /not/ hold a 300K+ prefix table? All we need is a model number and a price, and then we can substitute it into the pricing questions previously posed. If you disagree that the 7600/3bxl is a good choice for the fully-capable router, feel free to change that too. I don't really care, I just want to see the cost difference between DFZ-capable and non-DFZ-capable on stuff that have similar features in other ways. If using the 7600/3bxl as the cost basis of "the upgrade", you might as well compare it to the 6500/7600/sup2 or sup3b. Either of these would likely be what people buying the 3bxls are upgrading from, in some cases just because of DFZ growth/bloat, in others, to get additional features (IPv6). ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: BGP Filtering
On Sat, 19 Jan 2008, Andy Davidson wrote: On 15 Jan 2008, at 16:11, Ben Butler wrote: As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use & traffic engineering. Maybe you don't get covering aggregates. That causes holes. Whether you care is a matter of local policy, though. :-) There's no maybe about it. Filtering on RIR minimums will result in the more clue deprived networks disappearing from your view and a loss of reachability unless you have default pointed at some network not using such a filter. Since I've gotten several requests recently for the "latest version" of what I posted back in September (I guess others are starting to get worried/close to their limits), I decided this was a good time to setup some blog software (late last night)...and I posted the filter and a brief intro to http://jonsblog.lewis.org/ ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: BGP Filtering
On Tue, 15 Jan 2008, Christopher Morrow wrote: Jon, didn't you start: http://www.wibble.co.uk/archives/nanog/2007/msg05265.html Yep. and Ben, is this sort of what you are looking for? Or would it accomplish the same thing for you? I don't think it's at all what Ben "wants", but I think it's the closest thing to it that's actually available, relatively simple to configure, and accomplishes the desired savings. For anyone in need of such savings, I recommned you start with one RIR at a time and carry a default route, because you're going to lose some networks. If you want to be somewhat charitable, bump the limits up 1-bit and filter on RIR minimums + 1. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: BGP Filtering
On Tue, 15 Jan 2008, Ben Butler wrote: I want a filter that will automatically match the shorter prefixes that match any longer prefix, once I can match them I can drop them. I don't want to manually configure a static prefix list for lots and lots and lots of reasons. If the longer prefix disappears from the route table I want to stop filtering the shorter prefixes - automatically. This was talked about / requested several months ago on cisco-nsp. IIRC, the thread ended along the lines of don't hold your breath. Implementation of this sort of feature is very icky (lots of details you may not be considering) and why should cisco spend time writing this code when they can sell you a bigger router instead? If the filter has to remember routes that are filtered so they can be automatically unfiltered if their covering prefix is withdrawn, then where's your savings? You can't have tea and no tea simultaneously. You want to filter routes, but keep them around (and extra pointers connecting their covering prefixes to them) in case they're needed in the future...sort of like partial soft-reconfig. On a platform like the 6500 where you may have surplus RAM but limited TCAM, that could work...on the software routers where RAM is the limiting factor it's not going to help. -- ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, 8 Jan 2008, Joe Provo wrote: Until you assign a .255/32 to a router loopback interface and then find that you can't get to it because some silly router between you and it thinks '.255? that's a broadcast address.' See the qualifier "where you don't care that broken or archaic systems cannot reach them". If you have brokenness on your internal systems then yes, you'd be shooting yourself in the foot. Until you shoot yourself in the foot, how would you know you have such brokenness on your internal systems? That silly router happened to be a 7206 running (IIRC) 12.1T code. Unless you really don't care about the brokenness, or really want to root it all out, I'd avoid using .0 and .255 IPs. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, 8 Jan 2008, Joe Provo wrote: Yes. Efficient address utilization is a Good Thing. I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Great for router interfaces, loops, etc where you don't care that broken or archaic systems cannot reach them, and where the humans interacting with them should have no issues. Until you assign a .255/32 to a router loopback interface and then find that you can't get to it because some silly router between you and it thinks '.255? that's a broadcast address.' Been there...had to change the loopback IP. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
On Sat, 22 Dec 2007, Greenhalgh, John wrote: throughout the satellite industry. So if we didn't deaggregate RIR blocks, we'd have at least one RIR allocation per discontiguous network and so would be contributing the same number of prefixes to the global table. True, but I've seen enough networks that deaggregate because they just don't know any better. If we were to make an exception for every network that had reasonable cause to deaggregate, that probably wouldn't scale. Relaxing the filters by a few bits might work. I'll have to run a few tests to see what happens to the route savings if I filter on APINC RIR+1 bit, RIR+2 bits, etc. The worst abusers are the ones to whom their RIR allocations are "collections of class C's" so it may be that there's enough savings at RIR+2 to make that worth using as a compromise. I just filtered you (before seeing your message) as we're now filtering APNIC on "RIR Minimums". The timing of my mail was pure coincidence. I am assuming that unless our immediate Tier 1 upstreams start filtering, we won't see any significant degredation as people start implementing these filters. We don't normally point default anywhere (other than null0), but I knew I'd have to before adding the route filter...so you're still reachable as long as the networks between us aren't filtering. For anyone interested, the filter I'm using is the APNIC section of the ISP-Ingress-In-Strict filter posted to nanog a few months ago, plus around 10 additional deny rules that we'd normally have via an input distribute-list...since IOS doesn't seem to allow both an input distribute-list and input prefix-list on the same BGP peer. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
On Fri, 21 Dec 2007, Greenhalgh, John wrote: For example, we have a /19 allocated from APNIC and announce this from our Hong Kong network. Within that /19 we have assigned a /21 to our Australia site which is discontiguous from Hong Kong. This /21 is announced upstream to two ASes, and being in the 210/7 block would be filtered. We have several discontiguous networks around the world and when these sites started it could not be justified to use a min RIR allocation for the site. That's unfortunate, but your problem doesn't scale. If every network got an RIR allocation, and then subnetted it among several discontiguous POPs and polluted the global route table with those subnets, the routing table would be even worse than what we have today. How much are you willing to pay every other network to carry your deaggregates? What makes your deaggregates special and more worthy of a free ride than any other deaggregating network? With the holiday and new years fast approaching, and our upgrade kits not quite fully assembled (much less tested), I just filtered you (before seeing your message) as we're now filtering APNIC on "RIR Minimums". We were just 2399 routes away from our Sup2s doing bad things. Now we're 20306 routes away...which leaves a much more comfortable margin of safety. Looking forward to seeing your routes early next year...after we've upgraded. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
On Mon, 3 Dec 2007, Andy Davidson wrote: As you nearly point out, it's 100% of the traffic for some networks, and will still be high for other networks. The only way to feel confident that traffic is unaffected by routing table compression is to aggregate sensitively. This is where my "permit one deagg" question came from. What positive effect do you hope to get from allowing one level of deagg beyond RIR minimums? The route table fat that's trimmed away by imposing an RIR minimums filter basically falls into 3 categories. 1) gratuitous deaggs done by networks devoid of clue. They see their CIDRs as collections of "class c's" and announce them largely as such with no covering aggregates. 2) traffic engineering deaggs. One would hope that a network with enough clue to be doing this would announce both the deagg and the covering RIR-assigned CIDR. 3) PA-space multihomers announcing small CIDRs (/24, /23, etc.). I don't see how allowing one additional deagg beyond RIR minimums will help in any of these cases. Case 1 is hopeless. Case 2 doesn't generally need any help. Case 3, unfortunately is unlikely to see much benefit either, because their CIDRs are so small relative to RIR minimums. As someone else suggested (I can't remember if it was in the earlier thread or private email) another filter that might be interesting to "run the numbers on" would be one that instead of using RIR minimums to build the filter, looked at actual RIR assignments. That would obviously be a much larger filter and might pose issues for either CPU load or config size. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Dynamically Changing Exit Policy (iBGP)
On Mon, 29 Oct 2007, Benjamin Howell wrote: On Mon, Oct 29, 2007 at 04:53:50PM -0400, Deepak Jain wrote: You can "nail" down your announcements to external peers by tying their network blocks to a route-of-last resort on one of your loopbacks. This will prevent flapping externally. Point taken, but it's actually difficult to nail down all of our routes. We have some lone /24's that are not subnetted and thus cannot be used with an 'ip route ... null0' statement. When WAN connectivity drops, the routes flap if we don't have a stable iBGP session. Thus I'd like to steer well clear of severing the iBGP session. Not subnetting them doesn't mean you can't ip route a.b.c.d 255.255.255.0 null0 250 while still routing the /24s internally (with lower metric) or having them connected on some interface. Only a single internal /30 route will be removed when an interface goes down. I can't come up with a route-map implementation that would add/remove the weights to the routes already received from our eBGP neighbors. If I'm missing something, please let me know. ... I'd like to dynamically change from best-exit to a "hot potato" exit policy when an internal DS3 fails. We fail over to a much lower bandwidth link and would like to avoid sending anything but internal traffic over that link. If it's not already clear, this change needs to happen automatically. Are you talking about a single internal DS3, or the more general case of "if any of our internal DS3s are down, we need to route differently"? If it's a simple case of two DS3 connected routers which are iBGP peers and also have directly connected eBGP peers, could you use route-maps to set ip next-hop on iBGP exchanged external routes (setting the ip next-hop to be the IP of the other end of the internal DS3, with a second IP of an eBGP neighbor interface)? I haven't tried it, but it seems like it might do what you want. (1) Set a weight on all routes received from the eBGP peer at each location so that it prefers the direct eBGP peer. (2) Sever the iBGP session by tying the iBGP session to an interface IP address rather than a loopback IP. When the DS3 goes down, so will the knowledge of the remote exit point. Another possiblility (I've never tried) would be to configure multiple iBGP sessions...one using loopback IPs, the other using the DS3 interface IPs, exchanging internal routes over both sessions, while exchanging external routes over only the second. If the DS3 goes down, the session exchanging external routes dies. I'm not sure you can do this, but I think by having different peer/endpoint IPs (loopbacks for one session, serial interface IPs for the other), it may work. It may be appropriate to move this thread to the *-nsp list appropriate for your brand of routers. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 240/4
On Fri, 19 Oct 2007, Adrian Chadd wrote: People -chose- to use some new IP space which had once been bogon space and then spent quite a bit of time figuring out why the hell customers couldn't reach the general internet. People adapted. We didn't choose it. ARIN and other RIRs started handing out that space, and if you didn't like it you were welcome to not have any more IP space. There's a huge difference between getting a handful of networks to fix their outdated filters and getting "the internet" to all upgrade their software or replace old non-upgradable gear. You know, Cisco do release updates to old IOS software periodically. ISTR seeing a Cisco 2500 IOS update -this year-. Yup: c2500-is-l.123-23.bin 16 16 25-JUL-2007 Lots of 2500s can't run that code. Where can I get a 240/4 compatible update of c5200-is-l.113-11a.AA.bin? Interestingly, my unpatched Ubuntu 7.04 notebook would let me install routes for networks in 240/4, but would not let me configure an interface IP in 240/4. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Level3 in cleveland/ohio?
On Fri, 19 Oct 2007, Drew Weaver wrote: Anyone else having major difficulty with service with ICG/Level3 circuits in Ohio/Cleveland? We've had a circuit down for 10 hours and just two hours ago they notified us that they're having a major outage in our region and have not provided __any__ further information. When did your outage start? Perhaps last night was a big migration^Wbreak the network night for Level3. We had a Progress Telecom^W^WLevel3 DS3 break at about 4:20AM and not get fixed until about 4:30PM today. I don't have a good explanation yet as to why they broke our circuit or more importantly, why it took them >12h to put it back in service. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 240/4
On Thu, 18 Oct 2007, Stephen Wilcox wrote: You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4. step awy from the crack pipe... I almost wrote a message similar to Joe's (actually did, and then canceled it). I think (realy hope) that there's a misunderstanding here about exactly what 240/4 space would be used for. I think Michael's point is that it can be allocated as "unique space for internal use". i.e. kind of like 1918 space, but you know your slice of 240/4 is only used on your network[1]. For that purpose, it's fine, as long as you determine that all your gear allows it. If anyone really thinks it can be announced into the global routing table and expected to function, I'm afraid they've swallowed the crack pipe so far down that this thread is pointless for them. Too many devices will never (can never[2]) be upgraded and are unlikely to go away in the forseeable future. You just can't expect 240/4 (regardless of how trivial the code change would be) to ever work as globally & reliably as people expect the internet to work. I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided. 1) As much as this can ever be known...you can't stop random IP squatters from picking random IP space out of their hats for use as "private" networks behind NAT. Eventually, they realize some bit of the internet is unreachable...because it's their LAN. The various squatters using 1/8 and the other "not-yet-allocated" /8s will all get the rude awakenings they deserve in time. 2) Anyone care to guess how much network gear is deployed that either won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or flash to handle a newer code train...the old one in use long since unsupported, or gear from vendors that no longer exist? As long as this stuff generally works, nobody's likely to replace it. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, Justin M. Streiner wrote: As far as allowing prefixes longer than a /24, that decision was made when the Internet was considerably smaller than it is now, and many networks adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Anything longer than /24 is unlikely to propogate far on the internet. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. Rather than ISPs relaxing filters, you're likely to see them get more strict, filtering shorter prefixes, when routers start falling over in the next few months. Many networks see customers multi-homing as pretty easy justification to provide them with a /24 of PA space, even if they're small enough that justifying a /24 while single-homed wouldn't work. This is actually in the ARIN "rules". Multihoming is justification (regardless of utilization) for one of the multihomed network's providers to assign them a /24. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Creating demand for IPv6
On Tue, 2 Oct 2007, Stephen Sprunk wrote: I don't know the status of the v6 initial assignment fee; I think that the v6 initial allocation fee was waived at one point. If they're not waived now, that'd be a one-time cost of $1250. I'm pretty sure it's still being waived (at least for ISP/LIRs). I just applied for and received Atlantic.net's v6 /32 without paying any fees in advance. IIRC, with IPv4 initial allocations, you have to pay in advance. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Route table growth and hardware limits...talk to the filter
On Mon, 10 Sep 2007, Stephen Sprunk wrote: Sucks to be them. If they do not have enough PA space to meet the RIR minima, the community has decided they're not "worthy" of a slot in the DFZ by denying them PI space. Not true, there is an ARIN policy that allows you to get a /24 from one of your providers even if you only need 1 IP address: If the PA /24 is under 199/8 or 204-207/8, then the filters being discussed would allow their advertisement through, because ARIN's minimum allocation for those blocks is /24. In ARIN's 22 other /8s, the filters would not because the minimum is /20 (or /22, for 208/8). As long as enough NSPs don't filter on RIR minimums, there's still a pretty good chance that when a small PA multihomer's IP space provider's connection is down, traffic routed towards that provider will get rerouted to their other provider(s). Breaking PA /24 multihoming would be unfortunate collateral damage. Perhaps someone could use the data from the cidr-report and RIRs to create a precision targeted prefix-list intended just to block unnecessary more specifics rather than across the board on RIR minimums? You could even do two different versions. A loose version that just throws out covered subnets with same as-path and a BOFH version that throws out all apparently gratuitous subnetting smaller than RIR minimums, but not all smaller than RIR minimum routes. I just wonder how huge the list would be and what the CPU and config size damage would be. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: An informal survey... round II
On Thu, 30 Aug 2007, William Herrin wrote: Why should we announce tiny recycled blocks? If there is a /16 in the swamp in which half the space is free but its all /24's, why wouldn't wouldn't we allocate all the free /24's to a single entity and instruct the entity to announce it as a "holey" /16? The existing /24 holders will override (punch holes in) the /16 for their /24's. Except when there are /24-holder outages, at which point their traffic gets hijacked by the /16 announcer. Would you want to trust some random company to not take advantage of that situation in any way (collection of passwords, sampling your web traffic, putting up a fake "your org" web site, etc.)? As a holey /16 announcer, would you want all the junk traffic that results from /24-holder outages? What if one of them was running NS's for a popular DNSBL, and their outage basically caused a DDoS attack against your network? ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Mon, 27 Aug 2007, David Conrad wrote: For a few more months. What are upgrade cycles like again? How common are the MSFC2s? I think we'll find out in a few months, when the "internet breaks" in a whole bunch of places where the admins aren't aware of this issue or operations have been downsized to the point that things are mostly on auto-pilot. I'm guessing there are a good number of Sup2's in use, and that a good % of them think they're fine...as they have 512MB RAM and on the software based routers, that's plenty for current full BGP routes. Anyone want to bet there will be people posting to nanog and cisco-nsp in a few months asking why either the CPU load on their Sup2's has suddenly shot up or why they keep noticing parts of the internet have gone unreachable?...oblivious to this thread. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch... And the 7600 is a router? :) I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... And tagged with some white paint. Though if you've kept up with the latest IOS developments, cisco is finally differentiating the platforms we've assumed for years were only different in angle and paint. 6500's won't get to run the newest 7600 code. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Mon, 27 Aug 2007, John A. Kilpatrick wrote: 1. Cisco is still selling the 7600 with the Sup32 bundle (which is what we bought) and saying you can take a full route table on it. I could already do MPLS and IPv6 on this box. This is pretty new hardware. Where are they saying that? The Sup32 sounded great until it became clear that it came with PFC3B (not 3BXL), and that there was no upgrade path to 3BXL. If it was/is being sold as a BGP routing solution, it was awfully short sighted. 2. The only thing I could buy is the top of the line Sup720 3BXL. Ok, fine, but I don't need mega-super-d00per backplane speed. I just need more TCAM like Christoper Walken needs more cowbell. Cisco needs to have a We're in the same boat. According to show catalyst6000, our Sup2's are doing just fine. If there were a Sup32-3BXL, it'd be more than sufficient for our needs. If I end up upgrading because of this it will probably be a forklift upgrade to another platform. And there's no guarantee that it would be a Cisco one. I guess cisco wants to play chicken with us and Juniper. Will you really do the forklift, or just bite the bullet and go Sup720-3BXL? I think they're better on the latter and counting on a bunch of hardware sales in the coming months. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: On Mon, 27 Aug 2007, John A. Kilpatrick wrote: a reasonable solution to this problem - especially if they want to keep selling the 7600 as a router. and here I always looked at the 6500 as a switch... And the 7600 is a router? :) -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Mon, 27 Aug 2007, David Conrad wrote: Any reasonably valid way of predicting when we'll hit 244,000 routes in the default-free zone? Um? Real Soon Now? ... I must be missing something obvious (or should I be dusting off my unused Y2K survival gear?) Unlike Y2K, the end of the useful service life up the Sup2 can easily be pushed further away in time. ASnum NetsNow NetsAggrNetGain % GainDescription Table 233651151129 82522 35.3% All ASes AS4134 1337 339 998 74.6% CHINANET-BACKBONE No.31,Jin-rong Street AS18566 1020 101 919 90.1% COVAD - Covad Communications Co. AS4323 1315 437 878 66.8% TWTC - Time Warner Telecom, Inc. AS4755 1331 507 824 61.9% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System There's really only 151129 routes you need to have "full routes". Forcing just these top 4 slobs to aggregate reduces your global table by 3619 routes. Forcing the top 30 to aggregate frees up 15809 routes. Of course there are other reasons to upgrade (better CPU, MPLS, IPv6, etc.), but if you can't upgrade, there are alternatives to stretch the old hardware. It's not like it hasn't been done before. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: "2M today, 10M with no change in technology"? An informal survey.
On Mon, 27 Aug 2007, Eric Gauthier wrote: Do we have a real date for when this occurs? If you aren't doing uRPF, I thought they ran up to 256,000 routes. (I may not recall correctly) We ran into this hiccup a few months ago on a Sup720-3B (well, a 3BXL which mistakenly had a 3B card in the chassis, causing the SUP to clock down and act like a 3B), but I think the Sup2's are in a similar situtation. Though the box can handle up to 224k routes, they are set by default to only handle 192k IPv4 + MPLS routes plus 32k IPv6 + IP multicast routes. You can retune this so that you can get up to 224k IPv4 routes, but I've recently seen our Internet table bumping against this. My understanding is that this is a hardware limit, so upgrading is your only option. The sup2 can actually handle a bit more ipv4 routes than the Sup720(non-3bxl). I don't know if it can go all the way to 256k routes. I can't seem to find any cisco data sheets that specify max ipv4 routes on the sup2. The output from show mls cef hardware suggests 256k is the limit. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Gwd: crypted document
On Thu, 2 Aug 2007, Hex Star wrote: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P If you could read the header, the question you would have asked is, "What is Chris Adams doing in Korea sending virus mail to nanog?" :) It's a shame there's no test before people subscribe. For the humor impaired, obviously, some PC in Korea is infected with the latest virus and has both Chris's and the nanog list's addresses handy. I wasn't kidding about the test thing though :) ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Network Level Content Blocking (UK)
On Thu, 7 Jun 2007, James Blessing wrote: Sorry for the cross posting to a number of lists but this is an important topic for many of you (especially if you get multiple copies). As many people are aware there is an 'expectation' that 'consumer' broadband providers introduce network level content blocking for specified content on the IWF list before the end of 07. There are no British colonies in North America...are there? Or are the red coats coming again? ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: ISP CALEA compliance
On Thu, 10 May 2007, William Allen Simpson wrote: Follow the usual best practices, and you may save time and money. 1. Ensure that your DHCP, RADIUS, SMTP, and other logs are always, ALWAYS, *ALWAYS* rolled over and deleted within 7 days without backup. I'd recommend 3 days, but operational requirements vary. Assuming you're actually serious, how do you deal with customers who dispute usage one or more months ago (when they get their bill)? We keep summarized radius detail for a considerable time, and its not unusual to have to pull up several months worth to quell a customer initiated billing dispute. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: BOGON Announcement question
On Mon, 30 Apr 2007, Jason Lewis wrote: I'm seeing this announced at CIXP Collector: CIXP Prefix: 128.0.0.0/2 Last update time: 2007-04-27 07:36:30Z Peer: 192.65.185.140 Origin: 29222 My question is, why am I not seeing more issues because of the announcement? Is it just not propagating out of the exchange? It's been announced for a few days and only seems to appear at the exchange. It's so 'non-specific', all it's going to catch is traffic for destinations for which there is no route in the global table. i.e. it's likely nobody would notice it (nothing broken) unless looking for it. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SaidCom disconnected by Level 3 (former Telcove property)
On Wed, 14 Mar 2007, Frank Bulk wrote: http://www.phillyburbs.com/pb-dyn/articlePrint.cfm?id=1310151 Is this a normal thing for Level 3 to do, cut off small, responsive providers? Even from that one-sided account, I have serious problems with: Siwert said the Colorado-based Level 3 "cited several Internet abuses" by SaidCom customers as the reason for the shutdown, including spam problems. "Some customers abuse the system", but when that happens, SaidCom contacts the authorities, said Siwert. When we have a customer spamming, we don't call the police. We either talk to, ACL, or shut off the customer. The above suggests to me that SaidCom had spam issues that they were either unable or unwilling to remedy themselves. I also doubt that L3 shut them off without multiple prior warnings, though anything's possible. We had an issue many years ago where a leased line provider (coincidentally borged indirectly into L3) shut off all of our services with no warning at all on a Friday evening. Only after wasting some time with their NOC troubleshooting the circuits were we told we'd been shut off for non-payment. When we eventually got to the bottom of it (many hours later), it turned out they had another customer with a similar name that was way past due...and when billing told their NOC shut off "Atlantic" they shut off everything that looked like "Atlantic" even though we were two totally separate and unrelated customers. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
On Thu, 1 Mar 2007, Chris L. Morrow wrote: The challenge for folks on the far side of this problem (69box.atlantech.net for instance or midco) is finding a way to get this adjusted. 69box.atlantic.net So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours) The cisco auto-secure feature sure showed some fun effects for this too, eh? If by core you mean the "tier 1's" where in theory there are people with enable keeping up with the community mailing lists, then sure, bogon filters there sure beat bogon filters at every enterprise where they 'set it and forget it.' ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
On Thu, 1 Mar 2007, Chris L. Morrow wrote: ah-ha! but seriously, is this something an NSP/ISP should be doing? or is this an enterprise function? or MSSP function? Are there standard tools available to notify folks when changes occur? (aside from: "go check iana.org website" or "golly traffic's not flowing anymore") Such updates get posted to various places like nanog, cisco-nsp, probably other -nsp lists, and such...but for the large number of ASNs not represented at all on those lists, I don't know how they're supposed to "get notified" every time a bogon ceases to be. My own experience with this was that its very diffifcult to find your way to the clue at organizations with such filter issues...and even when you find such breakage, its hard to tell from the outside which end of a connection has the filter issue. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
On Thu, 1 Mar 2007, Chris L. Morrow wrote: So, where are static bogon filters appropriate? (loaded question perhaps) I ask because just about every 'security expert' and 'security whitepaper' or 'security suggestions' has some portion that speaks to "why it's a grand idea to have acl-lines/firewall-policy tp block 'bogon' ip space" (for some definition of 'bogon' of course). I suppose they're appropriate when done by network security consultants, as it guarantees future / repeat business. :) ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 96.2.0.0/16 Bogons
On Wed, 28 Feb 2007, Eric Ortega wrote: I'd like to thank the group for the responses and help with this issue. I find it ironic that Randy's study actually uses 96 space. The amazing/sad thing is that people have been facing and fixing the same problem for more than 4 years. How many times does a network have to fix their static bogon filters before coming to the realization that those filters are a bad idea? For my "solution" to the problem, see http://69box.atlantic.net/ It's also http://not69box.atlantic.net/ for the 69/8 challenged. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: what the heck do i do now?
On Tue, 6 Feb 2007, Stephane Bortzmeyer wrote: On Mon, Feb 05, 2007 at 10:13:08PM -0500, Jon Lewis <[EMAIL PROTECTED]> wrote a message of 52 lines which said: 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. That /24 doesn't show up in BGP Somebody clipped the "unless something is broken" part of that statement. It SHOULD NOT show up, but it does (ROSPRINT-AS, AS2854, does announce it and, among others, routeviews.org sees it). So the simple conclusion is ROSPRINT-AS is broken. BTW, that route doesn't seem to propogate very far. I don't see it via Level3, Above.net, or TWTC. What I do see when looking at my incoming distribute list is that someone seems to keep trying to announce exactly 192/8. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: what the heck do i do now?
On Mon, 5 Feb 2007, Jeremy Chadwick wrote: u1.vix.com. 604800 IN A 192.0.2.1 u2.vix.com. 604800 IN A 192.0.2.2 u3.vix.com. 604800 IN A 192.0.2.3 ... [as many as you like] i hadn't thought of that. i'll think seriously about it, thanks. The caveats to this are: 1) DNS servers which are not configured to blackhole IANA-reserved network blocks (read: the majority) will blindly try to reach 192.0.0.0/17 and friends. Huh? 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. That /24 doesn't show up in BGP unless something is broken or you have a cymru bogon feed. Either way, worst case is you're default routing to an ISP/NSP and the packets get a few hops before someone drops them as unroutable. 2) Some people (like myself) have ipfw/pf rules which block and log outbound packets to reserved blocks. We log these because usually it's the sign of broken software or possibly some weird IP routing (read: OS IP stack) problem. In the case of ipfw (I haven't tested pf), the block gets reported to underlying layers as EACCES, which can be incredibly confusing for admins. If it means they get noticed, mission accomplished. That's exactly what Paul wants. My vote is to simply remove the NS and A records for maps.vix.com and let people utilise search engines and mailing list archives to figure out where to go (mail-abuse). The vix.com NS's will get slammed with all the DNSBL queries then. The suggestions I made at least get some of the queriers (assuming they have properly functioning caches) off your back for a while. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: what the heck do i do now?
On Mon, 5 Feb 2007, Simon Lyall wrote: On Thu, 1 Feb 2007, Jay Hennigan wrote: Set up a nameserver there. Configure it to return 127.0.0.2 (or whatever the old MAPS reply for "spam" was) to all queries. Let it run for a week. See if anything changes in terms of it getting hammered. Well I've seen some RBLs do this with about 2 days notice. Perhaps a special value could be defined ( 127.255.255.255 ? ) to tell users that the DNSBL is no longer in operation and shouldn't be used, standard software can then raise an error or whatever. That doesn't help get the old/unwatched installations to stop sending queries. It's been established that regardless of what you return, those installations will continue querying the dead BL. That's why I think your best/only option is to attempt to misdirect them by pointing NS at . or unreachable space...effectively giving them someplace harmless to send their queries or to fail them without even having to send them. Killing the parent domain is an option too, but that only pushes the problem onto someone else's plate (the TLD servers). ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: what the heck do i do now?
On Thu, 1 Feb 2007, Paul Vixie wrote: 1) maps.vix.com.604800 IN NS . i've tried that. the retry rate actually goes up rather than down. That's pretty messed up. I've tested both the strategies I suggested, and at least with both bind9 and DJB's dnscache, the caching name server will cache the NS, and in this (.) case, it won't ask the auth server(s) again for any subsequent queries in the former DNSBL zone (until the data expires from the cache). You must be getting hit by some seriously broken DNS caches. I don't have them handy to test, but I wonder what bind8 and bind4 do? After all, the sorts of people who setup servers to use a DNSBL 8 years ago and forgot about it, are the sorts who might still be running really old DNS server software. 2) maps.vix.com.604800 IN NS u1.vix.com. maps.vix.com. 604800 IN NS u2.vix.com. maps.vix.com. 604800 IN NS u3.vix.com. ... [as many as you like] u1.vix.com. 604800 IN A 192.0.2.1 u2.vix.com. 604800 IN A 192.0.2.2 u3.vix.com. 604800 IN A 192.0.2.3 ... [as many as you like] i hadn't thought of that. i'll think seriously about it, thanks. I prefer this method since it's non-destructive, but much more likely to be noticed than the immediate failure the queriers get with the . method. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: what the heck do i do now?
On Thu, 1 Feb 2007, Justin Shore wrote: Jon Lewis wrote: 2) maps.vix.com.604800INNSu1.vix.com. maps.vix.com.604800INNSu2.vix.com. maps.vix.com.604800INNSu3.vix.com. ... [as many as you like] u1.vix.com.604800INA192.0.2.1 u2.vix.com.604800INA192.0.2.2 u3.vix.com.604800INA192.0.2.3 ... [as many as you like] 1) just tells them there is no NS, go away. 2) gives them someone unreachable to try, which they'll do, and do, and do, wasting lots of retransmitted queries and the time it takes them to timeout. If you're lucky, the timeouts might be noticed as increased load and mail slowdown on the servers sending these queries. Or you could just point them at a spammer's DNS. That's what the query is all about anyhow. Just let the spammer give the appropriate response. Wouldn't that be fun? I wonder how beefy Linhardt's NSs are Yeah, that'd be barrels of fun when the spammer sues you for orchestrating a DDoS against them in the form of bogus DNS queries. Next. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
WTH does Paul do now?
Why do I even bother? -- Forwarded message -- Date: Wed, 31 Jan 2007 23:08:22 -0500 From: Mail Delivery Subsystem <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Returned mail: see transcript for details The original message was received at Wed, 31 Jan 2007 23:08:18 -0500 from localhost.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> (reason: 553 5.7.1 Service unavailable; Client host [69.28.69.2] blocked using reject-all.vix.com; reason / created) - Transcript of session follows - ... while talking to sa.vix.com.: RCPT To:<[EMAIL PROTECTED]> <<< 553 5.7.1 Service unavailable; Client host [69.28.69.2] blocked using reject-all.vix.com; reason / created 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
Re: what the heck do i do now?
On Thu, 1 Feb 2007, Paul Vixie wrote: One thing you might consider is putting together a script to harvest email addresses from whois records that correspond to the PTR for the querying IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the poorly run domain. Then fire off a message explaining the situation and that you'll be adding a wildcard record on such and such date (preferably not 4/1). Script all of this and run it every couple of days until the date you gave and then follow through with the wildcard entry. This undoubtedly won't stop all of the whining but you can at least say you tried. volunteers are welcome to apply for that job. It's actually a trivial thing to do. Start with something like the geektools whois proxy. That'll handle getting the queries to the right RIR's whois server. Then all you need to do is parse the output for email addresses. For extra credit, you can look for common "abuse" addresses in the output and ignore other addresses in outputs where an "abuse" address is found. As for trying to "make it stop", the two methods thought to be most successful are: 1) maps.vix.com.604800 IN NS . 2) maps.vix.com.604800 IN NS u1.vix.com. maps.vix.com.604800 IN NS u2.vix.com. maps.vix.com.604800 IN NS u3.vix.com. ... [as many as you like] u1.vix.com. 604800 IN A 192.0.2.1 u2.vix.com. 604800 IN A 192.0.2.2 u3.vix.com. 604800 IN A 192.0.2.3 ... [as many as you like] 1) just tells them there is no NS, go away. 2) gives them someone unreachable to try, which they'll do, and do, and do, wasting lots of retransmitted queries and the time it takes them to timeout. If you're lucky, the timeouts might be noticed as increased load and mail slowdown on the servers sending these queries. Either way, a properly functioning caching DNS should leave you alone for a while after caching the fact that there (is no NS for maps.vix.com||the NS's for maps.vix.com are unreachable/unresponsive). i.e. Either of these should mitigate the traffic far better than simply returning NXDOMAIN for every maps.vix.com dnsbl query. Successful here doesn't necessarily mean "the traffic stopped" but rather the traffic has been mitigated as much as is possible without actually getting people to fix their systems and stop querying the dead zone. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: who was the last legit spammer?
On Sun, 28 Jan 2007, Travis H. wrote: Hey, was discussing something from the long distant past recently. Specifically it was my memory of the last legitimate spamhaus, and how (IIRC) their backbone was DDoS'd as an act of pseudo-vigilante justice. I also seem to remember their backbone as spinning it as a content-neutral free-speech kind of thing, but they buckled and the Internet was probably better off. "Legit spammer"? Perhaps you're thinking of Sanford Wallace's cyberpromo and AGIS? http://www.cctec.com/maillists/nanog/historical/9710/msg00018.html ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [cacti-announce] Cacti 0.8.6j Released (fwd)
On Mon, 22 Jan 2007, Jason LeBlanc wrote: Anyone thats seen MRTG (simple, static) on a large network realizes that decoupling the graphing from the polling is necessary. The disk i/o is brutal. Cacti has a slick interface, but also doesn't scale all that well for large networks. I prefer RTG, though I haven't seen a nice interface for it, yet. How large did you have to get for cacti to "not scale"? Did you try the cactid poller [which is much faster than the standard poller]? ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)
On Thu, 18 Jan 2007, Jeremy Chadwick wrote: For those who don't have the time/care enough to go look at the Secunia report, I'll summarise it: 1) cmd.php and copy_cacti_user.php both blindly pass arguments passed in the URL to system(). This, IMHO, is reason enough to not run this software. I've said this several times recently in less public places, but IMO, cacti is a bit of a security train wreck. The glaring problem isn't that the above mentioned php scripts have poor security / user supplied input sanitization. It's that those scripts were never intended to be run via the web server. So WTF are they doing in a directory served by the web server in a default cacti install? It seems to me, it would make much more sense for cacti to either split itself into 2 totally separate directories, one for things the web server needs to serve, one for everything else, or at least put all the 'web content' portions under one subdirectory of the cacti install directory, so that subdirectory can be either the DocumentRoot of a server or symlinked from elsewhere in a DocumentRoot. There's no reason for things like poller.php or any of the others that are only meant to be run by the admin from the commandline to be in directories served by the web server. I've heard from several people, and spent some time trying to help one of them, who had servers compromised (entry via cacti, then a local root compromise) over the past weekend due to this. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: http://cisco.com 403 Forbidden
On Wed, 3 Jan 2007, James Baldwin wrote: Anyone else getting a 403 Forbidden when trying to access http://cisco.com? Forbidden You don't have permission to access / on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0 Server at www.cisco.com Port 80 I think someone's going to get in big trouble. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Bogon Filter - Please check for 77/8 78/8 79/8
On Mon, 11 Dec 2006, Robert E. Seastrom wrote: no, he's saying that a lawsuit is a useful method of forcing someone who is intentionally or negligently distributing incorrect information that other people who do not know any better then believe and use in their own networks. i betcha libel laws aren't written in such a way that they are useful here, however, there might be some kind of restraint of trade thing that could be invoked or somesuch. ianal, not my dept. If you google for it, you'll find lots of obsolete bogon info, typically lacking the suggestion to check IANA's web site or other resources to check the freshness of the data or any warning that the data will change over time as more space gets allocated. From the first page of google: bogon ACL cisco http://www.tech-recipes.com/modules.php?name=Forums&file=viewtopic&p=6817 Do you threaten to sue them all? The real problems are all the networks that setup static bogon filters some time ago which nobody maintains or in some cases, even knows about. Changing a few web sites won't fix any of those routers. It's a lousy position to be in, but my suggestion is try to make contact with the bigger / more important networks blocking your new space and let the rest of them figure it out on their own. I'm surprised William's site hasn't been updated. He used to be fairly active online. Has anyone heard from him at all recently? ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 200K prefixes - Weekly Routing Table Report
On Thu, 12 Oct 2006, [UTF-8] Neil J. McRae wrote: I'm buying more stock in ram producers RAM's cheap. Buy stock in cisco and/or juniper. forklift router upgrades are not so cheap. A whole lot of NPE/RSP/SUP boards will be unsuitable for core router use (without route filtering) in the next year or two. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: ARIN sucks?
On Sun, 17 Sep 2006, Hank Nussbacher wrote: Also, you're incorrect on the process. You can definitely get an ASN without IP space. I find that fascinating. The ARIN template: http://www.arin.net/registration/templates/asn-request.txt states: 12. Indicate all IP address blocks currently in use in your network. You fill in "none" and ARIN has given you an ASN? Under what conditions? If you have no IP space in use, what do you plan to do with an ASN? It is pretty common to get an ASN from ARIN while using PA IP space, never getting (or requesting) space from ARIN or other RIRs. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: ARIN sucks? was Re: Kremen's Buddy?
On Thu, 14 Sep 2006, Lasher, Donn wrote: approved on the first try. I personally have a 0% success rate, and I spent a year or two in college I assume you mean 0% success on first submission of the template. My experience has usually been that I don't give them quite enough detail on the first try. They say "fill in some more detail here and here." The hardest part for me has always been forecasting expected future need. Our business changes frequently, and I never know what our expected usage will be...at least not with any certainty. Last time, we were about to roll our DLSAMs in a bunch of COs. The FCC pulled the UNE rug out from under us right as we were beginning deployment, and we canceled that idea. With RWHOIS your IP usage data is internal, easily searchable, modifyable without going through email ping-pong with ARIN. We (at a Are you aware of the use of ">" in [ARIN] whois queries? With that, it's trivial (though time consuming) to get a list of all your SWIPs, and then have someone verify that everything that should be SWIPed is, and any stale ones are undone. I don't agree with the idea that you should only request and receive 3 months worth of IPs at a time, and I wonder how commonly anyone does that in practice...but this is the wrong list for that debate. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Fri, 8 Sep 2006 [EMAIL PROTECTED] wrote: Since IP addresses are basically available free from any ISP who sells Internet access services, this seems In small quantities, and which tie you to particular providers. Shells of companies have been bought (or just claimed) for their large, especially pre-ARIN, PI-IP assignments. To a young ISP, a /16 for example may seem like a lifetime supply of IP space, and save the company many thousands of dollars (ARIN registration fees) and paperwork hassles. News of this case has been sent here before (by [EMAIL PROTECTED] back in July). Is anything really happening with the case? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Is it my imagination or are countless operations impacted today with mysql meltdowns
On Sun, 27 Aug 2006, Henry Linneweh wrote: I think you are just a rude person and I have been on this list since about 1995 and there is a real problem with the lastest cpanel upgrade with mysql and it took out 1 of my server configurations, that we host peoples businesses on and I wanted to see how many other isp's were affected and what their solutions were in resolving the problem. That to me is operational impact, since it affects customers on multiple networks. So your original post was pure content-free BS, fishing for others to admit (as you only just did) that they'd broken their own MySQL servers by installing a bad 3rd party (cpanel) update. That's not NANOG material. If you'd installed an update on your routers, and they were all freaked out, that might be. If you're having trouble with your hosting software, I suggest inet-access, or in this case, something as application-specific as http://forums.cpanel.net/ might be best. I've never used that site, but it's the first hit if you google: cpanel support forum BTW, I operate several MySQL servers and none of them have anything odd going on this weekend. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Deaggregation Disease
On Fri, 21 Jul 2006 [EMAIL PROTECTED] wrote: The big question is, of course, whether to upgrade a 6500 and keep it on life support, or bite the bullet and go for a whole new box. How much time a -3bxl and careful filtering will buy you does depend heavily on where in the Internet you are - but I'm willing to bet that a good number of sites will go for the fork lift upgrade because there are *other* pressing things coming up that the 6500 won't do either. With a 3bxl, you won't need careful filtering. All the lower Sups top out at or slightly below 256k routes. IIRC, the 3bxl claims to support 1M ipv4 routes. Anyone else care to guess at how far off 235k routes is? I'll concede that Jon is at least partially right - *somebody* is going to be selling gear... ;) Yeah...I posted recently on cisco-nsp that I think cisco's making a huge mistake not producing a Sup32-3bxl. When the Sup2 can't cope with "full routes" anymore, I suspect the Sup720-3bxl will already have been obsoleted by some higher end Sup. Then networks that would have bought Sup32-3bxl's for the route capacity, and don't really need the traffic capacity of the Sup720-3bxl will snap up Sup720-3bxl (and the required fan2s and power supplies) off the used market while bigger/richer networks upgrade to the Sup720-3bxl replacement. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Deaggregation Disease
On Fri, 21 Jul 2006, Fergie wrote: It's not, people are just lazy and since "nobody owns the internet man", or maybe "it's all a bunch of tubes" there's nobody to force people to be good actors. Perhaps it's time to bring back the old /19 filters that were started by sprint & such. I was just thinking the same thing. :-) As we push closer to the ipv4 route table limits of cisco's 6500/7600 series (with anything less than Sup720-3bxl), I suspect lots of networks are going to be forced to start doing some sort of filtering of routes beyond just refusing >24-bit networks or cisco's going to sell a lot more Sup720-3bxl's, FAN2 trays, and power supplies in the next year or two. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Zebra/linux device production networking? (summary)
On Wed, 7 Jun 2006, Nick Burke wrote: What about better case situations?* IE: toe cards custom kernel no moving parts (ie: hard drive, maybe fans if possible) up-to-date software packages with internal coders to fix ugly bugs, etc actual research into what packages & hardware would be best I didn't notice anyone mention Imagestream, who sell Linux based routers using a custom distro and no moving parts other than fans. Storage is flash. I've helped a client manage several of them for several years. IMO, they're not bad as CPE, but I don't think we could use them if we wanted to on most of our network. Some of the features we need just aren't available. As others have mentioned, I wouldn't recommend it unless you have some people very comfortable with Linux and IP routing on Linux on staff. At one point, they had 4 full BGP feeds going into one Imagestream Gateway router, which is a P4, upgraded to 512MB RAM. With 2 full views now, they have 308MB free. It's an older installation, predating the addition of zebra/quagga to their distro, so it's still running gated_public, which works, but is fairly lacking in BGP knobs. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Fwd: 41/8 announcement
On Sat, 27 May 2006, [EMAIL PROTECTED] wrote: How was that achieved if their users still are within 41/8 >locally? Route filter and PBR. I don't think so. If you're an end user assigned the "private version of" 41.0.0.1, how do you reach a web site on the real 41.0.0.1?...short of crazy DNS translation and NAT tricks...and that assumes everything uses names rather than IPs. Just renumbering into 1918 space would be much simpler. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Tools for LARTing large nets of compromised boxen?
On Thu, 20 Apr 2006, Michael Loftis wrote: One of our customers is (has been) under concerted attempt at a DDoS attack against their web server off and on for a while. I've lists of IPs, lots of them, many hundreds. I'd like to know if anyone has a tool that will take and match these lists of IPs into abuse contacts and fire off a LART to the appropriate RP for the IP, but only one per full set, IE if RP-A has IP A.B.C.D and A.B.C.C he should get one mail clue-batting him for both IPs. It's not an actual tool for doing the whole job, but you could use "bulk mode" on whois.cymru.com to turn your list of IPs [and timestamps?] into a a list of "AS | IP | Timestamp | AS Name". Send a help request to the whois.cymru.com whois server for instructions. Once you have that, you could pretty easily split it by AS#, grab email addresses from whois records for the AS#'s, and email each AS#'s data to their ASN POCs. You could also post a URL to the full output from your cymru whois here, and someone would likely forward the data to nsp-sec. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Determine difference between 2 BGP feeds
On Tue, 18 Apr 2006, Scott Tuc Ellentuch at T-B-O-H wrote: Is there a utility that I can use that will pull the routes off each router (Foundry preferred), and then compare them as best it can to see why there is such a difference? I can understand a handful of routes over what CIDR says, but a minimum of 3K more? Is one of them as4323? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: AT&T: 15 Mbps Internet connections "irrelevant"
On Sat, 1 Apr 2006, Marshall Eubanks wrote: If AT&T is really claiming that their backbone has less than 15 Mbps capacity (which is how "the backbone doesn't transport at those speeds" reads in plain English), this is either Maybe they meant that the typical end-user windows IP stack has small enough TCP windows that when you take into account typical latency across the internet, those users just can't utilize their high bandwidth links due to the bandwidth * delay product. - an April Fools joke or - pitiful. Could be either. Did you happen to catch the woman from Verizon at the last NANOG who was sure parts of New Orleans were 2 miles below sea level? Maybe that was a really early AFJ. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Have Yahoo! gone pink?
On Wed, 29 Mar 2006 [EMAIL PROTECTED] wrote: Received: from EXCHG01-DUB.Europe.Search.Corpsys.P4pnet.net (cluster01-dub.europe.search.corpsys.p4pnet.net [172.30.132.19]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2FIupeH049008; Wed, 15 Mar 2006 10:56:52 -0800 (PST) Hey, what do you know... if you trust both uksolutions.net and yahoo.com's Received: lines, it didn't originate at Yahoo - it came from p4pnet.net. ;) (A fine demonstration of the difference between being truthful and being helpful :) Only problem with that is 172.30.132.19 is part of NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName:IANA-BBLK-RESERVED So even if you did trust that Received line, it still had to come from inside yahoo.com (unless someone briefly announced some of 172.16.0.0/12 and yahoo both accepted the route and relayed for it). AFAIK, from other lists, Yahoo is aware of this screwup (disclaiming responsibility for 216.145.48.0/20) and is working on it. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: com/net Whois format change notice
On Fri, 24 Mar 2006, Matt Larson wrote: On March 30, VeriSign will upgrade its Whois service for .com and .net, which will now reflect registration activity in the .com and .net registry databases in near real-time. We are announcing this upgrade because the Whois output format will change slightly at the same time and we want to give notice to anyone who may have to update processes that parse this output. Slightly? A sample of the revised output is included at the end of this message. Domain Name: VERISIGN.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS1.CRSNIC.NET Name Server: GOLDENGATE-W2-INF6.VERISIGN.NET Name Server: BAY-W1-INF5.VERISIGN.NET Status: REGISTRAR-LOCK EPP Status: clientDeleteProhibited EPP Status: clientUpdateProhibited EPP Status: clientTransferProhibited Updated Date: 19-Nov-2004 Creation Date: 02-Jun-1995 Expiration Date: 01-Jun-2012 No more Registrant, POCs, or physical address information? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Network graphics tools
On Tue, 21 Mar 2006, Howard C. Berkowitz wrote: Much of the enterprise market seems wedded to Visio as their network graphics tool, which locks them into Windows. Personally, I hate both little pictures of equipment and Cisco hockey-puck icons; I much prefer things like rectangles saying "7507 STL-1" or "M160 NYC-3". ^ That's exactly what my network diagrams in dia look like. You can get dia for *NIX and Blows (if you want it). ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DNS TTL adherence
On Wed, 15 Mar 2006, Simon Waters wrote: This behavior is unfortunately not unique. Alas what others peoples servers do, shouldn't be an issue for you. Your problem is they can be coerced into a DoS attack, not that the data is stale. Tell that to a customer when you've moved some resource of theirs to a different IP...having been careful to decrease the TTL well in advance. Some parts of the internet are simply broken and beyond your control. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DNS deluge for x.p.ctrc.cc
On Sat, 25 Feb 2006, Rob Thomas wrote: As many say, you own your network, and are free to run it as you see fit. :) That said, please be aware that if you leave your name servers open to recursive query requests from any source, you WILL unwittingly help to amplify these attacks. It's the same as ICMP directed broadcast and the like. This has been an issue for years. Before the DDoSers started using open recursive DNS servers as a modern way to "smurf", spammers were abusing them by registering a domain, setting up DNS, loading the data into open recursive servers (by sending them queries), and then pointing the domains at those recursive servers...getting free DNS service and misdirecting complaints. The argument that DNS servers have always been open to recursion (so we shouldn't change it) sounds a lot like the open SMTP relay issue 5-10 years ago. It took years, but all but a few wingnuts seem to have finally caught on to the idea that open SMTP relays are a bad idea...enough so that spammers had to move on and adapt to open proxies, and then to botted systems / trojan proxies. Besides, don't the DNS specs dictate that a proper DNS resolver will try again with TCP if the server tells it the UDP reply was truncated? ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DNS deluge for x.p.ctrc.cc
On Fri, 24 Feb 2006, Chris Adams wrote: One thing to note: we've discovered that on some common DSL routers, the internal DNS caching server is on by default and answers requests on the outside IP address. IIRC some even do it when configured for NAT. So, even when you disable outside recursion, things you may not think of on the inside of your network may still allow outside DNS recursion. Efficient Networks DSL routers suffer from this problem if DNS servers are defined in the DHCP server config on the router. It's more of a DNS proxy though. It doesn't do any caching. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: MLPPP over MPLS
On Fri, 17 Feb 2006, Jon R. Kibler wrote: We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed. It's not clear from your message, but I'm assuming the MLPPP will be from PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case, on the customer end, it's just a MLPPP, and on your end, it's an MLPPP with an "ip vrf forwarding foo" statement. It's probably more than the average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS config work). Anyone who actually uses IOS on a regular basis (as opposed to someone who crammed for an exam and knows squat) should have no trouble with it. The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration. I think someone may be confusing "providing MPLS service" with "buying MPLS service". A customer buying MPLS VPN service never sees any of the MPLS tags or messes with MPLS/tag-switching commands. There is no added complexity...or at least there doesn't need to be any. == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. Virus-free, because I say it is...and I run Pine on Linux :) -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: AT&T (AS7018) customer triggered blackhole routing?
On Wed, 8 Feb 2006, A Satisfied Mind wrote: Does anyone know if AT&T (the old one, AS7018) has customer trigged blackhole routing? I looked in the copy of the BGP policy I have from 04/2005, and see nothing about it, and cannot find the updated online version. I really doubt it. Last time I talked to a couple of AT&T sales engineers, they didn't even support selective prepending based on communities. It actually took a while to find one the concept could be explained to. BTW... http://www.nanog.org/aup.html Acceptable Use Policy ... 7. Postings to the list must be made using real, identifiable names and addresses, rather than aliases. A Satisfied Mind <[EMAIL PROTECTED]> doesn't appear to qualify. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
TWTC as4323 full routes
Has anyone else with a transit connection to Time Warner Telecom noticed TWTC on and off over the past few days advertising an extra 2500 or so routes? Right now, I've got 180169 routes from 4323...and 176-177K from other transits. I noticed them setting off my BGP-4-MAXPFX warning :( ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: On the inoc-dba subject
On Mon, 6 Feb 2006, Joe Maimon wrote: pch.net publishes a SPF record: "v=spf1 ip4:204.61.210.70/32 mx mx:woodynet.net a:sprockets.gibbard.org a:ghosthacked.net ~all" Besides going from soft-fail (~all) to fail (-all), they are already giving you the tools you need to validate a MAIL FROM: claim. Thats all very well and good, but advising people who do not validate with spf to whitelist by domain name is an over-simplification. So call it additional clue-boundary to entry and be done with this silly thread. Besides, the site doesn't specify how to filter/whitelist...just to make sure you can accept mail from pch.net. A simple person might take that to mean "I better allow any @pch.net from address" but that's not what the site says. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Anyone heard of INOC-DBA?
On Fri, 3 Feb 2006, Aaron Glenn wrote: On 2/3/06, Sean Donelan <[EMAIL PROTECTED]> wrote: How about INOC-DBA, which is supposed to have a clue threshold you obtained an ASN by some means in order to have a dial-by-asn phone. Obtaining an ASN isn't much of a clue threshold. No...and sometimes its done on some customer's behalf...but there's still some clue threshold involved in getting setup with INOC-DBA. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 74/8 75/8 76/8
On Wed, 1 Feb 2006, Martin Hannigan wrote: 74.63.0.0/20 75.127.0.0/20 76.191.0.0/20 ...should be withdrawn now. Why? Allocation out of 74/8 happened on 12/20/2005 and 76/8 1/19/2006. So? Operationally, the testing should stop prior to allocations from the block, regardless of size. I think it's a binary question, they're either in production or not, and if they are, there should be no intrusive testing. Why should the testing stop (and what sort of testing did Cymru do?)? From my experience with 69/8 space (69box.atlantic.net), I can tell you, networks with outdated bogon filters will always exist. If Cymru is providing or can provide a tool for people to use to test/verify that certain networks have such filters affecting the above blocks, then it's still a useful service. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: MPLS vs PTP
On Mon, 30 Jan 2006, Andrew Staples wrote: As we roll out a new network, on one of our links it is remarkably cheaper to run a T1 ptp vs. MPLS (running 66% data, 33% voice). Based on comments received from this list (much thanks, you know who you are) MPLS satisfaction seems to be determined by backbone noc competence, not the technology itself. So back to priceif I consider layer1 issues to be equal in either scenario, and aggregation/meshing/hardware is not a real concern, it seems to me that a correctly configured, directly connected pipe would work as well as mpls, with the benefit of local control of my routers and owning any incompetence. Also, the PTP T1 has fewer hops (probably lower latency), fewer points of failure, fewer ways to break, less complexity, etc. I can't think of any reason you'd want to go with an MPLS(VPN) solution over PTP solution if startup and MRC were equal. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Router upgrade for small colo provider
On Wed, 25 Jan 2006, Andrew - Supernews wrote: I have some of these running with combinations ranging from 5 full-routes sessions + iBGP through to 2 full + iBGP + 70+ peers. You don't need to be nervous about the MSFC2's ability to do BGP (though for serious work you do want the maximum memory in both the MSFC2 _and_ the Sup2 (512M and 256M respectively) - the 256M on the Sup2 is _important_ if you're going to have full routes). It's actually 512M on both. With later/bigger IOS versions, you might actually utilize >256M on the Sup2. Max both out at time of purchase so you don't have to take it down later for upgrades. #remote command switch show mem HeadTotal(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 448543E0 393919520 108659576 285259944 273392008 211623448 I/O80067108880103533285672567256755512 That's from a WS-X6K-SUP2-2GE. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: PI space and colocation
On Wed, 18 Jan 2006, Patrick W. Gilmore wrote: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? I don't know about "most", but every one I've asked has done it. We'd do it as long as everything looked legit (i.e. it really seems to be the customer's IP space). Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net. We've done this as well. Whats wrong with letting the customer use their ASN and BGP peering with them in your data center? They might even get a connection to someone else there and multihome again. Either way, the routes are getting into the global table...does the end of the aspath matter that much? ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Destructive botnet originating from California (was Japan)
On Sun, 25 Dec 2005, Barrett G. Lyon wrote: I would have sent out a clean list sorted via AS and IP, except I have been working from vacation on GPRS via my 1 bar of service on my cell phone. What's vacation? I gather Prolexic isn't a one man shop. Nobody else had a better internet connection and a few minutes to tidy up the data and make the post? If the right thing is to post this information to a more private list, then I would do so. However, I think it has been benificial to get this information out to the public where they can actually do something about it. I've been I didn't say nanog wasn't a good place to post the info...or that there aren't better places. Just that if you want people to take action based on the data, present it in a more reader-friendly and meaningful format. Also, mixing IPs and PTRs in such a report is not a great idea. I actually did scan through the message looking for any of my prefix's and $work's primary domain name. If there was a PTR for some customer of ours in their own domain, I didn't see it, but I also didn't look for it. Posting data by ASN/IP totally avoids that issue and makes looking for your ASN(s) trivial. getting emails from a lot of people thanking for the posts because they were able to identify a lot of messy traffic on their network and put an end to it. Posting information like this to a private list may not have accomplished much. I don't see a problem with posting it to both or as many appropriate lists as you can find. Nanog is kind of geo-specific though. Other lists might have much broader representation from the entire internet. This should be another thread completely, but I am wondering about the liability of the individual's who have owned machines that are attacking me/my clients. I'm not a lawyer but I would assume that tort liability law could apply and find someone liable for allowing their machine to DDoS people. IANAL either, but if I steal your car and run someone over with it, are you liable? Should you be? Computers are "stolen" or at least commandeered on the internet at an alarming rate because those who do it know that odds are, they won't get caught. And if they are caught, odds are, nothing will happen. And there's apparently considerable profit in the sale of commandeered systems or services provided by them. I doubt you'll get anywhere trying to make an example of someone who's system was hacked or even just "used improperly". I really don't think this problem can be solved by scaring sysadmins or corporations. There will always be security holes. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Destructive botnet originating from Japan
On Sun, 25 Dec 2005, Rubens Kuhl Jr. wrote: The first rule of nsp-sec is, you do not talk about nsp-sec The second rule of nsp-sec is, you DO NOT talk about nsp-sec https://puck.nether.net/mailman/listinfo/nsp-security There's nothing secret about the existence or purpose of the list. I don't know enough about Barrett to guess as to whether or not he'd qualify. Also, I was considering emailing Barrett privately, but since there seems to be so much misinformation going around, others will probably benefit from this. If you want to send out list of IPs suspected of being bots or really any other class of insecure/0wn3d systems, to make it easier for those who care to find their IPs in your list, run it through the Team Cymru whois server first. http://www.cymru.com/BGP/whois.html Then sort the list numerically by ASN. That way, people can scroll through it, or search by ASN, and quickly determine if there's any further action worth taking. It's also a really good idea to include timestamps, ideally exact ones in GMT per IP. In this case (unix bots) it's not as likely, but typical windows bots frequently show up on end-user systems with dynamic IPs. Telling me one of my dial pool IPs was a bot "recently" is not as useful as telling me it was a bot 2005-12-25 02:30:45 GMT. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
On Sat, 10 Dec 2005, Douglas Otis wrote: With the high prevalence of viruses having a forged return-path, the concern is largely about _false_ detections. These are not actual numbers, but perhaps more realistic than figures suggested previously. Imagine the false positive error rate for an email AV filter runs about 1 in 1000 malwares. While indeed this may not be a tragedy having a few valid emails lost without notice in an AV effort, this loss is not required when "valid" DSN recognition is deployed. The loss is also not required when virus/malware scanning is done during the SMTP conversation. Google for QHPSI. Messages don't have to disappear and bogus DSNs don't have to be sent. People just need to modernize their MTAs. The AV filter then bounce technique has been used for many years, where DSNs must be filtered at the DSN recipient. Rather than seemingly Like many other things on the internet, just because it's been in place for many years doesn't mean its a good idea or still a viable system. will also recover the valid 1 in 1000 DSNs. This BATV automation would also ensure no DSNs with forged return-paths, created at any point where acceptance criteria differs between MTAs, will be accepted before the data phase. BATV should be almost as effective as a DNS-BL. You can even use automate BATV refusals by others to add to your own temp BL. That still leaves "our" (the people not sending bogus DSNs) systems having to do lots of work (validating signitures) to decide how to handle DSNs that should never have been sent. Interesting that you should mention DNSBLs. I've seen people asking for DNSBLs of bogus DSN senders for years. I hope the integration of AV filtering and MTAs will improve before we see widespread use of bogus DSN sender DNSBLs. Unfortunately, for some people, experiencing pain is the only way they can be convinced to clean up their problems. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Viral Cure Could 'Immunise' The Internet
On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: Excerpts: A cure for computer viruses that spreads in a viral fashion ^^^ could immunise the internet, even against pests that travel at lightning speed, a mathematical study reveals. Nobody remembers Nachi/Welchia and the damage it did to networks while curing blaster? Nice intention. Bad idea. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: blocking unallocated subnets
On Fri, 2 Dec 2005, John S. Bucy wrote: I work for a large email provider and we've run into trouble delivering mail to certain sites after bringing up new servers in a recently allocated subnet of 72/8. Apparently, some folks decided it would be a good policy to protect their nameservers from ddos attacks to silently drop requests from unallocated subnets. So they obtained a list of subnets at some point in the past, deployed it and then never updated it. Welcome to 2002. Have a look at http://69box.atlantic.net/ ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: SWIP and Rwhois in the Real World
On Wed, 7 Sep 2005, Randy Bush wrote: Can someone summarize the alternatives to the ARIN recommended RWHOIS server bits (from rwhois.org)? A quick hit on Google and Freshmeat was fairly barren. i use irrd I'm curious how you or anyone else using irrd deals with the following issues: 1) Needing to be able to tell ARIN how much of your space is reserved vs assigned, what percentages of each of those are the various "sub-categories" ARIN seems to care about. i.e. Dial-up, Cable, Hosting, Leased Line, DSL, Colo, Wireless, other. Did you hack the irrd source to add a custom field(s) to route objects, abuse the member-of field, or create a maintainer object for each category of usage and use the mnt-by field as a classifier. Or if you have all your space in irrd, can you just point ARIN to your whois server and say "there's all the data, have fun with it", and skip questions 4-8 on net-isp.txt? 2) Finding unassigned space, preferably appropriately sized for the desired allocation. Shell script that asks irrd for all routes mnt-by your "Unallocated maintainer" sorted by (selectable) either prefix or prefix length? 2a) Finding open bits of reserved space. i.e. We'll commonly take a /24 and mark it as reserved for router interface /30s. The /24 isn't "open" anymore, but until its been used up, there's lots of /30s within it that are available for assignment. I suppose instead of putting the /24 in irrd as reserved, each of the /30s could be put into irrd marked as either reserved in use, or reserved available. 3) Assuming you let multiple people add/remove route objects, what's done to enforce consistency in the data? Perhaps a web interface to sending the updates that populates as many of the fields as possbile from pull down selections? Also, is there some secret to mirroring other registries with irrd? After installing, I figured it'd be fun to play with someone else's data, so I tried to mirror altdb and then arin. Each gave me similar errors: % ERROR: serials (1 - 108) don't exist! % ERROR: 4: Invalid range: serial(s) 1-2902 don't exist -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: trollage (Re: Akamai server reliability)
On Mon, 28 Nov 2005, Deepak Jain wrote: I'm sorry, isn't that exactly what an airbill *is* paying for -- to get the equipment on site? They also frequently need boxes power cycled. It got to be so frequent that we "gave them" a remote reboot switch for all their gear and told them how to use it. They still kept emailing us for reboots until I finally used a contact at akamai to get the remote reboot info properly placed. We've had our share of failed boxes, DOA boxes, boxes with components literally falling out of them on arrival, etc. I suspect it's just a sign of the box building having been farmed out to the cheapest available source. When you're building boxes in really large volume, what's a few missing screws here there? :) The man hours (really, we are talking about less than a single hour to replace a server including all the mounting and repacking). The one man hour that they need (no more than 6 a year by the look of it) should offset the value the ISP is getting from not buying bandwidth to get to the content and for the improved performance they get. I wouldn't count on that. With bandwidth prices continually falling, and the ISP business changing (at least for us, dialup/DSL is dying, hosting is taking off, and now instead of having spare outbound capacity to sell to Akamai), we do more outbound than inbound, so the servers really don't save us anything except maybe a bit of latency. If that model doesn't work for the ISP in question, they should ask Akamai to pull their gear. Think of the man hours that'd take, ripping them out, boxing them up, etc. :) ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IP Prefixes are allocated ..
On Mon, 28 Nov 2005, Glen Kent wrote: to different Autonomous systems. Is there a central/distributed database somewhere that can tell me that this particular IP prefix (say x.y.z.w) has been given to foo AS number? Prefixes aren't assigned to ASNs. They're assigned to organizations/networks. Those entities may have several ASNs or no ASN of their own. You can see what ASN(s) annnounce what prefixes by looking at BGP. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: [NANOG]Cogent issues
On Thu, 17 Nov 2005, Edward W. Ray wrote: My cogent traffic is getting routed to my other peers here in Orange County, CA and I cannot access http://www.cogentco.com either. I have routes for it (38.0.0.0/8 from all my transits), but I can't reach www.cogentco.com either. Traces to it die inside Cogent's network. 9. cogent-level3-ge.NewYork1.Level3.ne0%5553 53 55 58 10. p15-0.core02.jfk02.atlas.cogentco.c0%5555 54 56 64 11. p14-0.core02.ord01.atlas.cogentco.c0%4454 54 54 54 12. ??? ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [NANOG]Cogent issues
On Thu, 17 Nov 2005, David Barak wrote: I think you mean http://www.cogentco.com It's up. Their wholesale dialup product appears to be down. A coworker just called it in and was told "multiple fiber cuts" have seriously impacted Cogent's network. Multiple simultaneous fiber cuts...yeah, that seems likely. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: the future of the net
The URL http://www.linuxjournal.com/article/8673 now leads to the following message: "Linux Journal Is Currently Unavailable Due to a Denial of Service (DoS) Attack Sorry for any inconvenience." That's intriguing ... Most likely incorrect too. They've been /.'d...not just nanog'd. They've apparently mistaken the spike in load for a DoS. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
L3 having issues on the west coast?
I was trying to get some IOS and compare a few images in FN, and found I cisco.com was being sluggish, and FN wouldn't load at all. Packets Pings Hostname%Loss Rcv Snt Last Best Avg Worst ... 6. ge-6-2-0.mp1.Orlando1.Level3.net 0% 44 44 54 13120 7. ae-0-0.bbr1.SanJose1.Level3.net 14% 38 4475 74 75 77 8. ge-11-1.ipcolo1.SanJose1.Level3.net 23% 34 4475 75 75 76 9. p1-0.cisco.bbnplanet.net 10% 40 4475 75 81160 10. sjce-dmzbb-gw1.cisco.com 0% 44 4477 75 82292 11. sjck-dmzdc-gw2.cisco.com 25% 33 4476 76 76 77 12. www.cisco.com 59% 18 4476 76 77 78 That doesn't look right. Anyone know what's going on out there? ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: cogent+ Level(3) are ok now
On Tue, 1 Nov 2005, John Curran wrote: I do not see how one network can tell another: "You can't send me what my customers are requesting of you." Depeering seems to say exactly that, no? No. Presumably, that traffic's still going to be exchanged between the two networks' customers. Depeering just says "go pay someone for transit if you want to talk to our network". Not talking to a network that depeers you is not a long term viable option if you're in the internet access provider business. If your business model is to provide flat-rate access, it is not _my_ responsibility to ensure your customers do not use more access than your flat-rate can compensate you to deliver. Agreed... I'm not defending the business model, only pointing out that some folks may find it easier to bill their "peers" than customers. Seems like some people want to bill both. Not being an expert in Tier1 peering issues, it really seems like the only explanation for this depeering was L3 wanting to raise Cogent's cost of doing business...presumably as an attack on Cogent's business model of selling access way below the average Tier1 going rate. For those who disagree, how does forcing Cogent to pay [anyone, not necessarily L3] for access to L3's network reduce L3's cost of carrying the bits that will flow regardless of whether Cogent's peering with L3 or buying transit to get to L3? I actually can think of a couple possible explanations. Perhaps L3 wanted Cogent to interconnect with them in more places (so they wouldn't have to carry traffic as far), and Cogent refused. If you have a customer in CA, and I have a customer in FL, and we peer, whats a fair way to move that traffic cross country? i.e. We both bill our customers...who pays to move the bits cross country? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Level3 Question
On Sun, 23 Oct 2005, Dan Mahoney, System Admin wrote: Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation. A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure. Yes. When Level3 depeers Cogent again, unless Cogent buys transit to or makes other arrangements for reaching Level3, you will be unable to reach single-homed Cogent customers (or Cogent itself) from your friend's single-homed Level3 colo...as you were when Level3 depeered Cogent previously. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Routers RAM and BGP table bloat
On Fri, 21 Oct 2005, Nils Ketelsen wrote: I am just guessing here, but if the manufacturer says 256MB is the maximum, I would expect that the unit is not able to address more than 256MB memory, regardless of the amount you plug in to it. Occasionally, that's not the case. i.e. the NPE225 was originally spec'd as having a max RAM capacity of 128mb. I've got an old Sony notebook that Sony says is upgradable to 256mb...but several manufacturers make a more densely populated dimm for it that allowed me to upgrade it to 384mb. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: /24 multihoming issue
On Wed, 19 Oct 2005, Kyaw Khine wrote: routeviews is seeing both paths. 64.9.17.0/24 AS 33105 ISP-A = 701 :) ISP-B = 19094 You might talk to 701 about why for instance, all I see is your prepended path via 19094 through 3356, 6461, 4323, and 19962. Maybe 701 is only propogating your route to customers? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: multi homing pressure
On Wed, 19 Oct 2005, Owen DeLong wrote: Yes and no. Most people that will spend the $$ for routers with enough memory to handle multiple full feeds are also looking to get a certain amount of TE capability out of the deal, and, at that point, babysitting the TE becomes more than 0.01 FTE (closer to 0.30 in my experience). Some may. The one I'm talking about with the Imagestreams really doesn't. They've overprovisioned the heck out of their network after the C&W/PSI thing and really have no need for TE. In fact, no attempt at all has been made to influence their traffic. Just a simple let BGP take care of it config. That's an interesting way to look at it. I think that at the time those routers were designed (I'm assuming you are talking AGS+ here), there I wasn't thinking that far back. I'm talking about the 3640 and 2610/2611/2620/2621s. For many end users, these routers would be just fine for multihoming with a few T1s, if they had the RAM capacity for several full views. At the time the above customer was multihoming, their only real options with cisco were the 3660 and 7200 series, which were overkill (and overpriced if you want new gear from say Tech Data). cisco finally has come out with replacements for those "little routers" with much bigger RAM capacities...but they're a little late. That could be true, but, how long do you really think the RAM will last? I suppose it won't. I just checked up on them. Seems they must have canceled their other provider (I hope so anyway...its been down at least a week), and with just 1 full view from us, they have 2.3mb free. I guess its time to get them on the phone and see about either shutting off BGP or just sending them 0/0. Another 3640 bites the dust. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: multi homing pressure
On Wed, 19 Oct 2005, Owen DeLong wrote: I've done simple ASN/BGP based multihoming for a number of businesses, and, it can be done on a mostly set-and-forget basis. If you have your upstreams supply 0.0.0.0/0 via BGP and no other routes, and, you advertise your networks, believe it or not, that's a pretty stable configuration. If your upstreams are reasonably reliable, that works pretty well. If not, and, you care about knowing what your upstreams can't reach at the moment, then, you need a full feed and life becomes slightly more complicated. There's really nothing more complicated about taking 2 (or more) full views, other than keeping an eye on available memory. The C&W/PSI incident a few years ago and the more recent Cogent/Level3 incident are perfect examples of why taking two 0/0's really doesn't cut it if you want reliable connectivity to the "whole internet". Cisco burned a lot people by building routers with needlessly limited RAM capacities (planned obsolescence?). Because of that, one customer wouldn't buy another cisco, and instead went Imagestream. They have 3 full views and no worries now. They were so happy with that Imagestream, they ended up buying a bunch more for internal WAN needs. Another customer I dealt with recently was fairly typical of the "small multihomer" I'd guess. They were multihomed to two Tier1 providers and wanted to replace one of them with us. Their BGP had been done either by a consultant or former employee and was definitely set and forgot on autopilot. Their router (cisco 3640) kept "dying" and they'd just power cycle it as needed. When I got in to take a look, I found it was taking full views and had pretty much no RAM left...and it was announcing all their space deaggregated as /24s for no reason. They weren't willing to shell out the $ for a bigger router, so I ended up configuring them for full routes from us and customer routes from their other (a Tier1) provider (and fixing their advertisements). Other than expansion (more network statements), running out of RAM again, or changing providers, I doubt their BGP config will need to be touched in the forseeable future. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Fwd: The Root has got an A record
On Mon, 10 Oct 2005, Peter Dambier wrote: I am sorry if you feel annoyed by this, but c.public-root.com, Cleveland, Ohio, USA, IP 68.255.182.111 e.public-root.com, Montreal, Quebec, Canada, IP 216.138.219.83 f.public-root.com, Terre Haute, Indiana, USA, IP 66.15.237.185 g.public-root.com, Chicago, Illinois, USA, IP 199.5.157.131 h.public-root.com, Des Moines, Iowa, USA, 64.198.89.245 Where they operate or how many alternative root's there are really doesn't matter. Anyone nutty enough to rely on them gets what they have coming. ------ Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Fwd: The Root has got an A record
On Mon, 10 Oct 2005, Peter Dambier wrote: See with your own eyes: ; <<>> DiG 9.1.3 <<>> -t any . @a.public-root.net ^^ ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18588 ;; flags: qr aa rd; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN ANY ;; ANSWER SECTION: . 172800 IN SOA a.public-root.net. ^ hostmaster.public-root.net.\ 2005101006 43200 3600 1209600 14400 . 172800 IN A 57.67.193.188 Who cares? Please stop wasting NANOG bandwidth that could be better used debating peering/depeering with gibberish about fringe DNS systems. Report this to NANOG and the IETF. Make sure you send them a copy of my response and the headers of this message. I am holding UNIDT personally responsible for this technical nightmare. Make sure to also report when pigs fly and the aliens decide to publicly make contact. Apologies to anyone already .procmailrc'ing Peter to /dev/null for sneaking this into your inbox. ---------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Level 3's side of the story
On Fri, 7 Oct 2005, David Hubbard wrote: I don't remember seeing this public notice from Level(3) posted Wouldn't that be "without notice from Level(3)"? They notified Cogent, not the public. Cogent chose to I think it's also interesting, that AFAIK, Level3 didn't give their own customers any advance notice. We're a customer. I saw nothing about this until it hit nanog. We're multi homed, so the impact on us was unnoticed. Suppose you're a single homed L3 or Cogent customer doing regular business with a single homed Cogent or L3 customer. If your provider gave you several weeks notice, and if you realized the coming problem, you might take some steps to work around the issue, depending on how important your internet communications are. Do the typical peering NDAs forbid giving customers this sort of notice? Is it better to surprise them with a multi-day outage and then give them 30 days notice that it's going to happen again?? Splendid, that gives the world sufficient time to accept Cogent's offer of 1 year free service. This is not the first time Cogent has used their customers as pawns in peering disputes, I don't know if I'd jump on the bandwagon so quickly (spoken as a customer of both companies). If you're multihomed and using Cogent as a cheap bandwidth whore, does it matter if their cheap bandwidth gives you 155k routes instead of 168k routes? After all, if its cheap and off-loads enough traffic from your more expensive 168k route circuits, isn't it doing what you bought it for? Also, is 30 days really enough time for anyone to get a free connection to Cogent? I mean if you're in a building they're already in, and its just a cross connect, sure that can be done quickly...but at least around here, getting any sort of high bandwidth circuit (>T1) can take months. IIRC, the UNE DS3 connecting our office to the rest of our network was several months late. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
