Port Security on 6248's

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.

Some switches support a MAC sticky option. The sticky option alters the behavior so that learned MAC addresses on the interface do not drop off. The 6200 switches do not have this option. This leaves you with the static entries you talked about.

Would MAC authentication bypass be something that could work for your network?

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

The intended use on this model switch is to help prevent a port from having additional networking devices added. For instance if a hub or another switch were to be added to the port, port security would prevent these additional clients from accessing the network.

Storm control settings can vary from network to network. The default value for all storm control settings on the 6200 switches is 5. I suggest leaving the default of 5 and monitoring to see if the desired outcome is reached.

What is your requirements/goals of implementing storm control?

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?

The goal here is to have the guest network only communicate with the second Sophos connection? And not communicate with any other internal network.

Could you leave the guest VLAN as a layer 2 only VLAN? This would isolate it from the other VLANs.

What about modifying the ACL so that it permits the guest traffic, and then denies all other.

Something along the lines of:

permit any (Sophos IP)
deny any any

Example 3 on page 9 of the this white paper goes into more detail about the permit then deny mentality with a guest vlan.

http://dell.to/1AACg9V

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!

If the VLAN interfaces do not have an IP address assigned to them, then those VLANs will be in layer 2 mode, and traffic will not be routed by the switch. This means that no ACL would be needed to prevent VLAN to VLAN communication.

When you put this in production, what changed? Were IP addresses added to the VLANs? Is the firewall routing between the VLANs?

Scenario 1:

- Leave the VLAN as layer 2, do not implement ACL on the switch, let the firewall handle routing and control connections.

Scenario 2:

- Assign IP addresses to the VLANs, implement ACL on the 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?