If i do this:

interface vlan 999
bridge address XXXX.YYYY.ZZZZ ethernet 1/g1 permanent

exit

interface ethernet 1/g1
port security discard
port security max 0
exit

From what i can tell when plugging in a different device it drops traffic, as i can't ping that IP.  However i would like dynamic learning to work and also is there a live log i can look at when port security is doing it's thing?

As show int status shows the port as active and up and show port security ethernet 1/g1 just shows what is configured.

This issue was not resolved with the firmware upgrade.

Thanks for the response, so what is the point of having the port security max command available?

Authentication Bypass could work, but that is a larger scale implementation which will have to be done at a later date.  I was hoping to just be able to secure ports that are customer facing faster.

Perhaps as an alternative you could provide some guidelines as to what storm-control settings for broadcast/multicast and unicast i should use or how i would determine the best setting for our network?

Cheers

I want to implement storm control on ports facing tenants who may use dumb switches in order to prevent potential loops.

I had another security type issue with this switch that you may be able to help me with.

I created a few VLANs that were internally routed on the switch using OSPF and connected to an interface on our Sophos firewall.  I then created a separate VLAN on the switch with a completely different port trunked back to a separate sophos interface.

I created the following ACL

access-list test deny ip 192.x.x.x 0.0.0.255

After i applied this to the 192.x.x.x vlan, the desired effect of people in the 192 range not being able to reach the internal range was achieved.  However, beyond this, i wanted guests in the 192 range to be able to reach the internet, so i added access-list test permit ip any any.

This last line then allowed traffic to flow as normal, instead of blocking the first network and permitting outbound internet traffic to unknown hosts.

Topology is as follows:

Internal Network:

Sophos (standard port with ospf) > dell (port in acces mode) > dell core switch does intervlan routing and passes unknown traffic back to the sophos.

Guest Network

Sophos (trunk port) > dell core (where i tried placing the ACL) - all traffic is passed back from this network to the Sophos as it is running router on a stick.

The only way i could get this to work was denying traffic from one interface to the other on the Sophos and permitting WAN access.

Any thoughts?

So permit first allowed me to continue using the internet, however it did not drop access to another vlan which was the second line.

Action......................................... permit
Match All...................................... FALSE
Protocol....................................... 255(ip)
Source IP Address.............................. any
Destination IP Address......................... 192.168.1.1 (routers sub interface)
Destination IP Mask............................ 255.255.255.255

Rule Number: 2
Action......................................... deny
Match All...................................... FALSE
Protocol....................................... 255(ip)
Source IP Address.............................. 192.168.1.0
Source IP Mask................................. 0.0.0.255
Destination IP Address......................... 192.168.2.0
Destination IP Mask............................ 0.0.0.255

Client in vlan 3 with IP 192.168.1.100 was able to ping client in vlan 4 with ip 192.168.2.2.

ACL config:

access-list denyDGaccess permit ip any 192.168.1.1 255.255.255.255
access-list denyDGaccess deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Ok... so i tried again with

Vlan 30 - No ip assigned to the interface, trunked back to PFsense

vlan 40 - no ip assigned to the interface, trunked back to same pfsense port

This is the access list placed in vlan 40

access-list denyip deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list denyip permit ip any any

This time, the vlans cannot communicate and both have internet connections.  Why did it work this time?

Also i went over your example, the permit first was for local vlan specific hosts, followed by deny to the other vlans and then permit ip any any for unknown hosts.

Ok tried it in production again and no go, it's the same switch!

It was actually the same in both scenarios.

So assigning an ip to a vlan makes a difference? Routing is still being done by the Sophia though so the vlans will still communicate.

Ok so i just confirmed the following in my lab:

The VLANs do not have IP addresses assigned to them.

Results before the ACL was applied:

Hosts in both networks could ping each other and get to the internet.

Results After the AC:

access-list denyip deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list denyip permit ip any any

ip access-group denyip in 1 (vlan 192.168.1.x)

Hosts could not ping each other but could get to the internet.

Switch Running Config:

configure
vlan database
vlan 2,8,40,254-255
vlan routing 2 1
vlan routing 40 2
vlan routing 8 3
exit
hostname "wanipswitch"
stack
member 1 2
exit
ip address dhcp
ip domain-name xxxxxx
access-list denyip deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list denyip permit ip any any
ip routing

ip route 0.0.0.0 0.0.0.0 x.x.x.x
interface vlan 2
routing
ip address x.x.x.x x.x.x.x
exit
interface vlan 8
name "Test Network"
routing
exit
interface vlan 40
name "Test1 Network"
routing
ip access-group denyip in 1
exit

So no IP addresses assigned to the VLANs here and the ACL works, each VLAN passes data back to the router which is how traffic is routed between the VLANs

Any other ideas why it wouldn't be working?