cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
36524
Views
53
Helpful
29
Replies

Pls explain SVI ACL source and destination direction

Hi I have a home network up and running well that uses a Cisco 1801.

I am just trying to increase my understanding of some it's config and I'm confused by ACLs on a VLAN interface.

Ok so I 'be the router' and imagine packets flowing to me and from me

I have two VLANs configured

VLAN 10 - 10.10.10.0 / 25

VLAN 20 - 10.10.10.128 /27

So for example, one of my Virtual Machines has an address 10.10.10.6 and is on VLAN 10.

Another has an address of 10.10.10.134 and is on VLAN 20.

I want to allow 10.10.10.6 access to 10.10.10.134, but prevent other VLAN 10 devices access.

So I create an ACL and apply it inbound of interface Vlan 20.

The config below works as desired, but I don't understand why.

If the packet filtering is for the inbound direction of the interface, then my logic would state that the source address of the packet to be filtered would be 10.10.10.6, not 10.10.10.134.

Can someone help me understand. Thanks.

interface Vlan20

ip access-group ACL-INBOUND in

!

ip access-list extended ACL-INBOUND

permit ip host 10.10.10.134 host 10.10.10.6 log-input

29 Replies 29

As Jon explained there is really no difference with ACL on SVI or physical port.

What you need to understand though is that if you have 10 clients in the same VLAN on a switch. When these clients communicate the traffic never passes the SVI. The switch simply forwards the frames based on the destination MAC address. If you want to filter traffic within a VLAN you need to use a VLAN ACL (VACL).

The only traffic that goes through the SVI is traffic leaving or arriving to the VLAN. Meaning that the traffic was routed. If a client in say VLAN 10 wants to communicate with a client in VLAN 20 then the VLAN 10 client will ARP for its gateway. Encapsulate the frame with SRC IP = Own IP, DST IP = VLAN 20 client, SRC MAC = Own MAC and DST MAC = GW MAC. This frame will arrive at the SVI and inbound ACL will be checked. The packet is routed and delivered to VLAN 20. Outbound ACL is checked there. Return traffic arrives inbound at SVI for VLAN 20 and inbound ACL is checked. Traffic then returns to SVI for VLAN 10 and outbound ACL is checked there.

You can think of it as two cities with a bridge between them. To go to the other city one must travel over the bridge. The bridge has guards at both sides. The bridge is the SVI. The guards represent the ACL. So there is both inbound and outbound check.

Daniel Dib
CCIE #37149

Please rate helpful posts.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

Hi Daniel,

If you want to filter traffic within a VLAN you need to use a VLAN ACL (VACL).

Wouldn't a port ACL block traffic between 2 devices in same vlan as well as between devices in different vlan too  ?

Regards

Alain

Don't forget to rate helpful posts.

Don't forget to rate helpful posts.

Alain

Hope you don't mind me answering.

A port acl could block traffic between devices in the same vlan but they are often limited by the fact that they are only allowed in an inbound direction. So if you had a host connected to that port and you wanted to stop a certain set of IPs from sending any traffic to that host you couldn't do it. In addition it would not be possible, using port acls. to block things like multicast/broadcast traffic within the vlan going to that host.

You could write the acl so that it stopped the host from sending any return packets to those IPs but sometimes that is not enough and you need to stop any packets actually being sent to the host. I suppose you could then argue that you can apply a port acl to each of the IP's ports inbound but that would become a configuration headache if there were a large set of them.

They are generally just not as flexible as either acls applied to the SVI for inter vlan traffic or VACLs within a vlan.

Jon

Jon,

of course you are welcome to answer.

Yes it is less scalable and not applicable in some situations but I just wanted to stress that it was not technically mandatory to use a VACL but you're right explaining the restrictions I omitted to mention( end of the year now so I'm a little bit tired    )

Regards

Alain

Don't forget to rate helpful posts.

Don't forget to rate helpful posts.

That doesn't explain why the SVI's address is subject to the ACL rules when it is an address which is on the same street as traffic that may want to use the bridge to cross to another network.

The traffic isn't leaving or arriving to the VLAN because it is on the same VLAN.

So I don't see why the following is necessary

ip access-list ACL-IN

remark allow all hosts access to gateway

permit ip host 10.10.10.1 10.10.10.0 0.0.0.127

"That doesn't explain why the SVI's address is subject to the ACL rules  when it is an address which is on the same street as traffic that may  want to use the bridge to cross to another network."

