Reply
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3
Accepted Solution

Access Port Best Practice

[ Edited ]

We're using freeradius to dynamically assign VLAN. Here's a configuration for a specific port:

 

interface 0/4
dot1x port-control mac-based
dot1x re-authentication
dot1x timeout quiet-period 5
dot1x timeout reauth-period 43200
dot1x max-users 1
dot1x mac-auth-bypass
dot1x unauthenticated-vlan 4000
vlan ingressfilter

First Question: Should I even be specifying `vlan ingressfilter`? I was trying to get an inkling for this in my other post. I set `vlan ingressfilter` because there was a column in `show interfaces switchport general` that looked like I should do something... however I'm not sure of what makes sense here.

 

As a side question I'd like to know if those dot1x configurations are sane as well.

 

show interfaces switchport general 

Intf      PVID  Ingress    Acceptable  Untagged  Tagged   Forbidden  Dynamic
                Filtering  Frame Type  Vlans     Vlans    Vlans      Vlans
--------- ----- ---------- ---------- --------- --------- --------- ---------
0/1       1     Enabled    Admit all  1
0/2       1     Enabled    Admit all  1
0/3       1     Enabled    Admit all  1
0/4       1     Enabled    Admit all  1                             40

Second Question: Should I force all of these ports to accept untagged frames only? When I deploy these access switches I make sure all 48 ports (ethernet) are dot1x controlled. If I need to deploy an access point or something I'll put another switch in the rack and set up copper trunking ports.

 

Third Question: If I know there are some vlans I don't ever want users to get on to (like management vlans) should I be setting them as forbidden?

 

Fourth Question: I'm rolling with STP defaults throughout the entire network and I'm setting the core switch to be the STP root with `spanning-tree mst priority 0 0` per @UBNT-benpin comment here.... so what things should I have enabled on these access ports?

 

show spanning-tree interface 0/4

Hello Time..................................... Not Configured
Port Mode...................................... Enabled
BPDU Guard Effect.............................. Disabled
Root Guard..................................... False
Loop Guard..................................... False
TCN Guard...................................... False
BPDU Filter Mode............................... Disabled
BPDU Flood Mode................................ Disabled
Auto Edge...................................... TRUE
Port Up Time Since Counters Last Cleared....... 2 day 19 hr 25 min 47 sec
STP BPDUs Transmitted.......................... 0
STP BPDUs Received............................. 0
RSTP BPDUs Transmitted......................... 0
RSTP BPDUs Received............................ 0
MSTP BPDUs Transmitted......................... 133662
MSTP BPDUs Received............................ 0

Should I have BPDU Guard enabled? or are there other things I should be checking?

 

Fifth Question: In the above it looks like interface 0/4 is transmitting BDPU packets... the intent of these ports is that the users never plug in a switch/router and always only plug in 'standard' devices... the fact that it's transmitting BPDU packets... does it mean I should go examine who's on 0/4 and expect to find something other than a laptop/desktop?


Accepted Solutions
Ubiquiti Employee
Posts: 2,490
Registered: ‎05-08-2017
Kudos: 446
Solutions: 364

Re: Access Port Best Practice

[ Edited ]

The vlan ingressfilter is not needed when you configure a port as 'access'. This is because there is no concept of including/excluding participating VLANs. 

 

As discussed here:

'An access port belongs to and carries the traffic of only one VLAN (unless it is configured as a voice VLAN port). Traffic is received and sent in native formats with no VLAN tagging. Traffic arriving on an access port is assumed to belong to the VLAN assigned to the port. If an access port receives a tagged packet (Inter-Switch Link [ISL] or 802.1Q tagged) for the VLAN assigned to the port, the packet is forwarded. If the port receives a tagged packet for another VLAN, the packet is dropped, the source address is not learned, and the frame is counted in the No destination statistic.'

 

And tested here.

 

The BPDUguard effect showing as 'disabled' is a bug that we are working on. Also reported in the topic here. What happens when you receive a BPDU on the port in question?

 

Ben


Ben Pin - EdgeMAX Support

View solution in original post


All Replies
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3

Re: Access Port Best Practice

Bumping, hoping someone from UBNT will venture an answer.

Established Member
Posts: 826
Registered: ‎07-23-2015
Kudos: 496
Solutions: 47

Re: Access Port Best Practice

I'm not a UBNT employee but a Cisco professional and can comment from suggested security best practices from a Cisco perspective merged with what I've learned from UBNT products.

 

vlan ingressfilter 

I would definitely leave this enabled this on your interface just in case tagged frames are sent into the switchport from an attacker attempting to jump VLANs.

 

This should also take care of your second and third questions because a port configured with this will not allow tagged frames on it for VLANs not configured as tagged members of the port.

 

STP configuration

I would explicitly define your ports as access ports and enable portfast:

switchport mode access
spanning-tree edgeport

Once this is done, you can enable bpduguard (global config level) which will disable any port that receives a BPDU:

 

spanning-tree bpduguard

I would leave bpdufilter alone as bpduguard will take care of your BPDU concerns and using bpdufilter may inhibit the effectiveness of bpduguard.

Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3

Re: Access Port Best Practice

