[Nlnog] NIET nog es!

[Boudewijn Visser]

> On woensdag, sep 17, 2003, at 21:07 Europe/Amsterdam, Boudewijn Visser
> wrote:
>
>> Een van de dingen waar ik eens van schrok was dat bij vendor C telnet
>> access-lists (access-class op vty lines), snmp access-lists etc
>> allemaal pas op de RP uitgevoerd worden.
>
> Niet zo raar.  Het gros van de produktlijn van Vendor C heeft 1 CPU
> voor alles, en het design van de software dat ze draaien is weinig
> veranderd sinds de AGS+, lijkt 't.

Het zou me niet verbazen als het code pad tussen vty access-class
en echte access-lists ook op single-CPU platformen dus anders is.
(En er ook op 1-CPU C platformen een performance verschil is).
Maar ik zou dus gedacht hebben dat die feature gewoon gebouwd zou
zijn als normale access-list.
Blijkbaar is het dus aan het betreffende proces gehangen.

>
> De vraag voor hen is: hoeveel implementaties van OSPF en BGP en IS-IS
> willen ze parallel onderhouden?  Het antwoord is uiteraard "Zo weinig
> mogelijk", wat een reden kan zijn voor een monolithic OS, maar
> misschien liggen de verschillende architecturen nu zodanig ver uit
> elkaar dat het lonend wordt om het IOS-roer fundamenteel om te gooien
> en er een echt OS onder te hangen met memory protection en andere
> nieuwerwetse fratsen van dien.

Ha, dat kan een leuke thread worden, IOS architectuur features en
het hoe & waarom , historische bagage etc.
(next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc).

Ik zou wel benieuwd zijn naar een beschrijving van cisco's software
development proces & infrastructuur.
Ze hebben een behoorlijk aantal geografisch verspreide teams, die
vzviw per team een bepaalde feature of driver supporten, over alle
versies en platformen.
Dan het enorme aantal versies die in principe allemaal gerecreeerd
moeten kunnen worden etc.
Beslist een niet trivaal source code versioning systeem, en build
omgeving.

[cue Larry McVoy en hoe uniek BitKeeper is, en hoeveel echt moeilijke
problemen er zijn bij wijd verspreide software ontwikkeling die mensen
niet zien ... ]

Vendor J lijkt (qua joblisting op de website) alle development
(nog?) centraal te doen. En heeft natuurlijk een stuk kortere historie,
zowel letterlijk als qua legacy platform support.


>
>> Ze  zijn dus niet geimplementeerd als onzichtbare access-lists die
>> overal op de linecard/VIP zitten, dat is pas het geval met de ip
>> receive-acl. (en de 'gewone' access-lists, natuurlijk.)
>
> Je zou denken dat als je ergens - waar dan ook - een access-list zet,
> het systeem slim genoeg zou moeten zijn om dit te vertalen in de juiste
> entries in de verschillende TCAM's en dergelijke, maar helaas is de
> techniek bij de meeste vendors nog niet zo ver.
>
> Om even een item van mijn wishlist te plukken: JunOS mist ook een
> `prefix-list me' die automatisch gevuld wordt met alle adressen van
> alle lokale interfaces.
>
>
>> (Niels, hoe zit 't met vendor F bv ? )
>
> (welke Niels?) Daar kon je lang maar beter geen incoming access-lists

Die Niels @ams-ix die wel ervaring moet hebben met vendor F ....

> doen (of waren het outgoing?) aangezien deze allemaal over de CPU
> gingen in plaats van in TCAM geprogrammeerd te worden.  De
> SSH-implementatie is gebaseerd op die van F-Secure, dus naar ik vermoed
> niet vatbaar voor de bug uit het begin van deze thread.

Maar wel het probleem dat elke access naar een lokaal IP adres (bij gebruik
als L3 device) hoe dan ook via de CPU loopt, met of zonder acl,of is
dat tenminste niet (meer) het geval ?

Boudewijn