VLAN ACL's (CCNP Switch)

[EricNL]

Mannen,

Vandaag helaas nét gezakt voor CCNP Switch (730 punten waar 790 nodig was) en één van de simulaties waar ik moeite mee had bevatte VLAN ACL's. Nu heb ik de simulatie die ik in het examen kreeg toevallig ook in één van m'n VCE's zitten, maar als ik daar de uitleg/config lees snap ik hem gewoon niet.

Even een samenvatting van het scenario/vraagstuk:
- Devices on VLAN20 are restricted to the subnet of 172.120.40.0/24
- Packets from devices in the subnet of 172.120.40.0/24 should be allowed on VLAN20.
- Packets from devices in any other address range should be dropped on VLAN20.

In dit geval mocht een simpele ACL niet toegepast worden en moest er echt VACL's gebruikt worden.
Als ik de config bekijk in het antwoord is het als volgt:

code:

SW1(config)#ip access-list standard 10
SW1(config-ext-nacl)#permit 172.120.40.0 0.0.0.255
SW1(config-ext-nacl)#exit
SW1(config)#vlan access-map PASS 10
SW1(config-access-map)#match ip address 10
SW1(config-access-map)#action forward
SW1(config-access-map)#exit
SW1(config)#vlan access-map PASS 20
SW1(config-access-map)#action drop
SW1(config-access-map)#exit
SW1(config)#vlan filter PASS vlan-list 20

Misschien staar ik me nu blind omdat het net na het examen is, maar wat ik niet begrijp is waarom je twee verschillende entries maakt voor een VACL. Corrigeer me a.u.b. als ik het ergens verkeerd heb, maar ik lees het nu als:
- Je maakt 1 standaard ACL aan waarin je het subnet benoemt wat ge-allowed moet worden
- Je maakt een VACL (VACL = Vlan Access Map?) waarin je een allow actie koppelt aan een standaard ACL
- Je maakt nog een VACL waarin een generale drop actie wordt geplaatst
- Vervolgens pas je de VACL toe op een VLAN (dus niet op een logische/fysieke interface).

Is een VACL dus gewoon eigenlijk een wat uitgebreidere ACL waarin je sets van criteria en acties kan maken en die in totaal toe past op een VLAN?

Zou dan een "deny any" niet kunnen in de standaard ACL zodat de 2e VACL entry (action drop) niet nodig is?

Wellicht is het een stomme vraag, maar ik heb tot nu alles m.b.t. "maps" (routemaps, vlan access maps) een beetje geprobeerd te ontwijken omdat ik het gewoonweg niet begreep.

[ipsec]

Volgens mij is een Standard of Extended ACL alleen van toepassing op inbound en/of outbound packets op routed interfaces in tegenstellig tot een een VACL die van toepassing is op álle traffic. Zodoende hoeft verkeer die een VACL raakt niet eens over een router heen te gaan, je kan simpelweg toegang weigeren zonder dat de source de router raakt.

Als een packet gerouteerd wordt tussen 2 VLANs wordt er standaard eerst gekeken naar een Standard of Extended ACL op de routing interface, eventueel daarna dan het VACL waarna vervolgens het VACL van het destination VLAN wordt toegepast en daar vervolgens weer het ACL.

Komt er een beetje op neer dat een VACL gebruikt wordt om verkeer binnen een VLAN te beheersen en een ACL tussen routed interfaces.


Edit:

Overigens is de standaard regel van een VACL deny. Daarom maken zij eerst een allow regel aan voor het betreffende subnet, en verder een deny op "de rest".

[ Voor 31% gewijzigd door ipsec op 19-09-2016 13:58 ]

[anboni]

SuperKevin schreef op maandag 19 september 2016 @ 13:48:

Overigens is de standaard regel van een VACL deny. Daarom maken zij eerst een allow regel aan voor het betreffende subnet, en verder een deny op "de rest".

Ik vind het over het algemeen wel prettig om alle impliciete denies alsnog expliciet te definieren in m'n configuraties. Het doet technisch niets, maar maakt dingen visueel iets duidelijker. Misschien is dat hier ook de achterliggende gedachte?

[EricNL]

SuperKevin schreef op maandag 19 september 2016 @ 13:48:
Volgens mij is een Standard of Extended ACL alleen van toepassing op inbound en/of outbound packets op routed interfaces in tegenstellig tot een een VACL die van toepassing is op álle traffic. Zodoende hoeft verkeer die een VACL raakt niet eens over een router heen te gaan, je kan simpelweg toegang weigeren zonder dat de source de router raakt.

Als een packet gerouteerd wordt tussen 2 VLANs wordt er standaard eerst gekeken naar een Standard of Extended ACL op de routing interface, eventueel daarna dan het VACL waarna vervolgens het VACL van het destination VLAN wordt toegepast en daar vervolgens weer het ACL.

Komt er een beetje op neer dat een VACL gebruikt wordt om verkeer binnen een VLAN te beheersen en een ACL tussen routed interfaces.


Edit:

Overigens is de standaard regel van een VACL deny. Daarom maken zij eerst een allow regel aan voor het betreffende subnet, en verder een deny op "de rest".

Ah, dat verklaart in ieder geval een hoop. Alleen jammer dat ik niet kan testen met VACL's in GNS3. Bedankt voor de uitleg!

anboni schreef op maandag 19 september 2016 @ 14:10:
[...]


Ik vind het over het algemeen wel prettig om alle impliciete denies alsnog expliciet te definieren in m'n configuraties. Het doet technisch niets, maar maakt dingen visueel iets duidelijker. Misschien is dat hier ook de achterliggende gedachte?

Valt een beetje onder de ICT "tikjes" denk ik. Ik betrap mijzelf er namelijk vaak op dat als ik een stukje config in een IOS device zet ik altijd ff een paar keer op de Enter knop wil rammen, en het grappige is dat ik heel veel netwerkbeheerders dit zie doen . Soort van visuele bevestiging zeg maar...

[ipsec]

EricNL schreef op maandag 19 september 2016 @ 14:18:
[...]
[...]


Valt een beetje onder de ICT "tikjes" denk ik. Ik betrap mijzelf er namelijk vaak op dat als ik een stukje config in een IOS device zet ik altijd ff een paar keer op de Enter knop wil rammen, en het grappige is dat ik heel veel netwerkbeheerders dit zie doen . Soort van visuele bevestiging zeg maar...

Net zoals dat ik altijd 20x de running config save nadat ik klaar ben om er zeker van te zijn dat je bij een reboot van het device niet gigantisch de Sjaak bent