I have a network based on (mostly)C3560G switches using L3 and OSPF everywhere except at the access ports where servers are connected. I was planning to use ACLs to restrict packet flow through the router part of the switches. I don't care about the packet flow in the L2 VLANs.
I was planning on dumping the unwanted packets based on source ip adress, and dumping them at the destination network(entry-point at the destination network). I have several networks (ip interfaces) configured at each access switch, and the ACL's are access-group'ed to the (SVI)interfaces on the access switches.
I have attached a sample-configuration (from a C3550), the Gigabit interfaces are the L3 uplink configured with OSPF
I have 2 questions, if anyone can be so kind as to explain :)
1) The ACLs need to be "ip access-group xx out" to be working in the "inbound" direction, when applied to a SVI? This goes beyond my logic? Can anyone tell me why?
2) The ACL at interface Vlan102 is not working, a host with ip 10.7.0.2 using 10.7.0.1 as gateway has full access to a host with ip 10.16.2.2. (The aim was to discard the packet if it doesn't match the ACL and as so I was expecting the reply-packet from 10.16.2.2 to be discarded, but it doesn't get discarded)
The ACLs at VLANs 103 and 104 are functioning as needed dropping packets from networks not matching the ACL (eg. 10.16.2.2)
Has anybody found the holy grail on these issues?
Thanks in advance (I cannot figure out what is wrong here) ..
With the "inbound" I mean packets being routed to the SVI, not comming via a physical port on the switch. I can see that the ACLs has to be "ip access-group 1234 IN" (not IN) to have any effect on the L3-routed packets to the VLAN.
The switch doesn't seem to accept this command, should you have this instead, show tcam outacl 1 entries ? (attached!)
Oh.. now, after a 2 days of thinking, I found what caused the 2) ACL-issue.
The ACL is working as expected.
I have a management lan on which all my L3 switches have a physical port connected, and the switch which host the server with ip 10.16.2.2 therefore has the 10.7.0.0 subnet directly connected at a physical port, and the return-path of the packet did not include a hop at the switch which has the 10.7.0.1 gateway and the ACL :-(
A simple traceroute showed this to me a very short while ago. I just had to traceroute the return-path of the packet instead of the other way around.
Sorry to have wasted your time on this ... now I have to figure out how I can configure a physical management interface on a layer 3 switch, which is not part of the routing table? Or maybe I need to have an outgoing accesslist distributed on all the L3 devices to limit packet flow into the management lan, if I cannot remove the physical interface from the routing part.
The management lan is setup with unmanaged L2 switches, so I cannot do port isolation or VACLs unfortunately.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...