> >Howard, >If you actually worked on a router in the real world >rather than just tell people you do, you would know >that Cisco has supported access-list remarks for some >time now.
Well, first, if you read exactly what I wrote, it might be pertinent. I wasn't saying specifically access-list remarks, or the description command. When I write protocol code in C, for example, I may very well put a page of comments in with a particularly tricky routine. I'm talking about large amounts of comments in the configuration files. There are operational routers in tier 1 providers today that have a large sign on their consoles, "DO NOT SAVE TO NVRAM". The reason for this is that their exceptionally complex access lists, route maps, quality of service commands, etc., result in configurations too large to fit in NVRAM. They _must_ be stored and loaded from TFTP servers. Organizations like this have to be very careful about the use of comments, even in loadable files. > >Oh I'm sure you're going to reply to this e-mail with >some stupid story like, "This reminds me when I was >talking to a developer at Apple about Mac OS 1.0 but I >had never really worked on an Apple" or some worthless >story like that. Why, thank you! Perhaps I can call upon your services in future to tell me what I will do in other matters, before I decide what I will do. > >Also do us all a favor and quit cross posting from >other mailing list. We don't want to see your replies >to the juniper and ccie mailing list posts. Cross >posting can be dangerous when you're on some of the >list the you are on.... wink, wink ;-) I'm afraid "the list the you are on" doesn't quite parse. I do not routinely cross-post. Presumably, you are using the editorial "we," and have reasons for anonymous posting. I'm not ashamed to use my name on IETF, NANOG, etc., lists, or on the RFCs and I-D's I've written with intense peer review. But thank you for bringing a bit of whimsy into a quiet day. > > >""Howard C. Berkowitz"" wrote: > >> >Yes, it does make simple tasks a little more >complicated. However, using >> >inverse masking can make complex tasks much easier. >> > >> >Take this issue. Say you are asked to filter access >to all odd 192.168.x.0 >> >/24 routes. >> > >> > >> >Your method. >> > >> >192.168.1.0 255.255.255.0 >> >192.168.3.0 255.255.255.0 >> >192.168.5.0 255.255.255.0 >> >FAQ, list archives, and subscription info: >> >> >> I see your approach, Marc, and I have even >encountered real-world >> situations where such filtering might be >appropriate. It happened >> when an enterprise wanted to "leave room for >expansion", but didn't >> understand summarization. They assigned >odd-numbered subnets to >> different sites/areas, thinking the even ones would >be for future use. >> >> My approach, incidentally, is to figure out the >number of potential >> areas or sites, then divide by a power of 2, at >least 4, to be >> summarization-friendly. >> >> There's no question that your approach takes fewer >lines of code. >> Personally, I wouldn't use it except in a huge >network where there >> was no other way to fit that many lines into NVRAM. >> >> My motivation for not doing so is maintainability. >The more complex >> the mask, the more difficult it will be for some >subsequent >> administrator to figure out what was being done. I >might be more >> open to the idea if Cisco saved comments with the >configuration, but, >> of course, it doesn't. >> >> >> > > >__________________________________________________ >Do You Yahoo!? >Send your FREE holiday greetings online! >http://greetings.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30501&t=30473 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
