At 11:41 PM -0500 12/31/01, Cisco Cisco wrote: >Howard, >Most ISPs today just use "service compression" to >compress the configuration when the configuration is >to big too fit into NVRAM. I would not expect you to >know that seeing as you do not really work on routers.
Dear Troll, Apparently, you haven't been doing it for long either, since compression has its limits -- as evidenced by the error message "##Configuration too large to fit uncompressed in NVRAM Truncate configuration? [confirm]". I repeat: there are tier 1 routers that cannot hold the necessary access lists in NVRAM. There are several workarounds to this problem, primarily distributing the filtering to the edge with customer-specific access lists, and unicast reverse path verification. At best, these solve filtering, not table churn, which requires other methods. Nevertheless, there are considerable concerns in the IETF and IRTF about the long-term scalability (over 3-5 years) of such methods, and there's active work in defining the generation of routing paradigms beyond BGP. See the IRTF-RR requirements draft, the activities of the PTOMAINE working group, the Future Domain Requirements team, etc. Incidentally, participants in all these groups argue technically in public forums, but they sign their names. > > >Being a network engineer in the real world is >different than writing about it. You seem to be just >like some of the professors I had in college. Talk all >day about a topic in the classroom but didn't know how >it really works in the real world. > >I may not be a high level Cisco guru but I know enough >to know when someone is just spewing hot air. Why am I not surprised you are not a high level Cisco guru? I don't propose to get into a battle of wits with an unarmed, overconfident opponent, but I'll match the real-world networks I've implemented, the protocol code I've written, etc., anytime....or answer honestly when I don't know something. Apparently, I still believe I can learn every day, and thank people if they point out something I missed...as opposed to your "real world" knowledge that covers everything. For spiritual calm, you might meditate on the conflict between virtual private networks and real networks. Just in case you don't recognize it, that's humor. > > >>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=30603&t=30600 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
