RE: Pitfalls of annoucing /24s
On 16 Oct 2003 at 9:44, McBurnett, Jim wrote: [...] We are annoucing a /24 from the 66 /8 block and I have only found 2 ISP's (according the the netlantis project) that can't reach me. We are multihomed. I suspect that may be due to aggregation. But even with our backup online, I still saw the routes propogate via Netlantis.. Or am I out in left field going nuts? That's not bad at all. Many may be overstated. But if Charter announced a supernet around you those two dropouts should be able to reach you too. Better, eh? If your luck's anything like mine then the ones you lose are the ones you want. Peter E. Fry
Re: Extreme BlackDiamond
Bradley Dunn wrote: [...] Adding more specifics of a /8, /16, or /24 prefix seems to have a disproportionate impact; my guess is it has something to do with the data structure used to store the prefixes. (If they use a 256-way mtrie like they do for CEF, more specifics of a /8, /16, or /24 would require creation of an additional internal node.) Good point. I'd made the simple assumption that scanner spikes were due to table churn, as when redistributing connected and/or static routes to unstable interfaces. It happens that most such will be... unnaturally specific. [...] Peter E. Fry
Re: CCO/cisco.com issues.
On 6 Oct 2003 at 19:22, Allan Liska wrote: I don't know what your post has to do with the original topic, but if you don't like the way NONOG is moderated, please feel free to start your own Network Operators mailing list. As far as comparing NANOG moderation to Nazi Germany that is disgusting and beneath contempt. Read it again. He has a point (not yours). Perhaps this should be an agenda topic for the upcoming get- together: A common strategy for dealing with Internet crime. Much of it does appear to have common roots. (And I'm not even a conspiracy buff.) Hm. Oddly enough there's a blurb on overclockers.com that follows this somewhat: http://www.overclockers.com/articles843/. Peter E. Fry
Re: Worst design decisions?
David Barak wrote: Personally my issues are console-cable related: is there a benefit to the HUGE variety of console pinouts used by the various hardware vendors? Just look at vendor C as an example [...] Is that the best example you can come up with? Ever use any Bay equipment...? Heh. Makes me want to add I hate it when that happens, as in Ever put your head in a vise and crank it down real tight...? Peter E. Fry
Re: BGP issues
Bret Baptist wrote: [...] Right now I have visi.com as one provider (AS8015), and Qwest (AS3908) as the other. When I look at the as-paths for my netblocks the ones from visi.com look fine, 208.42.20.0/23 and 208.42.104.0/23, the ones from Qwest go through visi.com and then on to us, 65.116.186.0/24, 65.121.8.0/23. The Qwest networks are the ones that I am having problems reaching hosts from or getting to from other networks. [...] It's a bit of a long shot and difficult to see, but when I see natural C blocks without problems and natural A blocks with, I tend to suspect class-based filtering. This usually occurs if there's no less-specific route available, but there's 65.112.0.0/12 from Qwest covering both. This leaves only a few very obscure possibilities, so I wouldn't chase this except as a last resort. Peter E. Fry
Re: Cisco Service Provider code - Any good?
Jason Frisvold wrote: [...] We're currently looking into migrating our Cisco 72xx and 75xx routers to Service Provider IOS [...] The IOS would also have to support RFC-1483 connections (Preferrably RBE), BGP, IS-IS and any other basic services of the such. Looks like bridging (IRB and RBE) is spanky new to the S feature sets -- 12.2-14S range, so a 12.0-S load doesn't sound like it'll do the job for you. Peter E. Fry
Re: Cisco Service Provider code - Any good?
Peter E. Fry wrote: Looks like bridging (IRB and RBE) is spanky new to the S feature sets -- 12.2-14S range, so a 12.0-S load doesn't sound like it'll do the job for you. Ooops... RBE is available for the 7500 and IRB for the 7200 in the late 12.0-S loads, apparently. Well, that's new and unusual. Bridging was unavailable on the 7500 in earlier 12.0-S versions, and I made the mistake of searching initially for both features at once. Peter E. Fry
Re: ISPs are asked to block yet another port
Sean Donelan wrote: http://www.lurhq.com/popup_spam.html LURHQ Corporation has observed traffic to large blocks of IP addresses on udp port 1026. [...] I haven't (yet) seen any scans of port 1026, but looking at my (home) logs I have seen several with a fixed source port of 1026 (destination of 137). Heh. Peter E. Fry
Re: IRR/RADB and BGP
Vandy Hamidi wrote: Our new ISP is asking that I create a maintainer object in the RADB and associated AS/Routes for us to be about to eBGP peer. This is the first time I've been asked by a provider to do this for something as simple as peering to advertise a couple /24's. I've peered with ATT, Sprint, UUnet, Qwest, Savvis, SBC, and Internap in the past and never had to do anything but have a valid ASN provided by ARIN. Hey, wait a minute! You've peered with SBCIS and not set up an aut-num and route objects in the RADB? For shame! That's our policy, too. Get with it! Is this just so they can dynamically build their prefix/as-path lists? It's to avoid having Sprint mocked by L3. Why would I need to do this and what advantages are there. Cost to register with RADB is $250/year and I want to understand it before I shell out. Use ARIN's IRR or AltDB, then. But wouldn't it be nice to support the RADB, and our good friends at Merit? Heck, you could donate a few grand -- I'm sure they'd accept it. Peter E. Fry
Re: Iraqi Internet communications still working 3/21/03
On 22 Mar 2003 at 19:28, Hank Nussbacher wrote: I think Infocom and the Elashi's have other problems right now: http://www.cnn.com/2002/US/Southwest/12/18/hamas.arrests/ http://www.chron.com/cs/CDA/story.hts/special/terror/local/1064146 Ha! I wish I'd read this thread last night. My old neighbors, the Holy Land Foundation. Grrr. Offhand I don't know what happened to the remainder of InfoCom. I'll have to poke around if I get the chance. Peter E. Fry
Re: Route Supression Problem
Iljitsch van Beijnum wrote: On Wed, 12 Mar 2003, Randy Bush wrote: You need at least three flaps to trigger dampening. i guess you really need to look at that pdf. You are right, it is depressing. However, I don't see how the penalty multiplication could happen here, you need a few hops in between for that. Ah, but this is the Internet. Jack's two upstreams likely have direct or indirect links between them where they will also receive the route updates in question. Should we change the subject (back) to BGP to doom us all? Peter E. Fry (I believe I said that without swearing. $#[EMAIL PROTECTED])
Re: 69/8...this sucks
Andy Dills wrote: On Wed, 12 Mar 2003, Randy Bush wrote: maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained? Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Filter (public, private and transit) peers or customers...? Or themselves? I've had a few customers spontaneously (ahem) come up with remarkably Rob Thomas configs (if any noun can be verbed, can any name be adjectived?) -- I usually convince them to tone down the filters a bit. The funny ones are those who've signed up for a partial table or default. Then again, I suppose you can't be too careful. Peter E. Fry
Re: route filtering in large networks
On 12 Mar 2003 at 22:59, Jack Bates wrote: Nice, although it doesn't explain the purpose of having the routes if you have an acl. To keep viruses from attempting to contact bogons? To stop your internal network from surfing the bogon web which can't reply back anyways? It's a generic config -- note the ! Default route to the Internet [...]. Saves you some microbucks on that burstable Internet link, or maybe some of that micro-upstream-bandwidth on your ADSL when you get those spoofy pings. Hey -- you asked. I recommend it myself, on a smaller scale. (Sigh.) Your ideas are nice, but I'd have to rant all over this list to keep y'all from filtering my compelling bogon content. Peter E. Fry
Re: Shuttle Columbia - not necessarily nanog related
On 1 Feb 2003 at 7:42, Darin Wayrynen wrote: The Space Shuttle Columbia seems to have broken up during re-entry over Texas. [...] Heard the boom. Sounded like a minor ground impact -- no accompanying higher-frequency noise. Didn't know what it was -- I hadn't paid attention to the shuttle schedule. A pisser on many levels. Peter E. Fry
Re: fast ethernet limits
Joel Jaeggli wrote: [...] moreover they're signifcantly harder to install since they need to be properly grounded and shielded at both ends. I've actually seen some very impressive ground loops. I'd ground one end. (Actually I'd use fiber, but hey.) Peter E. Fry
RE: frame relay to atm conversion tool?
On 9 Jan 2003 at 17:45, Swaminathan, Sekar wrote: Instead of Frame Relay frames, you have to look at the payload which is usually IP packets. Here is the formula that I would use: [...] Specifying an average packet size is rough: I've observed that on an average Internet connection around 35% of packets are 64 bytes, 35% 1500 bytes, and the remainder scattered about. The average is guaranteed to be a poor match for at least 70% of your traffic. Not that it matters. Most carriers configure FRATM VCCs as 1536kbps frame relay = 4500cps, treating fractions accordingly. The last thing you want to do is exceed this cell rate (around 1710kbps at a 1500-byte packet size), as on a policed link you'll lose nonconforming cells. (Actually, a 1536kb frame relay seems to be closer to a 1705kb ATM VCC. Eh, the IWF has to buffer some anyway.) If you increase your cell rates you potentially oversubscribe your frame link (and the IWF may disallow it in any case). So if you're tempted to exceed this ratio be very certain of your link characteristics. Add to that: when a sustained rate is defined (VBR service category) the ATM peak rate probably doesn't mean what you would expect, so I recommend sustained = peak. (ABR is the best match for data, but isn't often used.) As to the original question, I wouldn't recommend translating a burstable frame to ATM unless you can order an ABR VCC or get UPC and/or frame discard disabled on your link (don't bet on it). It's not likely you can match parameters, so without flow control you're essentially looking at reduced performance or packet loss under load. Whatever you do get, I recommend you ask your carrier for a spec. You have plenty of variables and relatively robust protocols, meaning you could take a shot, miss, and only find out for certain that you had when you'd really rather not. Get it reasonably right, though, and it'll do right by you. Huh. Now that I look at it, I need to rethink my own figures yet again (I haven't even implemented the last rethink) as I appear to have tended toward the conservative in some areas. Grrr. Take it easy. Peter E. Fry
Re: Weird networking issue.
David G. Andersen wrote: Rule number 1 with any ethernet: Check to make sure you have the duplex and rate statically configured, and configured identically on both ends of the connection. [...] I'd like to thank Cisco for this piece of advice, as the only company incapable of manufacturing Ethernet equipment capable of autonegotiation. At least until 1999 or so. Yeah, there're a few others, all of which seemed to follow Cisco's lead. Nutty. Peter E. Fry
Re: Weird networking issue.
Peter E. Fry wrote: [...] the only [...] Yeah, *that* is a nutty statement. I could re-phrase, but I think most here get the intent. Peter E. Fry
Re: ISDN tip wanted
Ian MacKinnon wrote: Surely it can't be that, as the call has been answered. Not in my experience. Have you tried it? Peter E. Fry
Re: IETF SMTP Working Group Proposal at smtpng.org
Larry Rosenman wrote: [...] I think $100/year is STEEP, if it is PER SERVER, but per COMPANY/INDIVIDUAL it **might** be acceptable. (I have 3 boxes + the laptop that do SMTP regularly). Ideas given this? Relay through your upstream (hierarchical approach)? i.e. Register your server(s) with your provider, who is presumably trusted (registered with the global system). A bit of an aside: I recall ATT Canada blocked all SMTP from exiting their network (excepting their own servers, of course) a few years back in response to a large spam. I don't know the details -- this is from a response to a complaint I filed. Interesting idea, though -- you then catch 'em when they attempt to relay through your server. And as far as that goes, I've seen a system that worked quite well... Larry might be familiar with it, as it was his. Peter E. Fry
Re: Max Prefixes Configured on Customer BGP
On 15 Aug 2002 at 17:38, Joe Wood wrote: [...] It's been my experience that a lot of the providers that do prefix filtering on customer BGP sessions take great amounts of time before they act on the prefix-filter update request. This much fun when it's 5pm or later and you really need to announce a new customer netblock. How often do you run into that situation? I understand that you may not like it when you do, but a little planning on someone's part somewhere down the line eases the pain for everyone. It depends upon experience. You'd never have formed that opinion if you were my customer. Peter E. Fry No, I never thought much of emoticons.
Re: OC-768 availability?
David Charlap wrote: I think an OC-192 network using 56K modems in the core would be a pretty obvious giveaway as well. Yes! Sheesh. Nobody uses K56Flex any more. Peter E. Fry
Re: Bogon list or Dshield.org type list
[EMAIL PROTECTED] wrote: [...] other people could look in their netflow data for traffic from bogon addresses to your destination. Do other people need such a list to discover invalid source addresses emerging from their networks? [...] the owners of compromised machines used to initiate DDOS attacks will begin to secure their machines the way they should have in the first place. Given. The issue of securing networks has been covered here -- I'd've figured it would have been worked into this issue as a given, for all that it makes tracking attacks in the above scenario a tad more challenging. Peter E. Fry
Re: verio arrogance
Brian Wallingford wrote: [...] 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. Interesting. Looking around, it seems that Verio allocates /24 and larger (all I saw offhand were /24s and /23s) address blocks for customers from the Class C space. Can't fault 'em for consistency. Peter E. Fry
Re: verio arrogance
Daniel Golding wrote: RADB is largely meaningless, in terms of authorization or authority to advertise. However, if you have a properly delegated SWIP entry for the block, few providers will request LOA. Those who do, should probably be avoided. Largely? I like to see the SWIP, but it's not always provided. Regardless, I want to see an announcement originating from my customer directly to the owner of the block. De facto authorization. [...] Peter E. Fry
Re: RADB mirroring
Ralph Doncaster wrote: RADB definately does not mirror (at least not daily) ARIN's RR. [...] Correct -- not at all. Can anybody speak toward the purpose of the ARIN RR? An IRR not mirrored by the RADB (to act as a member) and not mirroring every RR mirrored by the RADB (to hijack the top level) seems pointless. I've been meaning to try to dig up a contact (from a customer), but haven't had a chance... Peter E. Fry
