VACLs

So; it seems 2950's don't support VACL's, which sucks a bit since I'm having a bit of trouble understanding them. I'll copy the example from the official cert guide (page 227) for discussion.

Cat3550(config)# access-list 100 permit tcp any host 10.1.1.2 eq telnet
Cat3550(config)# vlan access-map ALLOWTELNET 10
Cat3550(config-access-map)# match ip address 100
Cat3550(config-access-map)# action forward
Cat3550(config-access-map)# exit

Cat3550(config)# vlan filter ALLOWTELNEt vlan-list 1-100

line 1 I get; it's standard extended ACL format.
line 2 I don't entirely get; you're making an access-map named ALLOWTELNET, but why is the 10 needed?
line 3 I sortof get; you're matching ACL 100 to your access-map (although I have to ask how it works if your ACL has multiple lines; do they all get applied?)
line 4 I sortof get; it specifies what to do with frames that match the statement(s?) from line 3 (making the permit from line 1 unnecessary? could it have been deny with no difference?)
line 5. duh.
line 6 is fine; you're just assigning the access-map to vlans 1-100.

Can anyone explain the problems I'm having understanding line 2 mainly, but also lines 3 and 4 to a lesser extent?

[EDIT for 2nd example begins here]

A second example, found here makes marginally more sense:

SW2(config)#ip access-list extended ACL_TELNETR1_R2
SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23
SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action forward
SW2(config-access-map)#exit