As Peter stated above, it's like a router. Think of the SVI as a separate router. You have two of them. If you had two routers and you wanted to block traffic between them, you would use an acl on the one that you want to block traffic from. The SVI is the same concept in that if you want to block intervlan traffic, you would use an acl because all traffic leaving that vlan that needs to be routed, will use the SVI as its default gateway.

With intravlan traffic, traffic that stays within the vlan as in host to server on the same subnet, will not have to go to the SVI to be routed, so that's where VACLs come in as mentioned by Daniel above.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

But the SVI address is on the same VLAN as the other devices so conceptually, no traffic is entering or exiting that VLAN when devices want to access the SVI.

Say a ping from a server to the SVI.....In my mind, this traffic virtually is not leaving the VLAN....Physically yes, it has to leave a server NIC and arrive into a switch port, and then from another switch port it travels out to the router.....

I'm not trying to be difficult and appreciate your explanation.

Is it better to think that the traffic is all on the same virtual LAN which is not subject to ACL control (unless using VACLs) but when it comes to accessing the gateway address (the actual router) the router can control traffic that is coming into and leaving it so it does have control over this?

It is the same as you would see on a physical interface.

If you ping any host within the same vlan then the traffic does not go to the SVI as you say.  If you ping a host in a different vlan then traffic does go via the SVI so the acl is applied (as long as the acl is applied inbound).

If you ping the SVI of the vlan from a host in the same vlan then the acl (in an inbound direction) is applied to the traffic. So the acl applied inbound filters traffic both going through the SVI to a remote destination and to the SVI IP itself.

If the acl was applied outbound then the above statement would not be true and you would be able to ping the SVI from a host in the same vlan.

Jon

With intravlan traffic, traffic that stays within the vlan as in host to server on the same subnet, will not have to go to the SVI to be routed, so that's where VACLs come in as mentioned by Daniel above.

Are VACLs a Cisco thing or are they IEEE standardised and work on any L3 switch?

Thanks for all the help everyone...I have a much better understanding of ACLs.

I'm a bit confused by your statement. In your first example you had a deny statement and nothing after that. There is always an implicit deny at the end that blocks everything not permitted. So if you put a deny statement and nothing after that then all traffic will be blocked.

You don't need to permit traffic to the SVI for routing to work. Clients would still be able to communicate as long as that traffic is permitted. If you want to be able to ping the gateway then traffic must be allowed towards the SVI.

Daniel Dib
CCIE #37149

Please rate helpful posts.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

You don't need to permit traffic to the SVI for routing to work.

This is what doesn't make sense for me as I would say the same as you, but this is not how it works for me whenever I apply an ACL to a VLAN.

Devices that are connected to the L2 switch cannot route to other VLANs on the switch until I explicitly permit access to the SVI address of the router for all addresses in that VLAN's subnet, by setting previously mentioned statement on the Cisco router.

Hmm,

That is not the behavior I see. This is before putting any ACL, 10.0.0.1 and 20.0.0.1 is IP of GW, 20.0.0.3 is a host in VLAN 20.

R1#ping 10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#ping 20.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#ping 20.0.0.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.3, timeout is 2 seconds:

!!!!!

Everything is reachable. Then I configure ACL on SVI for VLAN 10.

SW1(config)#ip access-list extended DENY_PING_TO_SVI

SW1(config-ext-nacl)#deny ip host 10.0.0.11 host 10.0.0.1

SW1(config-ext-nacl)#permit ip any any

SW1(config-ext-nacl)#int vlan 10

SW1(config-if)#ip access-group DENY_PING_TO_SVI in

R1 can't ping 10.0.0.1 but 20.0.0.1 and 20.0.0.3 still works.

R1#ping 10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

R1#ping 20.0.0.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

R1#ping 20.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

SW1#sh ip access-lists

Extended IP access list DENY_PING_TO_SVI

    10 deny ip host 10.0.0.11 host 10.0.0.1 (5 matches)

    20 permit ip any any (5 matches)

It's strange that we see different behavior. What platform and OS version are you running?

Daniel Dib
CCIE #37149

Please rate helpful posts.

Daniel Dib
CCIE #37149
CCDE #20160011

Please rate helpful posts.

Can you post the exact config for this ?

Note also indicate whether the acl is applied inbound or outbound.

Jon

The ACLs are applied inbound....

I will post up the config.

Oh and to answer Daniel again.

The router is an 1801

Cisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 15.1(4)M5, RELEASE SOFTWARE (fc1)

Thanks Daniel...I will try to look into this again as my config could be wrong somewhere.

I will isolate whether the problem only occurs with the ESXi virtual machines in my environment which could be a misconfiguration of the virtual network settings or whether a physical device plugged into the switch exhibits the same behaviour.

I will get back to you.

Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: