cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2831
Views
5
Helpful
10
Replies

6506-E won't allow outbound ACL

Mike Bailey
Level 1
Level 1

Hi all,

Have a 6506-E with SUP-720 running s72033-pk9sv-mz.122-18.SXD6.bin

I have traffic coming in on two devices connected to GigabitEthernet1/9 and 1/10 which 'should' exit on interface GigabitEthernet2/36 due to a static route.

However if GigabitEthernet2/36 were to go down due to a fault the static route would drop and the OSPF would force the traffic up GigabitEthernet2/48 which is connected to a much slower device which won't handle the traffic.

I've set the static route to 'permanent' so that even if GigabitEthernet2/36 goes down OSPF shouldn't re-route the traffic, but I wanted 'belt and braces' to apply an outbound ACL on GigabitEthernet2/48 to prevent the traffic trying to go out that way.

However the switch refuses to take the command 'ip access-group 101 out'.

It will accept 'ip access-group 101 in' but not 'out'.

Any ideas?

Cheers

Michael

2 Accepted Solutions

Accepted Solutions

Mike

Switches support port acls which is a router acl applied to a L2 switchport but it is only supported in the inbound direction so you cannot apply them outbound. This is why you only have the "in" option when dealing with a L2 switchport.

If you want to make sure traffic cannot use the OSPF link then i would suggest if possible moving the OPSF link into a different vlan than vlan 10 then using PBR on vlan 10 interface to route the traffic for the specific 2 machines via your chosen link and if that fails route the packets to the null interface. You would not need the static route if this was your approach.

Edit -  i forgot to mention that upgrading IOS wouldn't help. Port acls can only be applied inbound to L2 switchports

Jon

View solution in original post

Mike

I do understand about complying with change control. So further investigation may need to wait for another time.

I have done some searching and now have a better understanding of what you were seeing in on line help. And "ip access-group in" turns out to be valid on the layer 2 interface. To explain that let me point out that (depending on the  version of code that you run on 6500) there are multiple types of access lists. The familiar access lists are the router access lists which are applied to layer 3 interfaces to filter routed packets. There are also VLAN Access Lists (VACL) which can be applied to VLAN interfaces and can filter traffic being bridged through the VLAN. And there are Port Access Lists (PACL) which are applied to layer 2 ports - but only in the inbound direction. So ip access-group in is how you apply a PACL to a layer 2 interface.

Here is a link which has good information about these different types of access lists:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vacl.html#wp1039754

I am not clear whether a PACL would help solve your problem, but you should take a look and see what you think.

HTH

Rick

[edit] I am glad to see that while I started my response and was doing my search that Jon posted explaining the feature also. What a neat place this forum is. 

HTH

Rick

View solution in original post

10 Replies 10

Richard Burts
Hall of Fame
Hall of Fame

Michael

Perhaps if you would post the configuration of the interface it would help us figure out what is going on.

HTH

Rick

HTH

Rick

rahurao
Level 1
Level 1

HI Mike,

As per the issue the ACL should be applied but you haven't pasted the ACL configuration and the interface configuration to check more details about the issue.

Can you paste in the same information ?

ALso the code you are running on the E chassis is pretty old and i believe you need to upgrade the same.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/COnfiguration guide:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html



HTH

RAHUL

OK config of the interface:

interface GigabitEthernet2/48
description *** Uplink to BLAH BLAH BLAH ***
no ip address
switchport
switchport access vlan XXX
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable

ACL defined:

access-list 101 remark *** Block BLAH BLAH BLAH ***

access-list 101 deny ip XX.XX.XX.XXX 0.0.0.15 any
access-list 101 permit ip any any

We are they trying to apply the configuration as follows:

switch(config)# interface GigabitEthernet2/48

switch(config-if)# ip access-group 101 out

At which point it tells me 'out' is not a valid argument, and using 'ip access-group 101 ?' gives me 'in' as the only option.

Michael

Thank you for the additional information. It does make clear what the issue is. You are using this interface as a switch access port - layer 2 port. You apply ip access-group to layer 3 interfaces and not to layer 2 ports. You would need to apply the ip access-group to interface vlan xxx.

