- Test - lists.nanog.org

BGP configuration checking tool: announcement and request for users/feedback
by Nick Feamster 09 Jan '04

09 Jan '04

Hi Nanog, As you may know, I've been developing a tool called "RoLex" (Routing Lexer) that performs various syntactic and conceptual checks on existing BGP configurations. (To refresh your memory, see: http://www.nanog.org/mtg-0310/feamster.html) The checker now parses Cisco and Juniper IOS and represents BGP configuration in an abstract format (in the form of relational database tables); the checks themselves are expressed as perl modules that run SQL queries against these tables. You can get more information about the tool itself, including the tests that the tool currently performs, at: http://nms.lcs.mit.edu/bgp/rolex/ (the code is in pre-release; if you would like to test it on your configurations, please ask me and I'll give you a version.) Part of our motivation for developing this tool is to get a better understanding of errors and anomalies that turn up in real configuration files. A couple of very kind, generous folks at some larger ISPs have given me some initial assistance by letting me run the tool on some of their configuration files, and, in some cases, our checks have allowed operators (and me) to see some interesting things. (read: you might find some things you didn't expect) Nevertheless, our study (and the tool) will benefit tremendously by exposure to configurations from a much wider variety of ASes. (The more, the better.) If you could help me in any of the following ways, I would be extremely grateful: 1. Run the tool on your configuration and let me know what types of errors you find. This will help me in our analysis as far as figuring out what types of problems are most common, etc. If you're feeling extremely helpful, you could let me run the tool on your configuration files for you. This would probably save you time; of course, I'd discuss with you what I found in your configs. (Yes, I am asking to look at your configs; I'm amenable to nondisclosure arrangements regarding keeping keeping your configuration data private, if you like.) 2. Suggest new tests that you would like to see incorporated into the tool. I am eager to provide the tool for you to try on your configuration files. I'm also more than willing to help you set it up in a way that works well for you. In return, I would hope that you would help me better understand the errors/anomalies that the tool turns up or at least give me some suggestions on how to improve the tool (e.g., what types of checks you would like to see added to the tool, personal experience, etc.). Please let me know if you are interested in helping out. Thanks! Nick

1 0

New Statistics Format Available
by Ginny Listman 08 Jan '04

08 Jan '04

On 5 January 2004, the Regional Internet Registries (APNIC, ARIN, LACNIC, and RIPE NCC) implemented a new standard file format for reporting the current state of Internet resource allocations and assignments for: - IPv4 address ranges - IPv6 address ranges - AS numbers The new file format, now available from all RIRs, ensures consistency and makes it easier for users to integrate and analyze data from different sources. The reports contain a snapshot of the status of Internet number resources, without any details of transaction histories. They are produced daily and include: - Information summaries - GPG key signatures - MD5 checksums for verification Statistics files ---------------- The latest statistics files are available from the RIR sites listed below. Each RIR site also mirrors the files of the other RIRs. ARIN ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest APNIC ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest LACNIC ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest RIPE NCC ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest More information ---------------- ARIN ftp://ftp.arin.net/pub/stats/arin/README APNIC http://www.apnic.net/db/rir-stats-format.html LACNIC ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest RIPE NCC ftp://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt Regards, Ginny Listman Director of Engineering ARIN

1 0

RE: GSR, 7600, Juniper M?, oh my!
by Michel Py 08 Jan '04

08 Jan '04

