As the previous post suggests, you can do both inbound and outbound filtering on each interface. I would recommend this only if you want to rigorously control the traffic flow, and make sure that anything which slips through an inbound list gets caught by an outbound list on another interface. It creates a lot of extra work for you, because you have to get the inbound list on each interface coordinated with the outbound lists on all the others. Make a change in your inbound list, and you also have to change all the other outbound lists. If you get your inbound lists right, then the outbound ones are not absolutely necessary; in fact, they just eat up CPU cycles.

What follows is an example inbound access list for interface VLAN132. The "!" at the front of each line indicates a comment, to help explain the purpose of the folloiwing IOS command. The "*" at the end of a comment indicates a note at the end of the access-list. Line spaces are inserted here to keep the comments next to their corresponding IOS commands. Enter these commands from "config term":

------------------------------------------------------------------------------------------

! create named extended access list "Inbound132"

ip access-list extended Inbound132

remark Apply to interface VLAN132 inbound; filters traffic coming in from VLAN132 and going somewhere else.

! let VLAN132 hosts talk to VLAN132 hosts*

permit ip 192.168.132.0 0.0.0.255 192.168.132.0 0.0.0.255

! let the VLAN132 specified host talk to the VLAN133 specified host

permit ip host 192.168.132.6 host 192.168.133.6

! let VLAN132 hosts ping VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo

! let VLAN132 hosts reply to pings from VLAN133 hosts

permit icmp 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 echo-reply

! block VLAN132 hosts from talking to VLAN133 hosts**

deny ip 192.168.132.0 0.0.0.255 192.168.133.0 0.0.0.255 log

! block VLAN132 hosts from talking to VLAN151 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.151.0 0.0.0.255 log

! block VLAN132 hosts from talking to VLAN152 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.152.0 0.0.0.255 log

! block VLAN132 hosts from talking to VLAN128 hosts***

deny ip 192.168.132.0 0.0.0.255 192.168.128.0 0.0.0.255 log

! let VLAN132 hosts talk to any host anywhere on the Internet****

permit ip 192.168.132.0 0.0.0.255 any

! block any host from talking to any host anywhere on the Internet*****

deny ip any any log

------------------------------------------------------------------------------------------

* Permits VLAN132 hosts to talk to VLAN132 hosts, if that traffic must go through this device interface at the Layer3 level. Not necessarily needed if this is a router; more likely needed if this is a multilayer switch.

** Blocks any VLAN132 host from talking to any VLAN133 host (except .6 trying to talk to .6 on VLAN133, which was permitted earlier). Logs anything blocked so it can be reviewed later.

*** Logs anything blocked so it can be reviewed later.

**** Assumes Internet is upstream from the VLAN1 interface, and all VLAN132 users are to be permitted access to it; if this rule is executed, it means the previous blocks of VLAN132 traffic to other local VLANs 133, 151, 152, and 128 did not apply.

***** Blocks any other TCP/IP traffic received inbound to this interface. Logs anything blocked so it can be reviewed later. This takes the implicit "deny all" at the end of the access list, and makes it explicit so we can log anything that makes it this far in the list.

------------------------------------------------------------------------------------------

Create similar Inbound access lists for the other VLAN interfaces, deleting the lines you don't want, or changing the IP addresses in the lines you do want to create the desired flow of traffic.

Apply the appropriate access list to each interface. Example:

interface VLAN132

ip access-group Inbound132 in

Hope this helps.

You are correct, you can have only one inbound access-group and one outbound access-group per VLAN interface.

But if you want to, you CAN put all your extended access-list commands into one access-list, and apply it to every interface. Just make sure both directions of traffic flow are accounted for: that is to say, make sure each IP address involved has both a line permitting it to be the source and another line allowing it to be the destination.

Then, it doesn't really matter whether you apply it inbound or outbound on an interface; although technically, just inbound would be better, otherwise, each packet that clears the inbound access-list on one interface, will have to be processed a second time against the same access-list on the outbound journey through another interface, which is a waste of CPU time.

Here's an example:

! Allow all IP traffic between these two hosts

access-list 111 permit ip host 192.168.132.6 host 192.168.133.6

access-list 111 permit ip host 192.168.133.6 host 192.168.132.6

! Allow host .11 on VLAN133 to access POP3 e-mail server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq pop3

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.68 eq smtp

access-list 111 permit tcp host 172.25.4.68 eq pop3 host 192.168.133.11

access-list 111 permit tcp host 172.25.4.68 eq smtp host 192.168.133.11

! Allow host .11 on VLAN133 to access web server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.5 eq www

access-list 111 permit tcp host 172.25.4.5 eq www host 192.168.133.11

! Allow host .11 on VLAN133 to access DNS server on VLAN1

access-list 111 permit tcp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit udp host 192.168.133.11 host 172.25.4.66 eq domain

access-list 111 permit tcp host 172.25.4.66 eq domain host 192.168.133.11

access-list 111 permit udp host 172.25.4.66 eq domain host 192.168.133.11

! Block all other inter-VLAN IP traffic, and log the denials for later review

access-list 111 deny ip any any log

At the moment, the only reason I can come up with for NOT doing it this way is, if you delete access-list 111 then it affects all the interfaces it has been applied to at once.

Over time, you might want to optimize the order of the access-list commands. Check which permit lines have the most matches, and move them to the top of the list so they get executed sooner. Ideally, the fewer access-list commands that have to be processed before making a forward/don't forward decision, the better.

Hope this helps.