HTH

Rick

HTH

Rick

Rick,

Thanks for the response but if you can't apply an 'ip access group' to a layer 2 interface why does it allow me to create it inbound but not outbound?

How would it work if the traffic is leaving the switch on the same VLAN (e.g. you can't apply ACL outbound from the VLAN as you want it to leave the VLAN but you only on specific ports)?


So example....

Port 1/10 is in VLAN 10 @ 100Mbits/s

Port 2/36 is in VLAN 10 @ 1Gbits/s

Port 2/48 is in VLAN 10 @ 100Mbits/s

Under normal circumstances 100Mbits/s traffic is going to come into the 6500 switch on port 1/10 and then leave on port 2/36 which is fine.

However if the link on 2/36 goes down it will try and use 2/48 and in this instance it will consume all the bandwidth and I don't want it to use 2/48 under any circumstances.

OK I could create a QoS policy to reduce the traffic or even drop it but surely you should be able to apply an outbound ACL to an interface.

Cheers

Mike

Mike

I am not convinced that you can configure ip access-group in on a layer 2 interface. At one point you talk about the switch allowing the ip access-group in and in another point you are obviously using the online help facility to determine what the options are and what is allowed. Have you actually configured ip access-group in on the layer 2 interface? If so can you post the interface config that includes the access-group on the layer 2 interface?

HTH

Rick

HTH

Rick

Can't make any further changes I'm afraid as we are now outside our RFC window and I'll need to get approval for any further changes - extremely strict change control on our network which is why we don't upgrade IOS images regularly - 'if it isn't broke it isn't worth the hassle of arranging to make changes'

Indeed I was referring to the online help which told me 'ip access group 101 in' was valid but 'out' wasn't listed as an option.


We didn't attempt to apply the ACL inbound at the time as it wouldn't have achieved what we were attempting.

I had therefore assumed a 'known quick' in IOS allowing inbound but not allowing outbound and that perhaps it could justify an IOS upgrade to a versus that perhaps did support it.

Frustrating,,,,

I do think the VLAN option is a possibility just need to think about practicalities of associated changes to make it work otherwise a policing QoS policy which drops packets from the specific source using the 2/48 interface would probably work but again time needed to plan it....

Mike

Switches support port acls which is a router acl applied to a L2 switchport but it is only supported in the inbound direction so you cannot apply them outbound. This is why you only have the "in" option when dealing with a L2 switchport.

If you want to make sure traffic cannot use the OSPF link then i would suggest if possible moving the OPSF link into a different vlan than vlan 10 then using PBR on vlan 10 interface to route the traffic for the specific 2 machines via your chosen link and if that fails route the packets to the null interface. You would not need the static route if this was your approach.

Edit -  i forgot to mention that upgrading IOS wouldn't help. Port acls can only be applied inbound to L2 switchports

Jon

Mike

I do understand about complying with change control. So further investigation may need to wait for another time.

I have done some searching and now have a better understanding of what you were seeing in on line help. And "ip access-group in" turns out to be valid on the layer 2 interface. To explain that let me point out that (depending on the  version of code that you run on 6500) there are multiple types of access lists. The familiar access lists are the router access lists which are applied to layer 3 interfaces to filter routed packets. There are also VLAN Access Lists (VACL) which can be applied to VLAN interfaces and can filter traffic being bridged through the VLAN. And there are Port Access Lists (PACL) which are applied to layer 2 ports - but only in the inbound direction. So ip access-group in is how you apply a PACL to a layer 2 interface.

Here is a link which has good information about these different types of access lists:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vacl.html#wp1039754

I am not clear whether a PACL would help solve your problem, but you should take a look and see what you think.

HTH

Rick

[edit] I am glad to see that while I started my response and was doing my search that Jon posted explaining the feature also. What a neat place this forum is. 

HTH

Rick

THanks both for the replies.

Have to admit I've always previously applied ACL's to L3 interfaces on routers and this was first attempt on a L3 switch and had 'assumed' incorrectly that the same rules would apply.

Will go 'back to the drawing board' with the newly learnt information.

Thanks again

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: