[Nlnog] NIET nog es!

[Niels Bakker]

On woensdag, sep 17, 2003, at 23:09 Europe/Amsterdam, Boudewijn Visser 
wrote:

> 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.

Dat is er zeker wel.  Maar of het nu op process-niveau in IP Input 
wordt gedropt of op process-niveau in Virtual Exec maakt niet bijster 
veel verschil.  Pas als je het op interrupt-niveau kan doen (CEF/dCEF - 
wat verplicht is voor "ip receive-acl") ga je verschil zien.


> Maar ik zou dus gedacht hebben dat die feature gewoon gebouwd zou zijn 
> als normale access-list.

Zoals ik al schreef, er wordt nauwelijks magic juju gedaan met het 
optimaliseren van access-lists, voor zover ik weet.  "ip receive-acl" 
is een stukje implicit access-list dat bij elke interface applied wordt.

Volgens mij herordent JunOS geconfigureerde firewall filters ook om 
packets niet onnodig door het chassis te sturen.

[..]
> (next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ 
> etc).

insmod???  hoewel het voortdurende succes van Linux anders doet 
vermoeden, het tijdperk van monolithische kernels is eigenlijk wel 
over.  Hier zou je geen goed cijfer voor krijgen van de heer Tanenbaum.

Juniper doet het al vrij goed met hun strikte scheiding tussen control 
en forwarding planes


>>> (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 ....

Alleen nauwelijks met layer 3.  We draaien de layer-2 only code op het 
produktieplatform.


>> 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?

Voor zover mijn informatie reikt zullen packets die geblokkeerd worden 
door "line vty 0 4 / ip access-class 1 in" door de CPU gedropt worden - 
zeker in de L2 only code voor BigIron.  Daarom maak je de management 
interface ook niet algemeen beschikbaar (lang geleden hadden de 
switches gewoon IP-adressen in het peering LAN).


	-- Niels.

--