> Richard A Steenbergen wrote: > I already have a very nice empty M160 > chassis for a chair at the colo, I don't like it for a chair, too high (29"); A 7500 is a lot better for that use. It's really nice as a heater too, particularly a dual AC loaded with legacy blades. Other possible uses for a 7500 include a temperature sensor (http://arneill-py.sacramento.ca.us/mrtg/router-temp.html) My views on the original question: Cisco vs. Juniper: Whatever some people might say, everyone that uses both will tell you that the real picture is not Cisco=100% crap and Juniper=100% perfect :-) Besides, if you're a Cisco shop it's hard to find sound arguments to have only one or two Junipers (common business sense: twice the training, each one rejecting responsibility on the other, more difficult to find JunOs experts than IOS experts, etc...). 7600 vs. GSR: These are not the same boxes. There is stuff that the 7600 won't do, but there's also stuff that the GSR won't do in terms of aggregating a bunch of disparate links together. Michel.

8 9

GSR, 7600, Juniper M?, oh my!
by bcm 08 Jan '04

08 Jan '04

Hello all, I'm faced with a difficult decision. I work for a large multi-node regional ISP (and Cisco shop). In our largest nodes we've found the Cisco 7500 series routers to be at the end of their useful life due to the throughput generated by POS OC-3 feeds and 10,000+ broadband users whose traffic needs to be moved out of the node. Short of building a farm of 7500's the need to upgrade seems clear. But where to go? The Cisco GSR platform seems a logical choice, but their new 7600 series units are attractive for their cost. Juniper may also have a place at this end of the processing spectrum. I'd also like to ensure that the new platform supports doing CAR and ACLs at line rate, given the client base. I wanted to see what other operators in this situation have done, so I would appreciate anyone's input or insight into the pros and cons of these platforms or any other ideas as to how I can grow beyond the Cisco 7500.

12 14

Re: Upcoming change to SOA values in .com and .net zones
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>I worry especially when I can not clearly see a benifit to either cat >or mice. The current serial number format supports a maximum of 100 changes to the .com zone per day. If you store your zone as text files on a hard drive that is more than enough. But! What if you consider the zone to be a database and maybe even store it in RAM? In that case, you could update the zone every single time one of the .com entries is added or deleted. The performance impact of doing this to a zone stored in RAM is approximately nil. However, the DNS protocol requires a serial number that changes every time the zone changes. So the first step is to change the way a zone serial number is created. Then you deploy a DNS server architecture that runs entirely out of RAM. And then when all of this works smoothly, you start to increase the number of updates per day until you're doing it every 15 minutes or so. Then, finally, you go live with real-time updates. In fact, with the speed of today's hardware and RAID arrays it's probably worthwhile to do this even without holding the whole zone in RAM. Now do you see why changing the serial number would clearly benefit the cat? And can you see how this would even lead to possible future benefits for many of us mice? If you are going to attack Verisign, at least pick a weak point to target with your attack. --Michael Dillon

2 1

Wirespeed 24-port L3 switches
by variable＠ednet.co.uk 08 Jan '04

08 Jan '04

Hi all, We're looking at L3 switches which have decent L3 packet forwarding performance (wirespeed if possible), a reasonable amount of L4 ACLs/ACEs (an average of at least 80 per port) and comes in a 24-port 10/100 port package with a couple of GBIC slots for uplinking to the core network. OSPF, but no BGP. We've looked at the Cisco 3550-24, but they seem to have "resource exhaustion" issues[1] if you create more than 8 SVI's (i.e. it goes back to software routing). Extreme 200 switches look OK, but are limited to about 1000 ACE[2] (averages 32 rules per port). Allied Telesyn's 8800/Rapier series currently only manage half that figure in hardware and don't support UDP/TCP port ranges in a single ACE[3]. Are our expectations of a 24-port switch too high? Would it be better to move over to higher density switches and put in large amounts of underfloor cabling in large installations and keep putting separate routers and switches into the smaller locations (<100 ports)? Or are L3 switches not a mature product and we should all stick to using switches for L2 and have L3+ dealt with by dedicated routers for the time being? Cheers, Rich [1] http://www.cisco.com/warp/public/473/145.html [2] http://www.extremenetworks.com/libraries/prodpdfs/products/summit200_24_48.… [3] They do support ranges, but a rule to cover a single range may require multiple ACEs.

2 1

Re: Upcoming change to SOA values in .com and .net zones
by Michael.Dillon＠radianz.com 08 Jan '04

08 Jan '04

>No, they are not learning. At least this is not what their CEO says: http://www.redherring.com/Article.aspx?f=articles/2003/12/14c9995f-5557-4dc… After reading that article I got curious about who Overture is. A quick search on Google got me this article: http://www.internet-marketing-research.net/overture_click_fraud.php And in case you think that perhaps the Red Herring writer only used Overture's rates as an example, here's another article that confirms that Overture did have a deal with Verisign's Sitefinder project: http://www.internetnews.com/bus-news/article.php/3080071 Verisign and its CEO are looking slimier and slimier... Thankfully, it is highly unlikely that the .com boom will ever make a comeback. Marketing and advertising people and investors are beginning to understand what works and what doesn't on the Internet. I expect that Sitefinder will return but that a lot of browser software and ISPs will divert the misspelled URLs to a local spelling checker. Sitefinder version 2 will die a quick death because it won't get enough clicks and most of the ones that it does get will be nuisance clicks. --Michael Dillon

1 0

RE: Upcoming change to SOA values in .com and .net zones
by McBurnett, Jim 08 Jan '04

08 Jan '04

RFC 2182 Section 7 covers this as Randy Bush mentioned earlier.. If They do serial # updates, in a scripted manner or they just change the serial number to 40000000 let it propagate and then change to 1000000 something all will be fine... The RFC above explains it well, no need to repost here.... Jim > > ... and not as YYYYMMDDHHMMSS or any contracted version thereof! Right, but, the _OLD_ format is. Therefore, the old zone file prior to the conversion will be SN 2004020800 through 2004020901. After the change, the SN will be in the range 1076284800 through 1076371200 inclusive. This complete range is less than 2004020800, so, the serial number will, indeed, be going backwards at the time of the change. This should only matter to things doing automated zone transfers and a forced manual zone transfer should solve the problem. Presumably, the responsible TLD operators are being coordinated with to take the necessary steps. Anyone else doing zone transfers of COM and NET has now been warned and should take appropriate action. Owen

1 0

Re: GSR, 7600, Juniper M?, oh my!
by neil＠DOMINO.ORG 08 Jan '04

08 Jan '04

> There still is the issue of cost though. GSR line cards are not cheap. Hence my point about them not being an access router :-) > I would put 10mbps Ethernet and possibly DS3 in the same pool as E1/T1 > though; this still remains in the realm of things a 7500 does fine. I'm > not trying to defend the 7500 platform, it's obsolete all right. > However, free is music to my ears. 10meg ethernet yes, DS-3 depends on whether you own the telco side as well. Neil.

2 2

Re: Upcoming change to SOA values in .com and .net zones
by Frank Louwers 08 Jan '04

08 Jan '04

On Wed, Jan 07, 2004 at 11:34:46PM +0000, Maarten Van Horenbeeck wrote: > Hi Frank, Dag Maarten, > > stuid question, but isn't 2004010101 (today) > 1076370400 (9 Feb 2004)? > > This doesn't apply here. It is perfectly possible to decrease the value > of your serial number without any consequences for the DNS slave/master > zone transfers, if you adhere to the procedures put forward in RFC 1912 > (section 3.1). The fact that the newly introduced serial is lower will > thus not have any consequences from this perspective. Yes, but we all know there are quite some non-compliant dns-servers out there. Do they want to break the largest zone for a few days for all non-compliant servers? Oh, wait, right, they don't care if they break stuff... Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium

5 5