Line 1 creates a named access-list, and line 2 is pretty standard extended ACL format. No problems.
Line 3 creates an access-map again, but does NOT have a number at the end. ???
Lines 4 and 5 I think match lines 3 and 4 in the previous example (so the order doesn't matter?)
Lines 6 and 7 are like 4 & 5, but in reverse order, so I guess the order doesn't matter; but how would the IOS know which action to put with which match if the order doesn't matter? I guess it's not too difficult: match if it's waiting for a match, or make a 'wait for match' condition if not.

Find more posts tagged with

Comments

stuh84

bermovick wrote: »
So; it seems 2950's don't support VACL's, which sucks a bit since I'm having a bit of trouble understanding them. I'll copy the example from the official cert guide (page 227) for discussion.
Cat3550(config)# access-list 100 permit tcp any host 10.1.1.2 eq telnet
Cat3550(config)# vlan access-map ALLOWTELNET 10
Cat3550(config-access-map)# match ip address 100
Cat3550(config-access-map)# action forward
Cat3550(config-access-map)# exit

Cat3550(config)# vlan filter ALLOWTELNEt vlan-list 1-100
line 1 I get; it's standard extended ACL format.

Yep, nothing more to say on that

bermovick wrote: »

line 2 I don't entirely get; you're making an access-map named ALLOWTELNET, but why is the 10 needed?

That would be sequence number 10 in that particular access map, so it starts with the one numbered 10, then if you did one thats number 20, anything that didn't match term 10 would be evaluated by term 20

bermovick wrote: »

line 3 I sortof get; you're matching ACL 100 to your access-map (although I have to ask how it works if your ACL has multiple lines; do they all get applied?)

Yep, that should be the case

bermovick wrote: »

line 4 I sortof get; it specifies what to do with frames that match the statement(s?) from line 3 (making the permit from line 1 unnecessary? could it have been deny with no difference?)

Theres a couple of actions for it, basically one of them will allow the traffic, another will forward it to another port, the other will deny it. The forwarding to another port is especially awesome.

bermovick wrote: »

line 5. duh.
line 6 is fine; you're just assigning the access-map to vlans 1-100.

Can anyone explain the problems I'm having understanding line 2 mainly, but also lines 3 and 4 to a lesser extent?

I take it you've not done the ROUTE exam yet? This is part of the reason why I always advise going for the Routing before the Switching, because simply put, a VLAN access map is configured almost exactly like a route map. If you know route maps, VLAN access maps look like childs play compared.

Edit: Just saw your example. The reason no number is specified at the end is because it's going to use the default term number (which I believe is 10 anyway), as theres only on term so its not necessary to specify it. However if you have 2 or 3 you want to apply to the same VLAN, then you can do it all in one map.

bermovick

Originally Posted by bermovick
line 2 I don't entirely get; you're making an access-map named ALLOWTELNET, but why is the 10 needed?

That would be sequence number 10 in that particular access map, so it starts with the one numbered 10, then if you did one thats number 20, anything that didn't match term 10 would be evaluated by term 20

so the access-map has sequence numbers also; in example 1 it's listing 10 for completeness, while the second one let's it generate the default sequence numbering (10 and 20 I think)?

And then if need be I could create something like

vlan access-map ALLOWTELNET 9

if (for some reason) I needed to have something tested with a higher priority?

Does the entire access-map get tested for every segment, until something matches similar to regular ACL's?

stuh84

bermovick wrote: »
so the access-map has sequence numbers also; in example 1 it's listing 10 for completeness, while the second one let's it generate the default sequence numbering (10 and 20 I think)?

And then if need be I could create something like
vlan access-map ALLOWTELNET 9
if (for some reason) I needed to have something tested with a higher priority?

Does the entire access-map get tested for every segment, until something matches similar to regular ACL's?

Yeah thats how you'd do it, say you wanted something in that list which blocked all ICMP first, then you'd set up an access list to do that, and do a vlan access-map ALLOWTELNET 9 and it would.

Also, you are right with the last part, every term gets evaluated along the way to see if there is a match.

bermovick

Thanks; your explanations are REALLY helpful & I'll give you +rep in a bit for it!!!

One more question and I think I'll have it.

I'm not clear how the implicit deny at the end of ACL's affect the VACL. The cert guide says all other traffic in it's example is dropped because of the implicit deny, but the CCIE blog example suggests otherwise:

Notice that the ACL that matches on the Telnet has an action of DROP, then we match on all other traffic (implicitly), and we forward all of that. Forward is the default action, so I actually did not need the action forward commands, but I added them above to make it more clear for us to learn.

Is the implicit just the opposite of whatever is explicitely stated?

bermovick

Also your edit on your first reply threatens to confuse me again!

The reason no number is specified at the end is because it's going to use the default term number (which I believe is 10 anyway), as theres only on term so its not necessary to specify it. However if you have 2 or 3 you want to apply to the same VLAN, then you can do it all in one map.

I'm not clear exactly what you mean here; are you saying that since the access map only has a single match, there was no need to define it a sequence number ("term?")? I hope so or else you've lost me. If you can give an example on what you mean by the second line, it might make what you mean clearer.

peanutnoggin

I think Stuh is saying... If you do not specify a sequence number, the IOS will automatically start at 10. The author uses the number to give you a visual. Now, if you created your access map and started with the sequence of 20, the next line you add would then be 30, then 40, then so on and so forth... hopefully I didn't confuse you more.

-Peanut

stuh84

peanutnoggin wrote: »

I think Stuh is saying... If you do not specify a sequence number, the IOS will automatically start at 10. The author uses the number to give you a visual. Now, if you created your access map and started with the sequence of 20, the next line you add would then be 30, then 40, then so on and so forth... hopefully I didn't confuse you more.

-Peanut

Yeah exactly, so if you wanted to either have your own number sequeunce (say rather than 10, 20, 30 etc, do 14, 18, 22) you can specify that, or if you just wanted to give yourself space to add more terms at a later date and not have to renumber, then you can specify something like term 50.

"Is the implicit just the opposite of whatever is explicitely stated?"

Yeah, implicit just means what automatically happens, unless you state otherwise.

bermovick

Hehe; I know the definition of the words; I just want to make sure that's how it works.

In example one since we have an 'action forward', anything not caught by it's match has the opposite done (drop).

In example two since we have an 'action drop', anything not caught by it's match has the opposite done (forward) --- the author states his 'action forward' at the end was unnecessary since everything else was already being forwarded.

That's the last of my confusion since example 1 has an implicit drop while example 2 has an implicit forward.

stuh84

bermovick wrote: »

Hehe; I know the definition of the words; I just want to make sure that's how it works.

In example one since we have an 'action forward', anything not caught by it's match has the opposite done (drop).

In example two since we have an 'action drop', anything not caught by it's match has the opposite done (forward) --- the author states his 'action forward' at the end was unnecessary since everything else was already being forwarded.

That's the last of my confusion since example 1 has an implicit drop while example 2 has an implicit forward.

I'll have to consult my BCMSN book for that one if I'm honest, as a contextual implicit action seems a little strange (its been a while since I studied VACLs I will admit). A quick google leads me to this statement

"I believe you are correct. If there is NOT a match statement, then the default behavior of the VACL is the forward traffic. If there is at least one match clause, then the default behavior will be to act like a normal ACL and add the implicit deny."

That would make sense in that case, but I'll try and confirm that one when I get home tonight.

bermovick

I just found that statement too after googling 'vacl implicit forward' haha, although that doesn't seem to quite match up with what the ccie blog posting says (not that I should assume that's correct either).

