How are ACLs filtered applied to a SVI

[billyguthrie]

Hello,

I have some equipment that I would like to understand a bit better:

6509-E w/ a MSFC3 and a PFC3

Can anyone direct me to a Cisco document or link (Maybe a case study, white paper, architectural guide) relating to how a ACL filters traffic on the inbound and outbound direction of an SVI when the traffic is coming from a different linecard/switchport that the SVI is actually associated with.

Thanks

Billy

[Jon Marshall]

Billy

Start with this paper on 6500 archtecture -

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

also worth a look is this acl paper -

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml

Jon

[billyguthrie]

Jon,

Thank you for the information; However, the links you have provided I have already came across in my research.

I have spent many hours over the past several days clicking through Cisco's site with no luck.

The 6500 architecture guide is actually an awesome read, I go back to the document quite often.

That was the first document that I referred back to thinking the information that I was seeking would be in

that document. Maybe it was and I skimmed through using the keywords I had in mind, but as I have read it a few time, I

am comfortable that I have not missed anything.

I have come across this document:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/7.x/configuration/guide/acc_list.html

However, most of the information that is contained in that document is basic information.

Tho, Figure 16-2 Applying ACLs on Routed Packets looked promising, but that is information that is most

basic; host to host, I am looking for host to SVI.

Hopefully, someone can point me to a document that supports the question I have.

From a 6509-Es perspective, I understand the Cisco IOS ACLs are configured on the MSFC VLAN interfaces (SVIs).

The Linecards we utilize are the WS-X6748-SFP with CFCs and a SUP720-BXL (MSFC and PFC).

From a centralized forwarding decision perspective (based on Figure 24.) of

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

I understand how the ACLs are filtering packets when arriving and exiting a switchport from one linecard

to another. It is in black and white on that figure and steps. What I do not have an understanding on

is how the ACLs that are applied to a SVI and which are located on the MSFC (RP CPU of figure 24.) are being filtered

when traffic arrives on a port from a linecard destined to the MSFC (Traffic destined to the IP address of the SVI).

I imagine that the MSFC is also connected to the Rbus and Dbus but Figure 24 does not depict that; based on the

design of the PFC and one of the main functions of the PFC is to lookup any security ACLs I would think that the

MSFC is connected to the Rbus and Dbus, I just can not find any Cisco document that outlines the SUP720 architecture

that would depict this information.

Assuming the MSFC is connected to the Rbus and DBus

That brings this discussion to the main question, if the SVI is located (Configured) on the MSFC, what is inbound

and what is outbound (I can apply a inbound ACL to deny ICMP any any on the SVI [I tried outbound as well], and I

can still ping the SVI interface and if configured, the HSRP standby IP) from another vlan (outside of the SVI).

Sorry for a long explanation, maybe that will clarify what I am looking to clear up.

Any explanations are welcome; supporting documentation would help a lot.

Thanks for your time.

Billy

[Jon Marshall]

Billy

"That brings this discussion to the main question, if the SVI is located (Configured) on the MSFC, what is inbound

and what is outbound (I can apply a inbound ACL to deny ICMP any any on the SVI [I tried outbound as well], and I

can still ping the SVI interface and if configured, the HSRP standby IP) from another vlan (outside of the SVI)."

I don't have docs to hand but i'll have a hunt around, but in answer to your question.

Inbound on an SVI is traffic FROM clients/devcies on that vlan.

Outbound on an SVI is traffic TO clients/devices on that vlan.

One more thing to note. An acl applied outbound to an SVI (as well a router interface) does not affect traffic sourced from that interface.

Now you say you applied an acl inbound and you can still ping the SVI. If by that you mean you can ping the SVI from another vlan then you will indeed be able to do this. If you mean ping it from a device on the SVI vlan then you shouldn't be able to do that.

When thinking of the MSFC it's sometimes best to picture it as a physical router ie.

vlan 100 SVI -> MSFC -> vlan 200 SVI

looking at it like this you can see that if you wanted to block ping to SVI 100 from a device on vlan 200 then you need to apply the acl inbound on vlan 200 interface.

Edit - note the above example exhibits the same behaviour as a physical router. Applying an inbound/outbound acl to vlan 100 SVI will only affect traffic either going to or coming from devices on vlan 100.

What it doesn't do is filter traffic going to the actual SVI interface itself, unless of course the traffic is sourced from a device on vlan 100.

Jon

[Edison Ortiz]

