ACL applied to Vlan interfaces

I have been working with access lists for a while now and i think i have a good knowledge about them. But the thing i'm still confused with is when you apply ACL "in" and "out" to a SVI or lvna virtual interface.
It seems like in these type of interfaces the directions change completely compared to the normal interfaces (ethernet, serial... etc.) The logic is different and sometimes i find myself in problems when i have to do some troubleshooting in my work.
I've tryied to found some information or manuals on Cisco about this specific issue but unfortunely, i couldn't find anything clear.
Is there some method to quickly know when these ACL should be applied in one direction or another?
Thanks for your time.

It's no different on a SVI , "in" means coming in from the network (user ports) . "Out" means out towards the clients network.

Similar Messages

ACL's and VLan interfaces

I am trying to understand the boundries of a Vlan on a given switch. When a packet that is passed from Vlan int 1 to Vlan int 2 on the same switch if Vlan 2 has an inbound ACL denying this packet would it get acted upon in this manner or does the ACL only get introduced if the packet enters a physical interface.

A packet coming into a device from one interface and going out another interface does not pass two 'inbound' ACLs. It can pass two ACLs but one will be inbound and one will be outbound.
The situation is no different when you are using logical interfaces like SVI (L3 VLAN interfaces). In your case if you have an ACL defined inbound on VLAN 1 in the distribution switch then the packets coming into VLAN1 will be subject to inspection against the rules of this ACL. However, if there is no outbound ACL for VLAN 2 then packets leaving the distribution switch and going out of VLAN 2 to switch 2 will not be subject to any ACLs.
The concept of inbound and outbound is the same in case of both physical interfaces or logical interfaces.

ACL on Vlan interface

I am trying to apply an acl on my vlan interfaces that would allow the vlan to initiate tcp traffic. When I apply it I am unable to surf the web from the vlan but I can tftp from the vlan .

This is normal behavior. The first packet coming from the station on the VLAN would not be considered as established.
On the other hand, the established keyword could be configured on an outbound ACL applied to the same VLAN. This would only allow TCP traffic initiated from the VLAN to reenter that same VLAN.
Hope this helps,

VLAN interface on ME2600X

I'm trying to configure a VLan interface on my ME2600X (for inband management), but the switch won't accept the command.
What am I missing? I need a way to combine layer-2 services and a management vlan on the same dot1q trunk into the ME2600X.
Geir Jensen

Hello Geir,
You can use service instances e.g.:
interface GigabitEthernet0/3
switchport trunk allowed vlan none
switchport mode trunk
dampening
mtu 9100
load-interval 30
media-type rj45
service instance 5 ethernet
description Management VLAN
encapsulation dot1q 5
rewrite ingress tag pop 1 symmetric
bridge-domain 5 – this will pop up message:
Bridge-domain 5 created
VLAN 5 does not exist, creating vlan
interface Vlan5
description Management VLAN
ip address 10.0.0.1 255.255.255.0
ip access-group MNGT-ACL in
end
adam

Vlan Interface state constantly disabled