Here's the code again

SW2(config)#ip access-list extended ACL_TELNETR1_R2
SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23
SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action forward
SW2(config-access-map)#exit

From what that forum suggests, there should be an implicit deny because we have a match clause, in lines 4 and 5. Remember the author has said lines 6 and 7 were unnecessary.

I've grabbed my SWITCH book, but it's material on VACL's didn't help much; it was quite similar to the CCNA:Security's material on the same subject (there's a LOT of overlap!)

This is the problem of not having a 2960 or 3550 yet to test these things on I suppose.

stuh84

Yeah I dont have either myself, a friend of mine does though but I believe he's using it. I'll see if I can get hold of one to try it out.

Thinking about it, the Packetlife lab has 3550s and 3560s, Community Lab - Packet Life, might be worth checking on that to see what happens?

bermovick

19 minutes until my packetlife reservation. I'm actually a bit nervous lol.

bermovick

OK, my 1 hour lab was quite enjoyable. Here's my 3 labs (I actually did more, but I only started keeping track near the end; and then had to re-do two of them cause I didn't write down my notes the first time). The topology is simple; 3 routers (.1, .3 and .5) connected to switch .50) of 192.168.1.0/24 network.

All 3 labs have the same ACL:

ip access-list extended VACL_LAB_3
 permit tcp host 192.168.1.1 host 192.168.1.3 eq telnet

and obviously all have the same

vlan filter MAP vlan-list all

So I'm only going to show the actual access-map itself under each lab section.

Lab 1

vlan access-map R1_R3_TELNET_DROP 10
 action drop
 match ip address VACL_LAB_3

Expected results: inability for R1 to telnet to R3.
Actual results: No connectivity from R1 to anywhere (ping/telnet tested). I should have checked R5 to anywhere, although I'm guessing there was no connectivity there either.
Why?: implicit deny, either in the ACL or the access-map drops everything.

Lab 2

vlan access-map LAB2 10
 action forward
 match ip address VACL_LAB_3

Expected results: R1 able to telnet to R3. Other connectivity unknown.
Actual results: No connectivity from R1 to anywhere (ping/telnet tested). Again I should have checked R5 connectivity to other devices, but I'm thinking the entire network was broken.
Why?: Implicit deny again, and I'm thinking it's in the access-map NOT the ACL, since we forwarded the ACL.

Lab 3

vlan access-map LAB3 10
 action drop
 match ip address VACL_LAB_3
vlan access-map LAB3 20
 action forward

Expected results: Based on previous labs, R1-R3 telnet blocked, everything else allowed.
Actual results: R1-R3 telnet blocked, everything else allowed (ping/telnet tested). I should have (again) checked R5-* connectivity, but have little doubts it had connectivity.
Why?: unmatched action forward acted like an allow any any, allowing anything not blocked by previous match.

Based on the 3 labs, it looks like the implicit deny any any at the end of ACL's is ignored by the access-map, but the access-map has it's own implicit action drop at it's end.

Anyone disagree? I'm still not really certain; I felt a bit rushed, knowing I only had an hour to do what I could, but this is the conclusion I draw from the results of the 3 labs.