Cat6500 Inbound ACL Issue. Very strange.

Answered Question
Mar 12th, 2009

Hey everyone :)

So, I have two 6500s and a vlan trunked between them (VLANx)

Running HSRP on the VLANx

6500-1 is 10.10.10.1

6500-2 is 10.10.10.2

HSRP is active on 6500-1 with 10.10.10.3

I have an inbound ACL on both VLANx interfaces, that do not permit anything but UDP traffic.

I can ping and telnet 6500-1 10.10.10.1 ip address

I cannot ping ot telnet 6500-2 10.10.10.2

I cannot ping or telnet 6500-1 10.10.10.3 HSRP

How does that work?

I would have thought, that I would not be able to ping or telnet to any of the interfaces, as it is an inbound ACL?

Is there sommat that happens in the ACL process that says, if you are directly for me, allow it or dont pass it thru the ACL?

Im confused.com :)

Many thx

Ken

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 7 years 9 months ago

Ken

3) SVI sends packet back. Yes but an inbound acl on the vlan interface would not affect that. Actually an outbound acl wouldn't either but that's to do with an outbound acl not affecting packet sourced by the router interface.

So the inbound acl on vlan X SVI never gets invoked when you ping that interface IP address. Packet from your PC never actually hits the inbound ACL - remember an inbound acl on a vlan interface affects traffic coming from devices on the vlan ie. 10.10.10.x.

And the return traffic never hits the inbound acl either.

Does this make sense ?

Jon

Correct Answer by adamclarkuk_2 about 7 years 9 months ago

No prob mate.

If you have applied and ACL inbound to an SVI denying icmp/telnet then it will not be permitted.

I'm guessing you setup is as below (apart from the IP's and names) :-

ip access-list extended Test

permit udp any any

VLAN 10

ip address 192.168.1.1 255.255.255.0

ip access-group Test in

standby 16 ip 192.168.1.3

standby 16 preempt

If so, any device on the 192.168.1.0/24 network will not be able to ping or telnet to the address, but other offnets should be able to.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
adamclarkuk_2 Thu, 03/12/2009 - 06:14

Hi

Can you post the relevant config and also the source for your ping/telnet connections.

kfarrington Thu, 03/12/2009 - 06:30

Hi Adam,

I am really sorry, I cant post the configs, not premitted to, but the config is quite simple mate :)

I am thinking that it may be sommat platform specific that says if a packet is destined for an SVI direcly on the router, it would be allowed?

Many thx for the ultra fast response mate :))

Ken

adamclarkuk_2 Thu, 03/12/2009 - 06:41

No prob mate.

If you have applied and ACL inbound to an SVI denying icmp/telnet then it will not be permitted.

I'm guessing you setup is as below (apart from the IP's and names) :-

ip access-list extended Test

permit udp any any

VLAN 10

ip address 192.168.1.1 255.255.255.0

ip access-group Test in

standby 16 ip 192.168.1.3

standby 16 preempt

If so, any device on the 192.168.1.0/24 network will not be able to ping or telnet to the address, but other offnets should be able to.

kfarrington Thu, 03/12/2009 - 06:44

Hey mate, that is correct. The thing is, yes, packets should be able to get to the LAN from offnets, but I should not get a reply correct?

I am getting replies from my PC to one of the 6500 interface addresses, ie, the active one. Not the HSRP address, but the physical interface?

:)

Man, you guys are quick :))

Many thx

Ken

Jon Marshall Thu, 03/12/2009 - 06:48

Ken

Do you get replies if you try to ping a device on the vlan and not the 6500 interface address ?

An inbound acl on the vlan interface will not affect the ability of the vlan interface to respond to a ping and nor will it stop the packet reaching the interface, unless of course you are doing it from the vlan itself.

Jon

kfarrington Thu, 03/12/2009 - 06:50

Anything on the LAN, I cannot ping. It is just the active (physical interface)

I am just gonna do a quick piccie :) Just so I am not confusing anyone, as I dont want to waste anyones valuable time.

