Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Richard A Steenbergen wrote: If you're going to filter, it is your job to keep the filters updated, not ARIN's. Nor is it ARIN's job to move your blocks around every time some idiot doesn't accept it, or after you manage to get it blacklisted, or whatever. They need to allocate more space from 69 so anyone still filtering it wonders why they can't get to their latest porn site (no pun intended) and fix it. People depend on ARIN's IP assignments being widely routable. When 2 different ARIN clients pay the same amount of money for leasing an IP block, the goods they receive should be of the same quality. ARIN clients should have the ability to exchange defective goods. It seems ARIN won't do this. And posting to NANOG or similar lists doesn't seem to fix the problem. Sooner or later someone's going to decide to let the lawyers deal with it. I don't think ARIN's resources should be wasted in the courts. This type of problem is likely to spur interest in more regional registries. There's been talk of CIRA seting up a Canadian IP registry. This has been handled by ARIN took over the work UofT was doing years ago. -Ralph
RE: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Kris Foster wrote: This type of problem is likely to spur interest in more regional registries. There's been talk of CIRA seting up a Canadian IP How would more registries help? It would just add more voices, not the number of ears listening.. Canadians have a lot more influence on CIRA than on ARIN. -Ralph
disconnected autonomous systems
I've found there are many providers that have completely disconnected autonomous systems. For example Yipes (6517) uses L3 on the west coast and Williams on the east coast. 66.7.129.0/24 is advertised under their AS through WCG and 209.213.209.0/24 is advertised under their AS through L3. And the number of connected autonomous systems with de-aggregated prefixes appears to be even more common than a disconnected AS. It would seem that many (most?) network operators are just ignoring the more vocal opinions on NANOG. -Ralph
Re: disconnected autonomous systems
On Wed, 13 Nov 2002, Daniel Golding wrote: [...] As far as aggregation - they are a couple reasons to not aggregate, but the vast majority of it is sloth. [...] I've never seen anyone here complain that Yipes de-aggregates 66.7.128.0/18 into /24's like 66.7.129.0/24. Until the bigger providers change their ways why should someone like me (who has only chopped a /20 into /21-/23 with a covering /20) decide that doing a single aggregate /20 announcement is going to make a difference? -Ralph
Re: disconnected autonomous systems
On Wed, 13 Nov 2002, Richard A Steenbergen wrote: Just making sure Ralph knows this, since I'm sure achieving 99% peering by getting 10GE into NYIIX is the goal for his OC192 over 2600 network. :) Trying to run OC192 over a 2600 router would make more business sense than giving away 250mbps of free transit, which you claim to have done (on isp-bandwidth) lately. ;-) -Ralph
Re: iBGP next hop and multi-access media
On Mon, 7 Oct 2002, Majdi S. Abbas wrote: On Sun, Oct 06, 2002 at 11:40:11PM -0400, Ralph Doncaster wrote: Manually configuring a static route in router A would achieve the result: ip route 172.16.16.0 255.255.255.0 fa0/0 However, I'm surprised that there's no dynamic routing protocol that allows you to do everything you can with static routes. Ralph, how do you intend on getting traffic *OUT* of this subnet? Static arp entries on all the hosts? Proxy arp? It seems like that would be a lot more work and much more failure prone in the long run. What, you don't use a static default route on your end hosts? Are you one of those crazy types that run RIP on your IIS/NT servers? -Ralph
RE: iBGP next hop and multi-access media
Can someone please explain to me *why* are you trying to come up with *complicated* configurations as opposite to (a) defining your connected routes on all the routers that would be using it. I've asked because I wanted to know if any routing protocol redistributes information about diretly connected multi-access networks. It seems pretty obvious to me that if you have a an ethernet segment with multiple routers on it that adding a secondary IP to each one is more complicated and error-prone than adding it to one and having a dynamic routing protocol notify the rest of the routers on the segment. It also seems that the answer I was looking for, at least as far as iBGP is concerned, is no. However rather than just saying, no, BGP can't do this many people have decided to brag about how smart they are because they don't ask questions about how BGP works. So now I can sit back and watch the chest-thumping continue... -Ralph
Re: iBGP next hop and multi-access media
On Sun, 6 Oct 2002, Clayton Fiske wrote: On Sun, Oct 06, 2002 at 04:25:00PM -0400, Ralph Doncaster wrote: A and B are connected via the same multi-access media. It is technically possible for B to tell A you can reach 172.16.16.0/24 on the same media that you receive this update on. However what people seem to be saying is that there is no dynamic routing protocol that implements this. There are two solutions to your dilemma: - Route via B - Add A to 172.16.16.0/24 It's not a matter of dynamic routing, it's just the way subnets work. If you want all the hosts to be able to talk to each other directly, put them all on the same subnet. It seems I'm not the only idiot asking these types of questions. I found there's a whole RFC about it. http://www.ietf.org/rfc/rfc1433.txt -Ralph
iBGP next hop and multi-access media
Background: Router A and B are connected via a common ethernet segment 1. Router A uses 10.10.10.1/30, and Router B uses 10.10.10.2/30. Router B also has another subnet configured for ethernet segment 1; 172.16.16.0/24. When I setup a situation like the above, with Router B advertising the 172.16.16.0/24 to router A, router A sees a next hop of 10.10.10.2. This is not good since packets from A going to the 172.16.16 subnet get sent to Router B, which then ARPs the desitnation, instead of just being ARPed by router A. I don't want to turn on ICMP redirects on B since they're insecure and ugly. I've also made sure I'm not using next-hop self. Is there a way to make this work? Ralph Doncaster principal, IStop.com
Re: iBGP next hop and multi-access media
I've already had several direct replies saying to manually configure the 172.16 subnet on router A. Sure, that will work, but I'm looking for a solution that doesn't require manual configuration of all the routers involved. Ralph Doncaster principal, IStop.com
Re: iBGP next hop and multi-access media
A and B are connected via the same multi-access media. It is technically possible for B to tell A you can reach 172.16.16.0/24 on the same media that you receive this update on. However what people seem to be saying is that there is no dynamic routing protocol that implements this. Ralph Doncaster principal, IStop.com On Sun, 6 Oct 2002, Stephen J. Wilcox wrote: I dont understand this.. A wants to get to a network which it [thinks it] is not connected to, the only route is via B. therefore you must advertise the route from B with next hop B the only possible way (at least in ethernet IP) that A can send direct onto the ethernet segment is if it is connected to the other (172.16) network and if youre not willing to do that then your solution is not possible Steve On Sun, 6 Oct 2002, Ralph Doncaster wrote: Background: Router A and B are connected via a common ethernet segment 1. Router A uses 10.10.10.1/30, and Router B uses 10.10.10.2/30. Router B also has another subnet configured for ethernet segment 1; 172.16.16.0/24. When I setup a situation like the above, with Router B advertising the 172.16.16.0/24 to router A, router A sees a next hop of 10.10.10.2. This is not good since packets from A going to the 172.16.16 subnet get sent to Router B, which then ARPs the desitnation, instead of just being ARPed by router A. I don't want to turn on ICMP redirects on B since they're insecure and ugly. I've also made sure I'm not using next-hop self. Is there a way to make this work? Ralph Doncaster principal, IStop.com
Re: iBGP next hop and multi-access media
On Mon, 7 Oct 2002, E.B. Dreger wrote: RD Date: Sun, 6 Oct 2002 21:05:32 -0400 (EDT) RD From: Ralph Doncaster RD Not really, what I want is router A to learn that ther is no RD next hop IP- the subnet is on the local ethernet. As others are saying... it isn't local. It's not local unless in the same subnet. Physical topology often correlates with higher layers, but it's not strictly 1:1. Manually configuring a static route in router A would achieve the result: ip route 172.16.16.0 255.255.255.0 fa0/0 However, I'm surprised that there's no dynamic routing protocol that allows you to do everything you can with static routes. -Ralph
Re: iBGP next hop and multi-access media
On Sun, 6 Oct 2002, [EMAIL PROTECTED] wrote: On Sun, 6 Oct 2002, Ralph Doncaster wrote: As others are saying... it isn't local. It's not local unless in the same subnet. Physical topology often correlates with higher layers, but it's not strictly 1:1. Manually configuring a static route in router A would achieve the result: ip route 172.16.16.0 255.255.255.0 fa0/0 Why are we doing basic IP routing 101 on NANOG? OK, since it's so basic why don't you explain how to have router A dynamically learn from router B that there is a new subnet on the local ethernet? Don't route IP blocks to the ethernet. That's using ARP as your routing protocol and it's horribly fragile. I've seen one ISP do that (they were very technically challenged) and it's a setup that broke way too easily. So then what do you call a connected route (for an ethernet interface on a router)? If you use ethernet, at the edges of your network you HAVE to route IP blocks to the ethernet. -Ralph
Re: iBGP next hop and multi-access media
On Mon, 7 Oct 2002, Alex Rubenstein wrote: I've been doing ip route statements going on 8 years now, and I can't imagine why ever -- and how it would even work -- you'd want to ip route a netblock with a next hop of a multi-access brandcast media. As in, the next hop is still truly undetermined. I guess I don't know this because I've never tried it. But, how does the router determine where to send the packets for a route statement as specified above (ip route a.b.c.d e.f.g.h f0/0) ? When you setup a secondary ip on an interface int fa0/0 ip address a.b.c.d e.f.g.h secondary How does it determine where to send the packets? ARP. Which is the same as adding the route described above. -Ralph
Re: iBGP next hop and multi-access media
My understanding is the route is valid as long as the interface is up; just like adding a secondary IP on the interface. Ralph Doncaster principal, IStop.com On Mon, 7 Oct 2002, Alex Rubenstein wrote: Aha. So, if you route to a ethernet interface, it will try to arp for that address on that subnet, even without having a local address on the same subnet? This seems to me to be something you don't want to do. Is the entire route valid as long as the router can ARP for one of the addresses in the routed subnet? On Mon, 7 Oct 2002, Ralph Doncaster wrote: On Mon, 7 Oct 2002, Alex Rubenstein wrote: I've been doing ip route statements going on 8 years now, and I can't imagine why ever -- and how it would even work -- you'd want to ip route a netblock with a next hop of a multi-access brandcast media. As in, the next hop is still truly undetermined. I guess I don't know this because I've never tried it. But, how does the router determine where to send the packets for a route statement as specified above (ip route a.b.c.d e.f.g.h f0/0) ? When you setup a secondary ip on an interface int fa0/0 ip address a.b.c.d e.f.g.h secondary How does it determine where to send the packets? ARP. Which is the same as adding the route described above. -Ralph -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: iBGP next hop and multi-access media
It's a theoretical question. So far I've had one person email me saying OSPF can advertise a subnet as local on a shared multi-access media. If in fact BGP can't do this, then it's no big deal to me as nothing in my network relies on this functionality. Ralph Doncaster principal, IStop.com On Mon, 7 Oct 2002, Jason Lixfeld wrote: Are you just asking a question to get a better understanding of how things work, Ralph or have you already put this into production and are wondering why it doesn't work a certain way? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ralph Doncaster Sent: Monday, October 07, 2002 12:43 AM To: Alex Rubenstein Cc: [EMAIL PROTECTED] Subject: Re: iBGP next hop and multi-access media My understanding is the route is valid as long as the interface is up; just like adding a secondary IP on the interface. Ralph Doncaster principal, IStop.com On Mon, 7 Oct 2002, Alex Rubenstein wrote: Aha. So, if you route to a ethernet interface, it will try to arp for that address on that subnet, even without having a local address on the same subnet? This seems to me to be something you don't want to do. Is the entire route valid as long as the router can ARP for one of the addresses in the routed subnet? On Mon, 7 Oct 2002, Ralph Doncaster wrote: On Mon, 7 Oct 2002, Alex Rubenstein wrote: I've been doing ip route statements going on 8 years now, and I can't imagine why ever -- and how it would even work -- you'd want to ip route a netblock with a next hop of a multi-access brandcast media. As in, the next hop is still truly undetermined. I guess I don't know this because I've never tried it. But, how does the router determine where to send the packets for a route statement as specified above (ip route a.b.c.d e.f.g.h f0/0) ? When you setup a secondary ip on an interface int fa0/0 ip address a.b.c.d e.f.g.h secondary How does it determine where to send the packets? ARP. Which is the same as adding the route described above. -Ralph -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: IPv4 country of origin
On Thu, 3 Oct 2002, [EMAIL PROTECTED] wrote: Is there a more accurate method to determine the country of origin for an IP than the methods I've described above? Yes, at least three companies have databases of pretty much all /24s and above mapped up to a zip code. So far I've been referred to 3 commercial services, and all (including NetGeo/Ixia) fail on the example I gave (194.196.100.86). -Ralph
Re: IPv4 country of origin
On Thu, 3 Oct 2002, Stephen Sprunk wrote: Thus spake Ralph Doncaster [EMAIL PROTECTED] That's basically all Netscape Microsoft were doing when they had to restrict 128-bit SSL. They threw in the requirement to enter your address phone number, but they had no way of telling if you were entering your address, or the one you got from doing a four11.com lookup of John Smith in Plano, Tx. The new crypto regulations allow shrink-wrapped software to be exported if the receiver claims to be authorized; there is no legal requirement on the exporter to actually verify this status... One of my clients is a large computer security software company. According to them, it's not just crypto export rules that are the concern, but also the ITAR countries (N. Korea, Lybia, Cuba, ...). As well they are concerned about liabilities in countries like France where it is illegal to import crypto so they want to restrict people from France too. -Ralph
IPv4 country of origin
I would like to restrict access from certain countries to content on my network (for security and legal reasons). So far the best algorithm I've been able to come up with is a combination of reverse DNS and APNIC/ARIN/RIPE whois queries. I've written a perl cgi that checks reverse DNS first, and if there is no gtld country code for the reverse mapping, does a whois query and parses the response for the address. The problem I have is that the country for the company that owns the IP block is sometimes not the country the IP block is used in. For example sungold22.de.ibm.com 194.196.100.86 Whois parsing indicates a country of UK, but from the reverse DNS a person can see that it is Germany. I've built the pattern of cc.ibm.com into my cgi, but I'm sure there are other blocks that I'm incorrectly identifying. I've looked at RADB entries, as well as origin AS for various IP blocks, and neither source looks any better than whois. Is there a more accurate method to determine the country of origin for an IP than the methods I've described above? -Ralph
Re: ATT NYC
On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
routing architectures ( was Re: ATT NYCrouting )
On Thu, 29 Aug 2002, Robert A. Hayden wrote: Um. Set up more than one reflector So how many is enough? I would think 3 is a minimum to come close to the reliability/redundancy of OSPF. -Ralph
RE: ATT NYC
On Thu, 29 Aug 2002, Derek Samford wrote: I personally prefer using IS-IS for loopback/infrastructure routes, and I use confederations for my IBGP. If a confederation ever gets to large, I can always add a route-reflector inside the confederation. Ralph, you have never failed to amaze me with your love for WCP (Worst Current Practices.) OK, then hand me a clue and explain why ruing an iBGP mesh with 3-4 routers is so bad (seeing as Bassam Halabi didn't in his book). -Ralph
60 Hudson peering
I have a POP in 60 Hudson, 19th floor. The only peering exchange I'm aware of in the building is Stealth's IPV6 exchange in Tel-X (23rd floor). If there's any interest in IPV4 peering from any networks with a presence on the 19th, I'd be willing to provide free 100baseTx ports on a peering switch in 1904. I'm aware of MetroIX, but that's on the 15th floor and its unreasonably expensive to get fiber cross-connects between floors in 60 Hudson, and cat5 cross-connects aren't even available between the 19th and 15th floors. Ralph Doncaster principal, IStop.com
Re: 60 Hudson peering
$750/mth is once you get to MetCom. For the cx on the 19th to their FDP is another $300/mth. Now you're at $1050/mth. For $1K/mth I can get 100M from the 19th floor to 25 Broadway, + $100/mth for the cat5 cx. So if I were going to spend a grand a month to connect to an exchange point, it would be NYIIX and not MetroIX. Ralph Doncaster principal, IStop.com On Tue, 27 Aug 2002, Jeffrey Meltzer wrote: $750 is not unreasonable for 2 strand dark fiber in 60 Hudson. And if you work hard, you can get this down to $500. Check 111 8th Ave, it costs well into the $3,000/mo range generally. In addition, we're already working on (in progress) cat5 xcon's between TelX and suite 1505 in 60 Hudson. However, how much do you think that would cost? Not all that much less, figure in the $300/mo range. Furthermore, anyone peering inside of TelX is probably doing it privately and because of the cost of xcon's there, probably would keep doing it privately. BTW, if anyone is interested in speaking about MetroIX, contact myself or Avi off-list. It's been moving along slowly as people re-evaluate peering arrangements, companies that we talk to disappear, etc ;) People like to see things done instantly in this market, but that's not always the best way to get things done right... Jeff On Tue, Aug 27, 2002 at 12:38:43PM -0400, Ralph Doncaster wrote: I have a POP in 60 Hudson, 19th floor. The only peering exchange I'm aware of in the building is Stealth's IPV6 exchange in Tel-X (23rd floor). If there's any interest in IPV4 peering from any networks with a presence on the 19th, I'd be willing to provide free 100baseTx ports on a peering switch in 1904. I'm aware of MetroIX, but that's on the 15th floor and its unreasonably expensive to get fiber cross-connects between floors in 60 Hudson, and cat5 cross-connects aren't even available between the 19th and 15th floors. Ralph Doncaster principal, IStop.com
RE: Eat this RIAA (or, the war has begun?) - Why not all ISPs?
Is someone mainitaining a server I can get an eBGP feed from that will blackhole all RIAA IPs? If not, how do you propose to block the RIAA? Ralph Doncaster principal, IStop.com On Wed, 21 Aug 2002, Nigel Clarke wrote: Why don't larger ISPs follow through on this? Simply deny RIAA any access... http://www.informationwave.net/news/20020819riaa.php Too bad it's just a small ISP. - Joost ___ music-bar mailing list [EMAIL PROTECTED] http://www.ampfea.org/mailman/listinfo/music-bar
Re: ASN registry?
That seems to be the closest to a complete db, but I noticed it doesn't necessarily have the same info as ARIN. For example ARIN's listing for 1239 has a lot more details than the RADB entry. From the responses so far, it seems that it is necessary in some cases to query ARIN, RIPE, and APNIC to find the info you are looking for. Ralph Doncaster principal, IStop.com On Mon, 19 Aug 2002, [EMAIL PROTECTED] wrote: I usually use radb as it seems to referance other whois servers: whois -h whois.radb.net as1221 On Mon, 19 Aug 2002, Ralph Doncaster wrote: I've always used whois.arin.net to check ASN registrations, and until now it's always had information on those that I've checked. It doesn't have anything for 1221, which according to route-views.oregon-ix.net is Telstra. Is there a single complete database that has ASN assignment info? Ralph Doncaster principal, IStop.com
Re: Major Labels v. Backbones
In the meantime, you will have to continue to pay your staff, spend your own time and upgrade your routers to do the RIAA's dirty work for them. Happy networking. Doesn't anyone have any balls? The lawyers are making lots of money sending out nastygrams, so billing for work related to finding customers who infringe on copyrights is more than fair. http://www.istop.com/BSALetter.txt -Ralph
RE: Any people still with old filters?
...and the clue-less on the Internet is (still) less than 80%. It's more like 20%. See http://mcvax.org/~jhma/routing for one example of how much we could gain if we actually aggregated... This was hinted at in the peering debate, but wouldn't it help the cause of aggregation if networks stopped requiring a large number of prefixes in order to establish peering? -Ralph
RE: verio arrogance
You aren't the biggest offender, but how should anyone draw an arbitrary line for you are polluting too much and you are polluting, but to a reasonable extent. The most reasonable and quantitative means I can see is technical; if there is no network engineering benefit to announcing more specifics it should not be done. There's lots of swamp space where you'll see 2 contiguous /24's announced with the same AS path, metrics, etc. Those are the prefixes you should be pushing to get aggregated, not mine. You could do a deaggregate+no-export method as well, even with your two different transit providers. You would just need to run ebgp-multihop to each of them from the opposite network, and announce your more-specifics there. Not a perfectly clean method, but at least it keeps your pollution local. Then there is no ability for remote networks to choose the best path to my Toronto vs Ottawa networks (since the different transit providers would announce only the /20). Instead of using more router CPU/mem, this uses more network bandwidth than necessary (statistically speaking traffic has a 50% chance of going to the wrong transit provider). As well, for the ebgp-multihop to work wouldn't that require some extra static routes to be setup by my transit providers? -Ralph
Re: verio arrogance
Announce your largest aggregate, and announce more-specifics tagged no-export to those peers who agree to accept them? Which is worse than announcing just the more specifics to 2 different transit providers in 2 different cities. Worse for those two transit providers, not the rest of the world. Why won't the rest of the world see extra hops and increased latency reaching my network (for the 50% of the time that the wrong transit provider is picked). Upgrade the connectivity between your sites? Technically sound, economically stupid. You offering to pony up the $5K/mth for an OC3 so I can have a redundant link between Ottawa and Toronto? You are choosing to save money by poluting the global routing table. There may not be anything wrong with that, but don't be surprised when you hit providers who don't want or need to listen to your more specifics. Stop whining about it and fix your announcements. The proposed fix is a big mess. My solution doesn't add to the global routing table since I'm renumbering out of a few /24's to the /20 I received from ARIN. I'm only de-aggregating to a /23, not /24. My solution provides optimal routing vs announcing the /20 globally. The proposed fix will waste bandwidth, increase latency, and far more problematic to implement; how many NOC monkeys do you know that will be able to grasp the purpose of the 2 BGP sessions (one of them ebgp-multihop) let alone fix it if something goes wrong? -Ralph
Re: istop arrogance
Why won't the rest of the world see extra hops and increased latency reaching my network (for the 50% of the time that the wrong transit provider is picked). Because you could *gasp* be intelligent with your network design and do things like purchase transit from the same carriers in both your serving markets. I guess you don't consider redundancy to be intelligent. I do. I guess you can call me stupid. The problem here Ralph is that you see absolutely no problem with doing things on your network that have minimal benefit to you, yet have global impact. The problem here Paul is that you can't seem to see the forest for the trees. If you consider routing table size reduction so important, why don't you filter all /24's? That will give you much more benefit than /20's that have been de-aggregated. -Ralph
routing table size
If the size of the global routing table is really an important issue, why not start filtering /24 announcements? I have more of a legal right to use my /20 since I pay ARIN $2K/yr for it, vs most /24 owners. Filtering /24s should cut the size of the global routing table back to 1998 levels. Ralph Doncaster principal, IStop.com
Re: solving problems instead of beating heads on walls [was: somethingabout arrogance]
If you want to run seperate networks, run separate networks. Different ASes, the whole 9 yards; perhaps a re-reading of rfc1930 is in order? That brings us back to the discussion of PI space. If de-aggregating my /20 didn't work, then I'd either inefficiently use IP space in order to qualify for 2 /20's, or buy a defunct ISP or 2 to get a bunch of /24's in the 192-223 space. Are you suggesting that either of those (which don't violate any RFCs) options are better than de-aggregating my /20? Your response was something about I guess you don't consider redundancy to be intelligent. What's stopping you from using the same two transit providers in both locations? Seems to me you don't value redundancy all that much. I'm currently using Peer1 in Toronto for transit and they don't have a POP in Ottawa. Having 2 different transit providers in both Ottawa and Toronto has only a marginal improvement in redundancy vs provider A in Ottawa and provider B in Toronto. Even if I could use provider A in both Ottawa and Toronto I wouldn't due to the reduced redundancy. And your assumption about my Ottawa-Toronto link is wrong. I have a 100M point-to-point ethernet link between the cities. I have a 100M transit connection to Peer1 in Toronto, and have issued a letter of intent to a transit provider in Ottawa for a 100M link. -Ralph
Re: istop arrogance
Because you could *gasp* be intelligent with your network design and do things like purchase transit from the same carriers in both your serving markets. I guess you don't consider redundancy to be intelligent. I do. I guess you can call me stupid. Carriers is a plural word.. How does that not accomplish redundancy again? As I pointed out in my last post, I can't. And even if I could the economics of doing it don't make sense. If economics don't matter, then the most intelligent network design would be a redundant OC192 mesh, but I don't know even one network that does that. -Ralph
Re: routing table size
Off your network, your legal rights are pretty limited. I (and I'm sure lots of other admins) block at the /24 boundry. Anything you announce from /25 to /32 will be ignored on my network. Some providers choose to block according to RIR allocation sizes. To me, that's not worth the maintenance hassle. To them, it may mean the difference between having to upgrade or replace large numbers of routers last year or sometime in the next few years. I've never suggested accepting /25's thru /32's. I'm wondering if the people saying I should not de-aggregage my /20 actually practice what they preach and filter /24's and don't globally announce /24's from their customers. -Ralph
Re: istop arrogance
Your economic problems are your own, if you were smart you would learn how to solve them within the rules of the game. I know how to solve the problem within the rules. Getting a dozen /24s in the swamp would solve the problem, but would pollute the global routing table more than de-aggregating my /20 into /21s and /22s. It seems to me that there's a few experts on the list that have their heads in the sand. Not only did I quickly find someone who helped get Verio's filters updated, but I had several other emails from people asking for help doing the same. I have yet to hear anyone suggest any better technical solution, so I guess I'll just lurk on this thread and listen to the folks in their ivory towers talk about how the perfect world should be... -Ralph
Re: solving problems instead of beating heads on walls [was: somethingabout arrogance]
On Sat, 27 Jul 2002, Ralph Doncaster wrote: And your assumption about my Ottawa-Toronto link is wrong. I have a 100M point-to-point ethernet link between the cities. I have a 100M transit connection to Peer1 in Toronto, and have issued a letter of intent to a transit provider in Ottawa for a 100M link. Ralph, if you have a 100m link between the two cities, why don't you use conditional announcements to only announce your /20 though Ottawa if your primary transit in Toronto goes down? Then, you only need to announce your /20 in Toronto, no need to deaggregate, and the whole issue is solved. Then, when you have the Ottawa 100m transit link up, you can announce your /20 to both transit providers all the time. That is roughly the intention. I also have to be able to announce the more specifics for when the Ottawa-Toronto link goes down. You could find in the archives my posts from a couple months back asking how to do this. -Ralph
Re: verio arrogance
I'm a little disappointed in Verio, if they really did decide to accept your unneccessarily deaggregated prefixes. I'm a little disappointed you're wasting list bandwidth after this has been well discussed, and not a single post has offered a better technical alternative to de-aggregating my ARIN /20 (given my network topology). -Ralph
Re: verio arrogance
I'm a little disappointed you're wasting list bandwidth after this has been well discussed, and not a single post has offered a better technical alternative to de-aggregating my ARIN /20 (given my network topology). -Ralph Announce your largest aggregate, and announce more-specifics tagged no-export to those peers who agree to accept them? Which is worse than announcing just the more specifics to 2 different transit providers in 2 different cities. Upgrade the connectivity between your sites? Technically sound, economically stupid. You offering to pony up the $5K/mth for an OC3 so I can have a redundant link between Ottawa and Toronto? Besides the technical aspects of my network, I didn't see any proof that relaxed prefix filtering (and no I'm not saying accept /32's - the more specifics I got Verio to accept were /23's) would cause significant (i.e. 30%) routing table bloat when that was recently discussed. -Ralph
packet loss source
Thanks to those who suggested improper duplex negotiation between the 2621 and the 2900. Although show int on the 2621 (running 12.0.7T) indicates full-duplex, sh controller indicates BCR9 =0x (half-duplex). Ralph Doncaster principal, IStop.com
Cisco questions
A couple people pointed out cisco-nsp would be more appropriate for questions like the one I posted about packet loss. http://puck.nether.net/lists/ Ralph Doncaster principal, IStop.com
Re: Draft of Rep. Berman's bill authorizes anti-P2P hacking
The BSA is even flexing it's muscles here in the GWN. http://www.istop.com/BSALetter.txt Although they seem to have lots of money for scanning services and lawyers, they expect ISPs to provide services (assisting them enforce their copyrights) for free. Ralph Doncaster principal, IStop.com
debugging packet loss
I'm seeing 2-5% packet loss going through a Cisco 2621 with 10mbps of traffic running at ~50% CPU. (packet loss based on ping results) Pinging another box on the same catalyst 2900 switch gives no packet loss, so it seems the 2621 is the source of the packet loss. I need help figuring out why it is dropping packets, and how to stop it. The odd thing is that the interface stats don't show any dropped packets: Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 00:01:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 00:10:16 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 1/512, 0 drops 5 minute input rate 5257000 bits/sec, 1383 packets/sec 5 minute output rate 5692000 bits/sec, 1448 packets/sec 845743 packets input, 392733148 bytes Received 403 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 887446 packets output, 430245866 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 22694 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Ralph Doncaster principal, IStop.com
Re: /24s run amuck... again
On Fri, 19 Jul 2002, Richard A Steenbergen wrote: With all the recent talk about filtering, I figured now was a good time to update my list of evil /24 announcers... There are currently over 63k /24s out of 113k total unfiltered announcements (over 55%). Does anyone (Cisco, Juniper, etc.) have an auto-aggregation feature? Let's say a router that receives the following prefixes under a single AS 206.51.128.0/24 206.51.129.0/24 206.51.131.0/24 And the following network is not in the table: 206.51.130.0/24 Then it would be usefull to collapse it into a single 206.52.128/22 aggregate (especially if the metrics communities are the same). -Ralph
Re: verio arrogance
That said, their current policy of refusing to accept de-aggregated prefixes from peers (while accepting such from paying customers) makes perfect sense, IMHO. Not arrogant, just a smart reasonable business decision. I have one downstream ISP customer that explicitly asked for full BGP routes to be written into the contract. Why Verio's customer's wouldn't want full routes makes no business sense to me. However a NANOG list subscriber was kind enough to help me get past Verio's NOC monkeys and get their filters updated to allow my announcements. -Ralph
Re: verio arrogance
(Apologies if this is flogging a dead horse, but some messages are worth repeating, if for no other reason than to illustrate the down side of not understanding the proper rationale for CIDR.) I thought the dead horse was the conclusion that small ISPs should use whatever means the ARIN rules allow in order to get PI space. Having used provider-assigned space for a couple years, I can firmly say it sucks. Even if I had to talk to every tier-1 to get my de-aggregates accepted, it would be MUCH less hastle than having PA IP space. And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space. -Ralph
Re: verio arrogance
On Thu, 18 Jul 2002, Ralph Doncaster wrote: And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space. I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point? If the block isn't assigned to you by ARIN, I've encountered cases where network operators request an LOA before accepting the announcement, even if there is an RADB entry for it. As well, if you have PA space and your upstream allocates you a 66.x for example, then you're back to square one. -Ralph
Re: verio arrogance
On Mon, 15 Jul 2002, Richard A Steenbergen wrote: On Mon, Jul 15, 2002 at 05:10:28PM -0400, Ralph Doncaster wrote: Announcing a covering /20 along with the regional more specifics I have will only serve to increase the size of the routing table for most backbones, and lead to sub optimal routing in some cases since I'm announcing the more specifics due to geographical diversity. Announce the /20 to your transit providers, and the more specifics with no-export. Verio's position is that they don't want to or need to hear your /23s unless you are a customer, and for the most part they are right. But I've broken my /20 into a /21 for Ottawa, a /22 for Toronto, a /23 for Montreal, and a /23 for expansion. I'm currently only getting transit in Toronto, but will have a second transit provider restored in Ottawa (I was using GT for a short while). While announcing the the /20 will my network is reachable for single-homed Verio customers, it won't provide the true best path that simply accepting the regional more specifics. -Ralph
Re: True cost of peering (was Re: Sprint peering policy)
NYIIX 1/4 rack + 100M switch connection - $1K/mth fiber cx for Gig-E to high-bandwidth peers: $0/mth small GSR12000 - $20K from the local bankruptcy trustee OC192 from Manhattan to Vienna, VA: $10K/mth SIX is also quite inexpensive. I've been told Equinix can be talked down from ~$3K/mth for a rack/power a couple cx to $1500/mth. The following problems exist with your plan: * 10Gbps circuit to a 100Mbps peering point... Are you sure your name isn't Nick Catalano? With $0/mth cx fees from telehouse, it only makes sense to use the NYIIX switch for low-bandwidth peers, and do a private interconnect with the rest. * What peers do you plan to find at NYIIX that you'll be doing Gbps to? 6461, 4323, 4513 would be good candidates. * OC192 interfaces don't grow on trees (or even ebay yet) Yeah, right now the best price point is for OC48 - I've seen used OC48 linecards for $2K. This time next year I expect to start seeing OC192 cards on the used market. * Two peering points on the east coast won't get you squat Yeah, the point was to show just how cheap things are now. Adding Chicago, Seattle, Pao Alto should be enough to satisfy peering requirements for 75% of your traffic. * Crosscountry circuits are just a tiny bit more expensive Depending how you buy them - buying the backbone assets of a defunct carrier that has a bunch of OC48 192 lambda IRUs with 15+ years left on them should work out quite cheap amortized over the remaining IRU term. Next up on the auction block... Teleglobe. -Ralph
RE: Sprint peering policy
I know Sprint won't peer with anyone small. I said in my inital post I don't stand a chance - but who knows, at the rate OC48 prices are dropping maybe next year I will meet the requirements. Attention K-Mart shoppers, WorldCom OC48's on sale in isle 5. ;-) The second point is, whomever you spoke to has violated a non-disclosure agreement, one that is normally taken seriously. I would tread carefully in this area, as it may get whomever you spoke with in a significant amount of trouble. I didn't post this until now since I was waiting for a couple opinions to verify that it was in fact genuine, and as well a public filing that anyone could get if they know where to dig at the FCC. http://ns.istop.com/~ralph/2000-04-13-sprint.pdf -Ralph
Sprint peering policy
While many other tier-1's have publicly listed their peering policies, I've never seen anything for 1239. Not that I'd stand a chance, but does anyone know what their peering requirements are? Ralph Doncaster principal, IStop.com
how is cold-potato done?
If I peer with network X in cities A and B, and receive the same route in both cities with an AS-path of X, how do I know which city to use for an exit? I can understand how if X uses communities to tag the geographic origin of the traffic, but I'm not aware of many networks that do this. Lots of networks claim to use cold-potato routing though, so how do they do it? Ralph Doncaster principal, IStop.com
Re: how is cold-potato done?
If I peer with network X in cities A and B, and receive the same route in both cities with an AS-path of X, how do I know which city to use for an exit? I can understand how if X uses communities to tag the geographic origin of the traffic, but I'm not aware of many networks that do this. Lots of networks claim to use cold-potato routing though, so how do they do it? they use the MED sent on the route (aka metric) from the other provider to determine which exit where they both interconnect is the shortest. this can at times provide undesired results because of aggregation. Besides aggregation, wouldn't this lead to a lot of ties? Let's say the cities are LA Manhattan, and the route from X originates in Chicago. I would think that it would be a common occurrance for the route to have the same metric in LA Manhattan. -Ralph
Gig-E over OC48?
What's the cheapest way to get Gig-E over OC48? A couple used Cerent(Cisco) boxes would work, but the $15-$20K price tag is too high. Ralph Doncaster principal, IStop.com
Nanog MRGT stats
I can't figure out why the weekly says max in 3051.7 kb/s, but daily says 999.3 kb/s max. http://nanogmrtg.grouptelecom.net/216.18.62.102_13.html Time for my morning coffee I think... Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
AS8070
I've noticed a large chunk of my customer traffic coming from Microsoft. Anyone know if they peer anywhere on the East coast? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: AS8070
On Sat, 1 Jun 2002, Richard A Steenbergen wrote: On Sat, Jun 01, 2002 at 06:42:58PM -0400, Ralph Doncaster wrote: I've noticed a large chunk of my customer traffic coming from Microsoft. Anyone know if they peer anywhere on the East coast? I think you have [EMAIL PROTECTED] confused with [EMAIL PROTECTED] 1) I already tried [EMAIL PROTECTED] (after finding them on the SIX members list) 2) I think you have forgotten the NANOG charter. I'll quote one of the 5 goals: Promote and coordinate interconnection of networks within North America and to other continents. You may not care about AS8070, but I'm sure there are lots of other people on the list that do. -Ralph
ARIN RADB
Did someone at Merit see my posts and decide to start mirroring the ARIN RR (see the source line at the bottom)? [ralph@cpu1693 lralph]$ whois [EMAIL PROTECTED] [whois.radb.net] route: 66.11.160.0/23 descr: ISTOP-Montreal Doncaster Consulting Inc. 2720 Queensview Dr Ottawa, ON K2B 1A5 CA origin: AS21936 notify: [EMAIL PROTECTED] mnt-by: MNT-ISTOP changed:[EMAIL PROTECTED] 20020525 source: ALTDB route: 66.11.160.0/20 descr: Doncaster Consulting Inc. 2720 Queensview Dr Ottawa, ON K2B 1A5 CA origin:AS21936 notify:[EMAIL PROTECTED] mnt-by:MNT-ISTOP changed: [EMAIL PROTECTED] 20020517 source:ARIN Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: Linux routing
On Tue, May 21, 2002 at 06:34:47PM -0400, Ralph Doncaster wrote: I don't really trust the vmstat system time numbers. Based on some suggestions I received, I ran some CPU intensive benchmarks during different traffic loads, and determined how much system time was being used by comparing the real and user times. The results seem to show that if I want to do 50Mbps full-duplex on 2 ports (200M aggregate) that the standard Linux 2.2.20 routing code won't cut it. [snip bogus benchmark] Why are you benchmarking network troughput by bzip2'ing a file in /tmp? It makes no sense. interrupts are taking up CPU time, and vmstat is not accurately reporting it. I need *something* compute intensive to infer load by seeing how many cycles are left over. -Ralph
RE: Cisco 7200 VXR with NPE-400 (was RE: The market must be coming back)
Based on our testing it looks like it all has to do with packet size. With small packets the throughput is very low. With what Cisco calls an internet mix of packet sizes throughput is much better. When doing max MTU packets, the throughput is of course the best. The other thing I've found about traffic type is how sensitive netflow is. I was running it for a while, then I got a co-lo customer that had a lot of UDP traffic with small packet sizes and rarely more than a few packets between the same src/dest ip/port (much like DNS queries). It was enough to flatline the box and cause it to crash. -Ralph
Re: list problems?
On Wed, 22 May 2002, Andy Dills wrote: On Wed, 22 May 2002, Jeffrey Meltzer wrote: I've gotten at least 5 messages from you on this list today... Yeah, maybe NANOG implemented WFQ... Further tests seem to indicate that every message posted to the list is read/approved by a human. http://ns.istop.com/~ralph/censored.txt -Ralph
Re: list problems?
It's not realtime censored (since my emails get through quite quickly, and if Merit is actually hiring people to censor NANOG 24/7 someone needs to reevaluate their funding), but I have seen censoring in the past which is almost comical in nature, for example the Sexual Harassment filter. So there's a netnanny-like bot that looks for bad words and filters the posts? Best be careful, the PC police are coming for you. If the US succeeds in assymilating Canada as the 53rd state, I could avoid the Merkans by moving to Cuba. ;-) -Ralph
Linux routing
I don't really trust the vmstat system time numbers. Based on some suggestions I received, I ran some CPU intensive benchmarks during different traffic loads, and determined how much system time was being used by comparing the real and user times. The results seem to show that if I want to do 50Mbps full-duplex on 2 ports (200M aggregate) that the standard Linux 2.2.20 routing code won't cut it. Unloaded Duron 1G root@TO-VS ~# time bzip2 /tmp/words real0m0.414s user0m0.400s sys 0m0.010s 750Mhz Duron, ~20Mbps traffic, 8K int/sec vmstat reported CPU idle: 98% (2% system) root@tor-router ~# time bzip2 /tmp/words real0m0.628s user0m0.380s sys 0m0.160s CPU load ~= 40% root@tor-router ~# time bzip2 /tmp/words real0m0.552s user0m0.460s sys 0m0.090s CPU load ~=16% 750Mhz Duron, ~60Mbps traffic, 20K int/sec vmstat reported CPU idle: 95% (5% system) root@tor-router ~# time bzip2 /tmp/words real0m1.071s user0m0.370s sys 0m0.690s CPU load ~= 65% root@tor-router ~# time bzip2 /tmp/words real0m1.041s user0m0.440s sys 0m0.600s CPU load ~= 58%
Cisco quality
For those saying Cisco is so great, it's still fucked up pretty bad. IOS 12.1 and later doesn't allow an MTU 1460 on L2TP, while 12.0.7(T) works fine with a 1492 MTU that my PPPoE customers expect. Every rev I've tried from 12.0 and up has problems with CEF when using ISL VLAN sub-interfaces, and without CEF, mac-accounting is screwed up. Now if they charged 1/5th of what they do, I'd say you're getting reasonable value for your dollar... Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: route statistics
I'm trying to collect statistics on how many routes match certain patterns. So far I've been using zebra, set term len 0, and then sh ip bgp regexp, and wait for the total prefixes count at the end of the list. I figure there must be a better way than this, but so far haven't found one. Any ideas? Zebra supports dumping the RIB to MRT binary format. See the 'dump bgp' family of commands. I find this format much easier to deal with than CLI output. Bradley I've been told getting the MRT sources to build is rather difficult. I may give it a shot anyway... -Ralph
RADB mirroring
RADB definately does not mirror (at least not daily) ARIN's RR. Time to setup with altdb... % ARIN Internet Routing Registry Whois Interface route: 66.11.160.0/20 descr: Doncaster Consulting Inc. 2720 Queensview Dr Ottawa, ON K2B 1A5 CA origin:AS21936 notify:[EMAIL PROTECTED] mnt-by:MNT-ISTOP changed: [EMAIL PROTECTED] 20020517 source:ARIN [ralph@cpu1693 lralph]$ whois [EMAIL PROTECTED] [whois.radb.net] % No entries found for the selected source(s). Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: portscans (was Re: Arbor Networks DoS defense product)
I often like to know if a particular web server is running Unix or Winblows. A port scanner is a useful tool in making that determination. a full-blown portscan is not required here. A simple telnet to port 80 will do the job. A simple telnet to port 80 will sometimes do the job, but often not. And even your statement a full-blown portscan is not required concedes that a portscan will work in making this determination.
Re: portscans (was Re: Arbor Networks DoS defense product)
rough assessment of their network security, which was important to me as a customer for obvious reasons. In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address? -Ralph
Re: PAIX (was Re: Interconnects)
traffic. If you're going to have to negotiate bilateral agreements to cover the bulk of your peering traffic, why not consistantly negotiate bilateral agreements? Randy (Group Telecom) snubbed me when I asked to peer at TorIX. Group Telecom is on the AADS MLPA. ATT Canada has a tough policy re peering as well, and is on the AADS MLPA. I'm sure there are others among the AADS MLPA signatories that would refuse bilateral peering if I approached them. -Ralph
Re: Re[2]: portscans (was Re: Arbor Networks DoS defense product)
RD I often like to know if a particular web server is running Unix or RD Winblows. A port scanner is a useful tool in making that determination. [allan@ns1 phpdig]$ telnet www.istop.com 80 Trying 216.187.106.194... Connected to dci.doncaster.on.ca (216.187.106.194). Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 19 May 2002 01:47:57 GMT Server: Apache/1.3.22 (Unix) FrontPage/4.0.4.3 PHP/4.1.2 mod_fastcgi/2.2.8 Sure, it works on some servers, but try it on yahoo.com, cnn.com, ... -Ralph
Re: Re[4]: portscans (was Re: Arbor Networks DoS defense product)
If they don't give a satisfactory bank somewhere else (or offer your services ;)). Certainly that is a better approach than scanning to see what you can find out. The organization receiving the scan has no way of knowing what your intentions are -- and should interpret them as hostile. I think that's pretty stupid. If I had my network admin investigate every portscan, my staff costs would go up 10x and I'd quickly go bankrupt. Instead we keep our servers very secure, and spend the time and effort only when there is evidence of a break in.
Re: Re[6]: portscans (was Re: Arbor Networks DoS defense product)
RD I think that's pretty stupid. If I had my network admin investigate every RD portscan, my staff costs would go up 10x and I'd quickly go bankrupt. RD Instead we keep our servers very secure, and spend the time and effort RD only when there is evidence of a break in. I didn't say investigate every portscan, I said assume every portscan is hostile. There is a big difference. So you assume it's hostile and do what? Automatically block the source IP? If you do that then you open up a bigger DOS hole. Then if someone sends a bunch of SYN scans with the source address spoofed as your upstream transit providers' BGP peering IP, poof! you're gone.
Re: Re[2]: portscans (was Re: Arbor Networks DoS defense product)
http://uptime.netcraft.com/up/graph/?mode_u=offmode_w=onsite=www.cnn.com Works for me, works from any system that has a browser. At any given time I'm *far* more likely to have a browser running than port scanning software, so this solution is also IMHO faster. Until today netcraft listed agamemnon.cnchost.com as unknown. I ran nmap to see what it says, so I guess you should assume I'm hostile. ;-) Interesting ports on agamemnon.cnchost.com (207.155.252.31): (The 1519 ports scanned but not shown below are in state: closed) Port State Service 21/tcp openftp 25/tcp opensmtp 80/tcp openhttp 110/tcpopenpop-3 TCP Sequence Prediction: Class=truly random Difficulty=999 (Good luck!) No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: TSeq(Class=TR) T1(Resp=Y%DF=Y%W=6045%ACK=S++%Flags=AS%Ops=NWM) T2(Resp=N) T3(Resp=N) T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=N)
Re: portscans (was Re: Arbor Networks DoS defense product)
That's a netblock, not an IP address. Your script kiddie at home with a cable modem or ADSL connection is not going to have his IP SWIP'd or populated in his ISP's rwhois server. Try that with 206.47.27.12 for instance. That is a Sympatico ADSL customer here in Ottawa. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Sun, 19 May 2002, Alex Rubenstein wrote: helium:~$ whois -a 207.99.113.65 Net Access Corporation (NETBLK-NAC-NETBLK01) 1719b Route 10E, Suite 111 Parsippany, NJ 07054 US Netname: NAC-NETBLK01 Netblock: 207.99.0.0 - 207.99.127.255 Maintainer: NAC Coordinator: Net Access Corporation (ZN77-ARIN) [EMAIL PROTECTED] 800-638-6336 Domain System inverse mapping provided by: NS1.NAC.NET 207.99.0.1 NS2.NAC.NET 207.99.0.2 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE * Reassignment information for this network is available * at whois.nac.net 43 On Sun, 19 May 2002, Ralph Doncaster wrote: rough assessment of their network security, which was important to me as a customer for obvious reasons. In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address? -Ralph -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PAIX (was Re: Interconnects)
On 17 May 2002, Paul Vixie wrote: I welcome any further questions about PAIX's health or future. When we Why no optional MLPA like AADS? Even though AADS is overpriced, I considered it just because of the long list of companies that are signed up on the MLPA. -Ralph
Re: PAIX (was Re: Interconnects)
Why no optional MLPA like AADS? [...] we had one at first. after a few years of approximately no signatories, we stopped trying. my own experience is that bilaterals are more useful for engineering purposes and that multilaterals are kind of swampy. One BGP session instead of dozens is more convenient. Maybe not more useful for engineering, but certainly less work than negotiating and configuring a bunch of sessions for bilateral peering. For smaller ISPs like mine, knowing in advance that you won't get snubbed for peering after connecting to an exchange is the big attraction. Given the dozens of signatories on the AADS MLPA, it looks like they can be quite popular. -Ralph
route statistics
I'm trying to collect statistics on how many routes match certain patterns. So far I've been using zebra, set term len 0, and then sh ip bgp regexp, and wait for the total prefixes count at the end of the list. I figure there must be a better way than this, but so far haven't found one. Any ideas? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: Network Reliability Engineering
Good luck. For a proper scientific analysis you'd need MTBF info on every point of failure - i.e. the physical link, CSU/DSU, power supply, ... As a rather non-scientific observation, a couple outages per year of 1-4 hours seems to be quite common for a single-homed T1 or faster connection, be it from WorldCom, ATT, Sprint... I think the arguments in favor of dual-homing are pretty cut and dry. Tri-homing vs dual-homing would be a much tougher benefit to quantify. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Sat, 18 May 2002, Pete Kruckenberg wrote: I'm looking for some good reference materials to do some reliability engineering calculations and projections. This is to justify increased redundancy, and I want to include quantifiable numbers based on MTBF data and other reliability factors, kind of a scientific justification instead of just the typical emotional appeal using analyst/vendor FUD. I'd appreciate references on how to do this in a network environment (what data to collect, how to collect it, how to analyze, etc). Also any data (or rules of thumb) on typical MTBFs for network events that I won't find on vendor product slicks (like what's the MTBF on IOS, or human-caused service outages of various types, etc). If someone has put together something remotely like this that they'd care to share, that'd be incredibly helpful. Thanks. Pete.
Re: Interconnects
There are some relatively small regionals like NYIIX where you won't find many large carriers, but they still have their own little nitch markets. There's been rumors of NYIIX and PAIX-NY linking up like SIX and PAIX-seattle. * Price - In these times of cost conciousness (and transit available for less than the price of peering), many people are taking a step back and realizing that PAIX services are OUTRAGEOUSLY priced vs the competition. Some big carriers are turning down their PAIX switch ports, even at Palo Alto. Which is why I was surprised that Paul offered PAIX-seattle connectivity for a $300 one-time charge for those who are already connected to SIX. -Ralph
RADB RRs
I've been registering my routes in ARIN's RR, only to find that nobody uses it. ;-( Do any of the RRs mirrored by the RADB offer free maintainer-IDs? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: BGP and aggregation
I was thinking of doing iBGP over my transit connections (with a couple of static routes so the iBGP works) AND over my inter-city circuit. Any reason why this won't work? -Ralph The loss of igp metric will make it untenable at best. Do it over a GRE tunnel, with your regular igp (isis, ospf, eigrp, or shudder rip). As far as I can tell, GRE doesn't support fragmentation - i.e. encapsulation of a 1500-byte IP packet that results in a GRE packet larger than the interface MTU size. -Ralph
Re: BGP and aggregation
isn't a problem don't worry about it. If you wish to preserve connectivity between cities you should have a back-up link or use different as's or gre tunnels:). Floating statics would be a less-hassle means to continue connectivity (with only 2 locations not much of a scaling issue). Or, if you want, a default route (learned via BGP if possible) going to your upstream(s). An IBGP session sharing full routing information might not be something you want to keep established over a GRE tunnel. Hmm... the default route idea sounds even easier than my iBGP over a transit link. I think I'll try your idea first. -Ralph
BGP and aggregation
I have transit in 2 cities. I have a circuit connecting the 2 cities as well. So far I've been using non-contiguous IPs, so there's been no opportunity for aggregation. Having just received my /20 from ARIN, I'm trying to plan my network. Lets say I split the /20 into 2 /21's, one for each city. I'd like to announce the aggregate /20 instead of 2 /21's, as long as the circuit connecting the 2 cities is working. If the circuit goes down I want each city to announce the local /21. Is this possible? (using either a Cisco router or Zebra) Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
Re: BGP and aggregation
* BGP is an EGP, not an IGP * You might want to check out OSPF if you think your net will grow Using iBGP between the 2 cities right now. May try OSPF later. * You don't want your IGP influencing your EGP. Flap, flap. * Redistributing EGP into IGP isn't exactly good, either. Are the upstreams the same in each city? Why not announce the aggregate /20 normally, and set NO_REDISTRIBUTE and use MEDs on the /21s? You're paying for transit, so MEDs are fair game. Well, the assumption is that most of the time the circuit between the 2 cities will be up, so flapping should be rare. The transit is from different providers, so only announcing the /20 won't do the trick. -Ralph
Re: BGP and aggregation
On Sat, May 11, 2002 at 05:34:39PM -0400, Ralph Doncaster wrote: [...] goes down I want each city to announce the local /21. Is this possible? (using either a Cisco router or Zebra) If I was paying for transit, I would want THEM to do the work of delivering it to the right city, without wasting the bandwidth of my circuit (unless they're really close and that circuit is really cheap). It's 2 different providers, and one is much cheaper than the other. Therefore I want all traffic to come in through city A, unless my circuit to city B is down. -Ralph
Re: BGP and aggregation
On Sat, 11 May 2002, Andy Walden wrote: Conditional Router Advertisement: http://www.american.com/warp/public/459/cond_adv.pdf Cool. This looks like what I want. For those that don't like pdf, here it is in HTML from cisco. http://www.cisco.com/warp/public/459/cond_adv.html -Ralph
Re: CAIS/Ardent Routing Problems?
I heard they were being bought by Verio. Maybe Verio is taking over their routes and dropping AS3491? Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Fri, 10 May 2002, John Palmer wrote: Anyone see anything strange with AS 3491 today? They have been dropping our routes on and off all day long?
RE: IP renumbering timeframe
But it would seem that given the attitude many have expressed here of if they're not your customer any more, screw 'em., then relying on the honor system is unwise. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Mon, 6 May 2002, Daniel Golding wrote: Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one check on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen. Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea. - Daniel Golding Ralph Doncaster angrily ruminated What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space. -Ralph
Re: Effective ways to deal with DDoS attacks?
What's NANOG's opinion: assuming that uRPF is implemented on all customer interfaces, are there any legitimate purposes for a customer to forward packets with source IP addresses not currently routed by the transit provider towards the customer (either static or BGP)? IP Tunneling - it often makes more sense to send packets out that have a source address reachable only through the tunnel.
RE: IP renumbering timeframe
As I already pointed out, I never passed a packet to Cogent. They were ready to provide service before I was ready to start using it. I paid setup, 1st month service, and then some. And your computer analogy is totally ridiculous. The only service I ever actually used was a /22 of IP space. A /19 from ARIN is $2500 for a year, so if Cogent wanted a couple hundred for my continued use of the /22 for 90 days I would have happily paid it. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Mon, 6 May 2002, Scott Granados wrote: Well don't forget its a two way street. If a customer isn't paying their bill then its the provider getting screwed. There is no insentive or in fact good reason to be helpful to this person. I won't be helpful to someone who decides to switch services and not pay me, ever! On the other hand if they are reasonable and if there is a friendly split both sides are more likely bo be reasonable. If someone buys a product say a computer from you, and doesn't pay you will you still service them? Better still if I'm the telephone company and you stiff me for x# of dollars and switch to another carrier do you really expect me to release the same telephone number for you so that you can switch uneffected. Its totally unreasonable to assume when someone isn't paid for their services that they will allow you to continue using their resources. And we're only talking a /20 here not to large a task. On Mon, 6 May 2002, Ralph Doncaster wrote: But it would seem that given the attitude many have expressed here of if they're not your customer any more, screw 'em., then relying on the honor system is unwise. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Mon, 6 May 2002, Daniel Golding wrote: Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one check on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen. Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea. - Daniel Golding Ralph Doncaster angrily ruminated What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space. -Ralph
Re: Effective ways to deal with DDoS attacks?
On Wed, 1 May 2002, Pete Kruckenberg wrote: I finally found a paper on this type of attack. http://grc.com/files/drdos.pdf and http://grc.com/dos/grcdos.htm describe the attack and a few possible defenses, though they are about as ineffective as most other DDoS defenses. Has NANOG stooped to quoting Steve Gibson as an expert on DDoS attacks? -Ralph
Re: anybody else been spammed by no-ip.com yet?
On Mon, 6 May 2002, Scott Francis wrote: On Sat, May 04, 2002 at 06:01:49PM -0600, [EMAIL PROTECTED] said: [snip] Passing laws and putting on filters don't work. Depending on each mail server admin to do the right thing doesn't work. We need to find something else that will. I'm beginning to think that fighting the spam itself is futile. What we should perhaps be focusing on is removing access to whatever is being spamvertised (frequently a get-rich-quick website, porn site, diet site, etc. - but generally a website somewhere, that can have the plug pulled). Actually, my analysis of spam seems to indicate authentication of remote SMTP servers through a process similar to joining this list would remove 99+% of SPAM. i.e. the first email from a particular remote server that is received, requires the sender to take some action (respond with a password, click on a URL, etc.) before the mail gets through. One of these days I hope to write the procmail rules to do it (if I don't find someone that has done it already) -Ralph
Re: Effective ways to deal with DDoS attacks?
On Mon, 6 May 2002, [EMAIL PROTECTED] wrote: On Mon, 06 May 2002 19:04:11 EDT, Ralph Doncaster said: IP Tunneling - it often makes more sense to send packets out that have a source address reachable only through the tunnel. But aren't those source addresses hidden *inside* the encapsulation, and what's visible to routers are the source/dest IPs of the tunnel itself? What I'm saying is that if something comes in through the tunnel, the shortest route to the destination is often not to go back out through the tunnel.
Re: IP renumbering timeframe
Well how am I supposed to arrange a payment on a Sunday afternoon? As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable. somehow, i suspect that we're hearing only one side of a, quite likely messy and unhappy, story. and i doubt it all happened on a sunny sunday afternoon. That's why I can't believe Cogent actually did this. 14:46 eastern, May 2 my Cogent rep Scott Elrod emailed me indicating there would be no resolution to the dispute, and to contact him should I wish to have Cogent service in the future. Since then we received *NO* contact from Cogent. I first heard that Cogent was expecting an immediate renumbering from the /22 was when I got an email from Peer1 (as I was watching Montreal beat Carolina). -Ralph