Inbound on an SVI is traffic FROM clients/devcies on that vlan.

Outbound on an SVI is traffic TO clients/devices on that vlan.

The other way around. You apply inbound ACLs when protecting devices that form that Vlan. You apply outbound ACLs to control traffic exiting that Vlan.

__

Edison.

[Jon Marshall]

Edison

Are you sure ?

An acl applied outbound on an SVI will control traffic going to devices on that vlan.

Traffic exiting the vlan has to go to the L3 SVI for the vlan and hence the traffic would be controlled by an acl applied inbound on the SVI.

An inbound acl on an SVI would have no effect on traffic going to devices on that vlan so i can't see how that would protect devices on the vlan.

Jon

[billyguthrie]

>The other way around. You apply inbound ACLs when protecting devices that form that Vlan. You apply outbound ACLs to control traffic exiting that Vlan.

Not sure what you mean here, maybe you meant the other way around and it just did not come out that. Sometimes I do the same thing; But thanks for the input. I do understand the concept of the inbound and outbound; If you apply an inbound ACL to the SVI, that will filter traffic received (ingress)from within the vlan and if you apply an outbound ACL to the SVI, that will filter traffic that is transmitted out the VLAN (egress). I am not concerned with the hosts that are within the VLAN. I am concerned with the ip addresses that have been configured on the interface vlan (SVI) on the MSFC and if configured, the standby IP for HSRP.

Jon, I am gathering more data to present to this discussion that might help a little bit more. I will add some attachments that will help further I believe.

Again, thanks for your input on this.

Billy

[billyguthrie]

Jon, I am attaching some documents, one a jpg and txt. Let me know what you think after reviewing that information.

What I see going on is that the ICMP request packet that was sent by 192.168.2.2 is received by R1 on port fast0/0.

R1 will rip the Layer 2 information off to determine that bast path based on the destination Layer 3 information; Assuming

the best path to 192.168.2.1 was via 10.10.10.3 (R3) based on the traffic share. The ICMP request packet will be sent out

fast1/1 and arrive on fast1/1 of R1 (Vlan10) with the Layer 2 destination MAC of R3, so R2 will forward that packet out of

fast1/15 tagged with vlan10. R3 will receive the packet on f1/15 and will see that the frame is for itself and rip off the

layer 2 information to inspect and lookup the destination layer 3 information (192.168.2.1). R3 will check its arp table, if

it has the MAC of 192.168.2.1, it will then build the frame with the destination MAC of 192.168.2.1 and forward that frame out

fast1/15 tagged with vlan111. The ICMP request packet will arrive on the input side of vlan 111 of R1 port 1/15. As the vlan

has a ACL applied inbound, the source ip (192.168.2.2) does not match the ACL and that is where it is denied? As the only port

that is associated with vlan 111 is the trunk (f1/15), is that the port that is used to classify the inbound and outbound

traffic. If there were another port, lets say fast1/5 and configured as access vlan 111, then that port is also used for the

inbound and outbound classification, and not so much the interface vlan111 (tho, you will apply the access-group to the SVI

and not the physical interface) as I was thinking?

Please advise.

Sorry for writing a book, and again I do really appreciate you taking the time on these discussions.

Billy

[Jon Marshall]

Billy

Still looking at outputs but a few quick questions -

1) i think there may be some typos in the output file but basically are you pinging 192.168.2.1/2/3 from 192.168.1.2 ?

2) Your diagram - R1 is connected to R2 only ie. R1 does not have it's own connection to R3 ?

3) When you apply the ICMP to acl 2111 are you applying

access-list 2111 permit icmp any any

or

access-list 2111 permit icmp 192.168.2.0 0.0.0.255 any

Can you doublecheck R3 config to make sure it matches R2 with acl entry etc. are have you just cut and paste in which case no need.

Jon

[billyguthrie]

Jon,

answers to your questions

1) i think there may be some typos in the output file but basically are you pinging 192.168.2.1/2/3 from 192.168.1.2 ?

That is correct, I am pinging from 192.168.1.2 to 192.168.2.1/2/3

2) Your diagram - R1 is connected to R2 only ie. R1 does not have it's own connection to R3 ?

Well, R1 does not have a physical connection to R3, but does have a OSPF adjacency with R3,

as R1 fast1/1, R2 fast1/1, and R3 vlan10 are in the same broadcast domain.

3) When you apply the ICMP to acl 2111 are you applying

access-list 2111 permit icmp any any

or