with vlan ingressfilter I'm confused about how this might be mixing the convention of switchport and vlan. @UBNT-benpin would you mind weighing in, based on your post here? It seems like the assumption is that when switchport mode access is set, it's functionally equivalent to vlan ingressfilter.

Established Member
Posts: 826
Registered: ‎07-23-2015
Kudos: 496
Solutions: 47

Re: Access Port Best Practice

[ Edited ]

I’m interested to see the answer too because I know with a Cisco switch “switchport mode access” does not prevent a tagged VLAN with an ID the same as the access VLAN from being accepted by the switch. Seems like you lose some feature functionality if you stick strictly with the Cisco convention.

Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Highlighted
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3

Re: Access Port Best Practice

[ Edited ]

@Joyn I might be doing this wrong or hitting a bug on the new firmware (1.7.3-beta). Per your notes above and this post by @methode-apadmin:

 

 

(UBNT EdgeSwitch) #show running-config | include spanning-tree

spanning-tree bpduguard
spanning-tree mst priority 0 0

This is my 'root' switch. I have two in my lab to muddle with. So I've set this to be the mst priority 0 0.

 

(UBNT EdgeSwitch) #show running-config interface 0/1    

!Current Configuration:
!
interface  0/1
description 'arbiter'
spanning-tree edgeport
switchport mode access
switchport access vlan 7
exit

I'd expect from here that the BPDU Guard Effect would be Enabled.

 

(UBNT EdgeSwitch) #show spanning-tree interface 0/1 

Hello Time..................................... Not Configured
Port Mode...................................... Enabled
BPDU Guard Effect.............................. Disabled
Root Guard..................................... False
Loop Guard..................................... False
TCN Guard...................................... False
BPDU Filter Mode............................... Disabled
BPDU Flood Mode................................ Disabled
Auto Edge...................................... TRUE
Port Up Time Since Counters Last Cleared....... 2 day 6 hr 58 min 30 sec
STP BPDUs Transmitted.......................... 0
STP BPDUs Received............................. 0
RSTP BPDUs Transmitted......................... 0
RSTP BPDUs Received............................ 0
MSTP BPDUs Transmitted......................... 138622
MSTP BPDUs Received............................ 0

So I'm still not seeing BPDU Guard Effect Enabled. Maybe "Guard Effect" only enables when it triggers from another switch?

 

Established Member
Posts: 826
Registered: ‎07-23-2015
Kudos: 496
Solutions: 47

Re: Access Port Best Practice

Can you verify actual edgeport status?

show spanning-tree mst port detailed 0 0/1
Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3

Re: Access Port Best Practice

(UBNT EdgeSwitch) #show spanning-tree mst port detailed 0 0/1 

Port Identifier................................ 80:01
Port Priority.................................. 128
Port Forwarding State.......................... Forwarding
Port Role...................................... Designated
Auto-calculate Port Path Cost.................. Enabled
Port Path Cost................................. 20000
Auto-Calculate External Port Path Cost......... Enabled
External Port Path Cost........................ 20000
Designated Root................................ 00:00:44:D9:E7:06:FF:02
Designated Port Cost........................... 0
Designated Bridge.............................. 00:00:44:D9:E7:06:FF:02
Designated Port Identifier..................... 80:01
Topology Change Acknowledge.................... False
Hello Time..................................... 2
Edge Port...................................... TRUE
Edge Port Status............................... TRUE
Point to Point MAC Status...................... TRUE
CST Regional Root.............................. 00:00:44:D9:E7:06:FF:02
CST Internal Root Path Cost.................... 0
Loop Inconsistent State........................ False
Transitions Into Loop Inconsistent State....... 0
Transitions Out Of Loop Inconsistent State..... 0
Established Member
Posts: 826
Registered: ‎07-23-2015
Kudos: 496
Solutions: 47

Re: Access Port Best Practice

Yeah this is not expected behavior. Someone from UBNT needs to chime in for sure.
Please don't forget to kudo helpful posts and mark accepted solutions accordingly!
jcm.me - Personal Site | Joyn.Tech - Consulting Site

Add Auto-Provisioning Support to UNMS
Member
Posts: 182
Registered: ‎09-18-2012
Kudos: 88
Solutions: 3

Re: Access Port Best Practice

[ Edited ]
Ubiquiti Employee
Posts: 2,490
Registered: ‎05-08-2017
Kudos: 446
Solutions: 364

Re: Access Port Best Practice

[ Edited ]

The vlan ingressfilter is not needed when you configure a port as 'access'. This is because there is no concept of including/excluding participating VLANs. 

 

As discussed here:

'An access port belongs to and carries the traffic of only one VLAN (unless it is configured as a voice VLAN port). Traffic is received and sent in native formats with no VLAN tagging. Traffic arriving on an access port is assumed to belong to the VLAN assigned to the port. If an access port receives a tagged packet (Inter-Switch Link [ISL] or 802.1Q tagged) for the VLAN assigned to the port, the packet is forwarded. If the port receives a tagged packet for another VLAN, the packet is dropped, the source address is not learned, and the frame is counted in the No destination statistic.'

 

And tested here.

 

The BPDUguard effect showing as 'disabled' is a bug that we are working on. Also reported in the topic here. What happens when you receive a BPDU on the port in question?

 

Ben


Ben Pin - EdgeMAX Support

Reply