Hi.
I have a SF500 in layer 3 mode. I have 5 vlans (10,100,200,201,202)
Of these 5 vlans, each one has a vlan interface configured.
However, vlan 10 and 202 don't have an IPv4 route (which is created automatically I believe).
I had a look and the vlan interface state is set to 'Disabled' (yes I'm using the GUI...)
Whenever I click 'Edit', it brings up the new window, but it has a tick in the Enabled box. Unchecking and applying and then checking and applying makes no difference. I just can't seem to change the state of the vlan interface.
Am I missing something weird?
Cheers.
Andy

Hi.
Thanks forumers!!
Turns out that even thought it was assigned to an interface, the static route never appeared until the end device was connected (even if you tried to access that vlan from a different vlan).
For example, the internal interface vlan 1 (192.168.1.254) would never have a route added until a device appeared on a vlan1 port - even if a device on a vlan2 port had access to vlan1, it didn't recognise it as being valid.
Many thanks for your help!
Andrew

3750X - Dropped multicat traffic flooding on all switchport vlan interfaces

Hello forum,
I have a problem on source multicast blocking. I have a switch with a vlan interface (Ex. vlan 20 )and on that vlan interface an extended ACL is present. That ACL block specific multicast groups. Furtehrmore I have many switchport access interfaces on vlan 20 with different sources connected.
If one source start streaming with multicast destination IP blocked by ACL, dropped traffic is flooaded on all switchports on source's vlan
IGMP snooping on this vlan is enabled but seems that dropped traffic stay on L2 vlan without it.
Device used: C3750X
IOS: 15.0(2)SE5
Thank you for help

Hi Michal,
thanks for your reply!
Yes, probably i've captured all lines of access-list... but I've to change my approach because my access-list is a extended "named" access-list and, on other post, I've read that "named" access-list cannot be debugged...
Now i've deleted all access-lists entries that refer to vlan2 and I've created new one "numerical":
#ip access-list extended 100
#10 ip permit 172.16.2.0 0.0.0.15 any log
In this mode the debug shows only access-list 100 traffic + bcast + mcast.
But, the strange thing is another one now...
I've bought a multifunction printer, that send scanned document to a email account, the printer haven't internal smtp, it makes a connection to hp servers that forward scans to real destination address...
I was curious to find out how this connection works because, my private/confidential documents are send on internet and, i would hope that hp use a secure connection from my printer to its server...
Well, if I add "log" switch command at the end of access-list, or I enable access-list debug, the printer stop to comunicate to hp services/server... if I turn off debug or rewrite access-list without "log" feature, incredibly the printer re-start to comunicate with hp...
Have you any idea that explain that? I'm going crazy...

PING TO ACE VLAN INTERFACES

Hi,
I am not able to ping the VLAN interfaces defined on the ACE devices unless directly connected to the subnet.
I tried options - defining Access-list,service-policy.I can ping the servers behind the ACE but i cannt ping the ACE vlan interface.
I captured the traffic on the ACE.I cannt see any traffic on the interfaces if i ping the VLAN ip address.I can see the traffic if i am pinging the host behind the ACE.
Is there any option available to enable icmp on the interfaces.

In order to ping the Vlan Interface you just need management policy applied to the vlan interface.
Class-maps used in the management-policy
defines the source addresses from where these management accesses are allowed.
If you can ping the interfaces from locally connected subnets but not from the remote subnets then there could be 2 reasons.
1. Some routing issues
2. Source IPs in Management class maps are not defined.
Following is an example of typical management policy
#Allow telnet & SSH from these ip addresses
#Allow ICMP from any source
class-map type management match-any MGMT-CLASS
10 match protocol telnet
20 match protocol ssh
30 match protocol icmp any
policy-map type management first-match MGMT-POLICY
class MGMT-CLASS
permit
interface vlan 10
ip address x.x.x.x 255.255.255.0
service-policy input MGMT-POLICY
no shutdown
interface vlan 20
ip address y.y.y.y 255.255.255.0
service-policy input MGMT-POLICY
no shutdown
Syed Iftekhar Ahmed

Broadcast/multicast counters does not increase on vlan interface

Hi,
on a Cat6500 we try to monitor interface packet statistics via snmp, in detail we want to get information about the relation between unicast, multicast and broadcast packet counter.
What we found out is that while on physical l2 interfaces all counters (ifHCInUcastPkts, ifHCInMulticastPkts, fHCInBroadcastPkts, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts) are filled, on vlan interfaces multicast in/out and broadcast out packets stay zero whole the time. We use arp, hsrp, ospf and other well know broadcast and multicast based protocols.
Does anybody know why this counters do not increase?
Attached you find an excel sheet which shows an example of interface counter vs. vlan counter.
many thanks in advance,
Thorsten Steffen

Hi jon,
belown the result of sh sdm prefer,so need i a licence ip service to apply the route-maap on the interface vlan,or just entrer the config"sdm prefer routing" and reboot the switch?
SWBB0#sh sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses:                  6K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    8K
    number of directly-connected IPv4 hosts:        6K
    number of indirect IPv4 routes:                 2K
number of IPv6 multicast groups:                  64
number of directly-connected IPv6 addresses:      74
number of indirect IPv6 unicast routes:           32
number of IPv4 policy based routing aces:         0
number of IPv4/MAC qos aces:                      0.5K
number of IPv4/MAC security aces:                 0.875k
number of IPv6 policy based routing aces:         0
number of IPv6 qos aces:                          0
number of IPv6 security aces:                     60

ACL's in VLAN Catalyst 3550

Hello !!
We have a Switch Catalyst 3550 - 12G
IOS : Version 12.2(25)SEA
I need to implement ACL security in VLAN's. But, it did't work.
VLAN 11 Definition :
interface Vlan11
description VLAN - RED WAN
ip address 192.168.21.1 255.255.255.0
Interface association (g0/7) with VLAN 11 and extended ACL (ip1)
interface GigabitEthernet0/7
switchport access vlan 11
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 11
switchport mode dynamic desirable
ip access-group ip1 in
ACL definition :
ip access-list extended ip1
permit ip 192.168.70.0 0.0.0.255 any
deny ip any any
This configuration must allow ip communication between 192.168.70.0 / 24 and 192.168.21.0 / 24. However it does't work.
Inter VLAN communication are ok.
Any Suggest ?
.... Switch Conf. attach
Tks.
John Nanez E.

Try putting on the SVI for vlan 11 (interface vlan 11) . don't think you can put it on a individual interface and have it work . Also they way you wrote it you'll have to put it as out on the vlan because you are permitting a address from another network to the vlan 11 address space thus it would have to block the traffic "out" to the devices on vlan 11 .

MSFC - cannot ping vlan interface

Hi,
We have several vlans defined on the mfsc. On the msfc we could ping all the vlans interface except 1 vlan. The interface is up and just recently we weren't able to ping it. Any help is much appreciated.
TIA.
PF

Hi PF,
AFAIK, When you are pinging a particular interface stting on the MSFC the source IP would be of any other available interfaces. If you are pinging vlan 110 it will take source ip of any other available vlan interface and the destination is Vlan 110, but ACL defined on the interface doesnot have any ACE for the same so that packets will be dropped.
Removing the ACL worked as explained above.
regards,
-amit singh

Could I use "vlan interface" as a tunnel source of DMVPN ?

I have a router R2811 with a 9 port FE Switch module(HWIC-D-9ESW).
Could I use vlan interface as a tunnel source when configuring DMVPN ?
The vlan ports is on the 9 port FE Switch module.
Because it's used now in production,I can't try it.

Hello.
I think there is no restriction on software routers like 2811.
PS: using loopback could be a better idea.

Netflow on 6509 in Native Mode from Vlan Interface

I'm trying to get a 6509-E, running Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.
2(33)SXI9, RELEASE SOFTWARE (fc2), to send netflow traffic from a vlan interface to a Solarwinds server.
The server is not seeing all the vlan traffic, but does see all the traffic on the layer 2 ports (not netflow).
I've seen that a command, ip flow ingress layer2-switched vlan, needs to be enabled, but the OS I have does not support that command.
Or could it be that MLS is not configured except for a couple commands:
mls netflow interface
mls cef error action reset
netflow setup:
Flow export v5 is enabled for main cache
Export source and destination details :
VRF ID : Default
    Source(1)       10.31.101.1 (Vlan52)
    Destination(1) 10.30.2.196 (2055)
Version 5 flow records
14927339 flows exported in 615072 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
0 export packets were dropped enqueuing for the RP
0 export packets were dropped due to IPC rate limiting
0 export packets were dropped due to Card not being able to export
interface:
interface Vlan52
description AN.VDI.stu
ip address 10.31.101.1 255.255.255.0
ip helper-address 10.31.149.200
no ip redirects
ip flow ingress
ip flow egress
ip pim neighbor-filter 98
ip pim sparse-dense-mode
ip cgmp

Enabling MLS was the fix.
mls netflow interface
mls flow ip interface-full
mls nde sender version 5
mls cef error action reset

VLAN Interface Command

Ok, I thought I had the reason for the VLAN interface command down. I thought it was either used for switch management or routing between VLANS? However, now I realized that some communication wont work with out this command which doesnt make sense. If I have a VLAN, then the switch will only switch packets to ports on the same VLAN. The only way, communication would work between VLANS is if I either enabled routing between VLANs with the VLAN Interface command, connected the switch to another multi-layer switch that did do routing between VLANS, or connected the switch to a router which routed between the VLANs.
However, I just got this new 3550 switch in, configured the correct ports with the assigned VLANs, and the only way my cisco ip phone would work is if the VLAN Interface for my voice-ip VLAN was configured. The 3550 is connected to a 4507. Now, can someone tell my why this is? You shouldnt have to configure the VLAN Interface, right?(unless I wanted to route between VLANs, which could be done by the 4507)

Sounds to me like you either dont have the dot1q trunk interface between your 4506 and 3550 working properly, or your 3550 is running the enhanced image which allows routing.
It would be nice to see your config on both the 3550 and the 4500 to determine the reason. Just a stab at how it should be configured is that on your 4506, you have it running VTP server or transparent with the defined Data and Voice Vlan's. You have a port configured for trunking (which connects to the 3550). On your 3550, you have configured it as a vtp client or transparent and have verified that it has received (or if transparent VTP you have configured) the appropriate VLAN's. You than specified "interface VLAN #" or whatever number for switch management and configured the port that connects to the 4500 as a trunk. Your port connected to the port has the auxillary or voice vlan configured. If this is how your equipment is configured and it still does not work, than look for the line "ip routing" in your 3550 and negate it with "no ip routing".
If still no worky worky, post your config.
Cheers,

ACE - Query VLAN Interfaces Status

Hi,
I am wondering what the status of the query vlan interface means in the command 'show ft peer detail':
Query Vlan IF State : UP, Manual validation - please ping peer
I am pretty sure that I did not see this status when I configured query vlan last time. Current version is A2(2.3).
Unfortunately this status does not seem to be documented anywhere on CCO.
I appreciate any help!
Thanks,
Daniel

Hi Daniel,
The FT Query VLAN interface is an optional, yet very good, feature to be used when using redundant ACE modules or appliances. Without it, if the FT VLAN was to go down, the standby ACE will no longer receive FT heartbeats from the active ACE and therefore take the active role. However, if the active ACE is still running fine in the active role, then you don't want the standby ACE to take over as active because that will put them into an active/active scenario, which may lead to connectivity issues.
This is where the FT Query VLAN interface comes in. If the FT VLAN goes down, the standby ACE will notice this, but before taking the active role, it will ping it's peer IP address configured on the interface that is designated as the FT Query VLAN. If the ping is successful, then it will stay in the standby role, thereby saving you some headaches.
The status that you are seeing is the ACE's way of telling you that the interface is UP, but if you want to know if it can successfully ping the peer IP address, then you would have to manually ping the peer IP address from the CLI. The ACE does not periodically check the ping connectivity through any automatic mechanism. The automatic mechanism is only triggered by the FT VLAN going down.
Does this help?
Sean

WLC - 4402/4 - Vlan Interface Addressing

I currently have 7 WLCs with the same Vlan interfaces defined across all 7 controllers. Does anyone know the best practice for addressing these interfaces on each of the WLCs. I currently have each unique Vlan interface assigned with the same IP address across all 7 WLCs. This is working. Should I leave it this way or should I assign each controller with a different address for the Vlan interface?

The controllers, assuming you have it configured as such, act as dhcp relay agents. Presumably, if the router got the wrong mac address in its arp entry, the dhcp message would be lost.
Clients could have taken a while before getting a dhcp addr (race condition for router arp entry) and not been able to work if dhcp was required.
That said, I've seen the controllers work with the dhcp server set to 255.255.255.255 so the ip helper addresses on the routers would pick up the requests.

ACL applied to Vlan interfaces

Similar Messages

Maybe you are looking for