access-list 2111 permit icmp 192.168.2.0 0.0.0.255 any

I used access-list 2111 permit icmp any any

Can you doublecheck R3 config to make sure it matches R2 with acl entry etc. are have you just cut and paste in which case no need.

They are a copy and paste.

Sorry that there are typos; I will re-review the file again to ensure that all is well.

Billy

[billyguthrie]

Jon, there was one typo that I did see, sorry; there is no trunk f1/15 on R1:

I meant to say:

if I ping from from 192.168.2.1 it fails!

When the pings fail, the icmp packets are traversing the trunk between R2 and R3. (f1/15). I see this with

packet captures when capturing on fast1/15 of R2.

[Jon Marshall · Accepted solution]

Billy

Assuming you are applying "permit icmp any any" then this is what is happening.

An ICMP packet is sent to 192.168.2.2 from 192.168.1.2. When R1 looks up the destination 192.168.2.2 in it's routing table it sees the next hop as 10.10.10.3.

So R1 sends the packet to R2 with a destination mac-address of vlan 10 on R3 ie. 10.10.10.3. R2 simply switches at L2 the packet on vlan 10 to R3.

R3 receives the packet and sees that the destination is 192.168.2.2 which is actually R2. So it sends the packet back to R2. And this is where the packet is filtered because

1) the source address is 192.168.1.2

2) the destination address is 192.168.2.2

3) the packet is routed onto vlan 111 by R3 so when the packet arrives at R2 it is now coming from a device on vlan 111 ie. R3

4) the acl applied to vlan 111 interface is now checked and because the source is 192.168.1.2 that is not permitted and so is dropped.

By applying ICMP permit ip any any you are actually masking the issue as this packet is now allowed.

If you disable OSPF on R3 then the next hop is 10.10.10.2. This now works for 192.168.2.1/2 because R1 still sends the packet to R2 but this time with a destination mac-address of R2's vlan 10 interface and not R3.

So R2 can now route the packet directly onto vlan 111 and so vlan 111 access-list is not checked.

The issue you have is your topology rather than an acl understanding as the acls are doing exactly as originally described in terms of inbound/outbound. The topology problem being the way R1 to get to R3 has to go through R2.

Jon

[billyguthrie]

Jon,

>The issue you have is your topology rather than an acl understanding as the acls are doing exactly as originally described in terms of inbound/outbound. The topology problem being the way R1 to get to R3 has to go through R2.

The funny thing Jon is that I have never looked at it as an issue really, as I had a basic understanding what was happening after I applied some thought into it. (before posting) Really just wanted to find some documentation my support my diagnose.

Before this posting, the confusion was that:

It was the concept that the SVI interface is logical vs. physical.

And where the correlation between the 2 existed.

When you apply an ACL to a physical interface (layer 3), there is no other direction for in and out of that port; it is black and white!

Lets scale it down a bit, lets bring a Cisco 3550 into the picture. You create a vlan and then create the SVI with an IP. With nothing else connected to the switch, that SVI is useless as really, the SVI is down until you configure a switchport in the vlan. So now, the a host connected to that switchport and the port is up/up, hopefully the SVI will be up/up as well. However, there is still only one direction for the traffic. Out/in of that port; Connect 12 hosts to the switch, assign all the ports to the same vlan that the SVI is is, now you have 12 directions that the traffic can enter and exit. I now see the physical port as the source for the inbound and outbound classification for the ACL that is applied on the SVI. (Not traffic literally coming into the SVI, is it is virtual anyway.) I was just hoping to find supporting documentation that discusses that. The discussions that you and I had, helped out a lot in helping me understand this.

Again, thank you for your time

[Jon Marshall]

Billy

"Again, thank you for your time"

No problem and thanks for the rating.

One last thing -

"The funny thing Jon is that I have never looked at it as an issue really"

it's not an issue in terms of how it is working but more a design issue. If you are going to run HSRP between R2 & R3 that assumes you are trying to provide redundancy to end hosts. But if R2 is the switch that fails then yes HSRP will switch over to R3 but R3 has no path to get to R1 so only local switching within R3 is now supported.

Of course without more details of the topology etc. this may be exactly what you want.

Jon

[billyguthrie]

Jon, I suppose I should have made that clear from the beginning. That is not the whole topology. We have redundancy in each area up to the core. Check out Figure 20 in http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/dcstslt.html

That is pretty much to the T of what we have without the Route Health Injection (RHI).

Thanks

Billy