Thx Jon :))

Jon Marshall Thu, 03/12/2009 - 07:09

Ken

It makes sense that the PC can ping 10.10.10.1 because the packet does not go inbound on the vlan interface at any time - see previous post.

It also makes sense that you cannot ping any of the devices on the 10.10.10.x network because their responses would have to come back into vlan interface with the access-list and so would be dropped.

Where things are a little unclear is with 10.10.10.2 and 10.10.10.3. I suspect as i said before this is due to how packets enter the 6500 from your PC. Because all the L3 interfaces are virtual it can sometimes be quite difficult to envisage the path the packets take once they enter the 6500.

Jon

kfarrington Thu, 03/12/2009 - 07:17

Hi Jon,

In ref to the diagram:

Becuase of the routing to the R1 and R2 from the core of the network, it is quite possible that traffic destined for .2 and .3 IP addresses come into R1 and then use the connected link from there to get to R2 *from* R1

So that would explain that.

BUT.

And please tell me that I am wrong. I thought that the interface .1 would also block it.

ie, process flow

1. packet comes into the router

2. router has to switch the packet to the SVI. Packet is now on the LAN (vlanx).

3. SVI now sends a packet back from the SVI (which is on vlanx) back to the destination, ie ICMP echo reply, or return telnet traffic.

4. This return packet hits SVI ACL?

5. Packet denied.

That would be the logic from my side. I asumme I am wrong :)

If so, also, do cisco document say this order of operation for the router/interface processing of the packet?

Many thanks for this guys, It is brill the responses I am getting :)

Many thx

Ken

Correct Answer
Jon Marshall Thu, 03/12/2009 - 07:22

Ken

3) SVI sends packet back. Yes but an inbound acl on the vlan interface would not affect that. Actually an outbound acl wouldn't either but that's to do with an outbound acl not affecting packet sourced by the router interface.

So the inbound acl on vlan X SVI never gets invoked when you ping that interface IP address. Packet from your PC never actually hits the inbound ACL - remember an inbound acl on a vlan interface affects traffic coming from devices on the vlan ie. 10.10.10.x.

And the return traffic never hits the inbound acl either.

Does this make sense ?

Jon

kfarrington Thu, 03/12/2009 - 07:29

Perfect mate.

Jon, Adam, Many thanks for the input. I am gonna store this post away so I dont forget how this works :))

Many thx indeed,

Ken

Jon Marshall Thu, 03/12/2009 - 06:36

Ken

Where are you pinging from ie. are you on 6500_1 or are you on a separate device ?

Jon

kfarrington Thu, 03/12/2009 - 06:39

Yes, I am approx 5 hops away, not on the device itself.

The input ACLS on both 6500s only allow UDP specifica ports with a deny ip any any log at the end of it. I am not seeing any logging entries for the deny as I am getting a response.

Does that help mate?

Many thx

Ken

Correct Answer
adamclarkuk_2 Thu, 03/12/2009 - 06:42

No prob mate.

If you have applied and ACL inbound to an SVI denying icmp/telnet then it will not be permitted.

I'm guessing you setup is as below (apart from the IP's and names) :-

ip access-list extended Test

permit udp any any

VLAN 10

ip address 192.168.1.1 255.255.255.0

ip access-group Test in

standby 16 ip 192.168.1.3

standby 16 preempt

If so, any device on the 192.168.1.0/24 network will not be able to ping or telnet to the address, but other offnets should be able to.

Jon Marshall Thu, 03/12/2009 - 06:45

Ken

i suspect Adam has hit it on the head. Inbound on a vlan interface means traffic coming FROM clients on that vlan.

What is more confusing is why 6500_1 works but not 6500_2 or the HSRP address. I'm guessing it's to do with it being a L3 switch and the path that the packets take to enter the 6500 ?.

Perhaps you could do a traceroute to all 3 addresses for us from your client ?

Jon

Actions

This Discussion