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