Switchport setup

[Nerm]

I have been working on creating a template for switchports to throw on new switches that enter our environment. One template for access ports and one for trunk ports. I was curious if anyone else has done similar and what has and hasn't worked for you? As an example here is what I have so far for access ports. Also if anyone sees any "that's stupid, don't do that" in this example let me know. I haven't deployed anything yet just toying with ideas.

Code Select Expand


switchport mode access
switchport nonegotiate
storm-control broadcast level 30
storm-control multicast level 50
storm-control action shutdown
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict


[SimonV]

Looks ok to me but root guard shouldn't be on access ports, and bpdu guard will already shutdown the port anyway.

I would also add:

- load-interval 30 for shorter interface statistics
- disable cdp/lldp transmit
- dhcp snooping rate limit on access ports, if you're using snooping of course

[NetworkGroover]

Looks ok to me but root guard shouldn't be on access ports, and bpdu guard will already shutdown the port anyway.

I would also add:

- load-interval 30 for shorter interface statistics
- disable cdp/lldp transmit
- dhcp snooping rate limit on access ports, if you're using snooping of course

Heh - I haven't found a great use case for root guard in general... if you're interested and/or bored, take a look at a couple of my blog posts and let me know your thoughts:

http://aspiringnetworker.blogspot.com/2013/07/optimizing-and-protecting-spanning-tree.html

http://aspiringnetworker.blogspot.com/2013/07/optimizing-and-protecting-spanning-tree_13.html

http://aspiringnetworker.blogspot.com/2013/10/spanning-tree-exercise-and-revisiting.html

[SimonV]

Current design practices are to place this on access ports.

Is there a reference for that? I've always wondered about it... BPDU guard would be the preferred countermeasure, right? Maybe in the rare situation that you do allow a "foreign" STP enabled switch to be connected but don't want to cause STP instability?  I've been thinking about it a few times, and the only place where it does seem to make sense is on distribution switches that connect downward to access switches only (imho).

May have to lab it 

[NetworkGroover]

Current design practices are to place this on access ports.

Is there a reference for that? I've always wondered about it... BPDU guard would be the preferred countermeasure, right? Maybe in the rare situation that you do allow a "foreign" STP enabled switch to be connected but don't want to cause STP instability?  I've been thinking about it a few times, and the only place where it does seem to make sense is on distribution switches that connect downward to access switches only (imho).

May have to lab it 

Agree - and even then I question it's applicability.

EDIT - Ha!  Just re-reading my blog post I see where that line came from - straight out of the CCNP books.  I have the same line in my blog posts since I wrote it as a form of note-taking while reading - "Current design practices are to place this on access ports."

If you read further down though, I state that in my testing I don't find a great use case for it.  The other blog posts go into more detail and testing notes.

[Nerm]

Looks ok to me but root guard shouldn't be on access ports, and bpdu guard will already shutdown the port anyway.

I would also add:

- load-interval 30 for shorter interface statistics
- disable cdp/lldp transmit
- dhcp snooping rate limit on access ports, if you're using snooping of course

So you're saying if I already have bpdu guard then root guard is not needed?

Here is what I have so far for trunk ports.

Code Select Expand


switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxx,xxx
switchport nonegotiate
storm-control broadcast level 30
storm-control multicast level 50
spanning-tree bpdufilter enable


Btw, if these look familiar it is because the inspiration for this idea came from a packet pushers blog article.

[SimonV]

So you're saying if I already have bpdu guard then root guard is not needed?

Correct, BPDU guard will shutdown a port whenever a BPDU is received and put it in err-disable mode. 
Root Guard will only act when a BPDU with superior priority than the current Root is received. 

link: https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10588-74.html

Here is what I have so far for trunk ports.

Code Select Expand


switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxx,xxx
switchport nonegotiate
storm-control broadcast level 30
storm-control multicast level 50
spanning-tree bpdufilter enable


Btw, if these look familiar it is because the inspiration for this idea came from a packet pushers blog article.

Where is this type of trunk running too? BPDU filter will make it filter all BPDUs so in effect, it doesn't participate in STP. So it shouldn't be configured on inter-switch links. I would also add a non-existing or inactive VLAN as native VLAN. And "logging event spanning-tree status" and "logging event link-status" on important uplinks.

There's probably more but that's what I remember from the top of my head.

EDIT - Ha!  Just re-reading my blog post I see where that line came from - straight out of the CCNP books.  I have the same line in my blog posts since I wrote it as a form of note-taking while reading - "Current design practices are to place this on access ports."

If you read further down though, I state that in my testing I don't find a great use case for it.  The other blog posts go into more detail and testing notes.

Right, sorry about that, I'm pretty ADD when reading stuff online 

[Nerm]

Currently we have trunks to AP's, Servers, and other switches. The trunk example I gave though is in regards to trunks going to AP's and Servers. The trunks going to other switches is currently only utilizing "storm-control".

Forgive my lack of knowledge but what would be the purpose of making a non-existent/inactive vlan the native vlan?

[icecream-guy]

Here's mine off one of my 4900's


interface TenGigabitEthernet1/5
description Demo Port
switchport
switchport access vlan 4000
switchport private-vlan trunk encapsulation dot1q
switchport private-vlan trunk native vlan tag
switchport mode access
switchport nonegotiate
no switchport protected
no switchport block multicast
no switchport block unicast
switchport port-security maximum 1
switchport port-security maximum 65535 vlan
switchport port-security maximum 65535 vlan access
switchport port-security maximum 65535 vlan voice
no switchport port-security
switchport port-security aging time 0
switchport port-security violation shutdown
switchport port-security aging type absolute
switchport port-security limit rate invalid-source-mac 10
no switchport port-security mac-address sticky
no switchport port-security aging static
no ip arp inspection trust
ip arp inspection limit rate 15 burst interval 1
ip arp inspection limit rate 15
shutdown
no mab
snmp trap mac-notification change added
snmp trap mac-notification change removed
snmp trap link-status
spanning-tree portfast disable
spanning-tree portfast trunk
spanning-tree portfast
spanning-tree port-priority 128
spanning-tree cost 0
ip igmp snooping tcn flood






























naaa... I just grabbed an interface config from 'show run all' LoL AF

[NetworkGroover]

Here's mine off one of my 4900's


interface TenGigabitEthernet1/5
description Demo Port
switchport
switchport access vlan 4000
switchport private-vlan trunk encapsulation dot1q
switchport private-vlan trunk native vlan tag
switchport mode access
switchport nonegotiate
no switchport protected
no switchport block multicast
no switchport block unicast
switchport port-security maximum 1
switchport port-security maximum 65535 vlan
switchport port-security maximum 65535 vlan access
switchport port-security maximum 65535 vlan voice
no switchport port-security
switchport port-security aging time 0
switchport port-security violation shutdown
switchport port-security aging type absolute
switchport port-security limit rate invalid-source-mac 10
no switchport port-security mac-address sticky
no switchport port-security aging static
no ip arp inspection trust
ip arp inspection limit rate 15 burst interval 1
ip arp inspection limit rate 15
shutdown
no mab
snmp trap mac-notification change added
snmp trap mac-notification change removed
snmp trap link-status
spanning-tree portfast disable
spanning-tree portfast trunk
spanning-tree portfast
spanning-tree port-priority 128
spanning-tree cost 0
ip igmp snooping tcn flood






























naaa... I just grabbed an interface config from 'show run all' LoL AF

Yeahhhhh I was like.... yeah right.

[SimonV]

Forgive my lack of knowledge but what would be the purpose of making a non-existent/inactive vlan the native vlan?

When someone connects to one of your trunk ports and sends untagged traffic, it gets black-holed. It's a long shot though, there might be better reasons too but that's how I justify it

Ok, point taken for servers and access points, but I guess you wouldn't expect BPDUs there either? For trunks going to ESXi, I also set bpduguard. More to protect someone from accidentally putting a switch in those ports in the distant future (speaking from experience)

[Reggle]

So you're saying if I already have bpdu guard then root guard is not needed?

Correct, BPDU guard will shutdown a port whenever a BPDU is received and put it in err-disable mode. 
Root Guard will only act when a BPDU with superior priority than the current Root is received.

To elaborate on that, there was a topic here about a year ago where I defended that we used both, so we could see if the BPDU that caused the err-disable was superior or not. Someone from this forum labbed it and found that BPDU Guard always takes precedence when enabled on the port (proving me wrong). So Root Guard is redundant here.

[wintermute000]

I'd make it maximum MAC address 2 (VOIP phone + PC) unless you have a use case where people randomly plug in belkins into conference rooms (hahahahaha).

I'd also limit broadcast and multicast to 10%, assuming 1Gb ports - unless you have a use case where a port should be receiving > 100M worth of broadcasts or multicasts?

Root guard is redundant on access ports if portfast is enabled and bpduguard is enabled globally on portfast. Reggle is right, any BPDU and err-disable. Speaking of that, I'd remove bpduguard off individual ports and just enable it globally for portfast. Set your err-disable recovery time as well to balance between safety vs number of helpdesk calls.

I'm not sure of the value of using sw nonnegotiate when you're already explicitly setting sw mode access.

[Reggle]

I'd make it maximum MAC address 2 (VOIP phone + PC) unless you have a use case where people randomly plug in belkins into conference rooms (hahahahaha).

I ran into trouble with that years ago where the IP Phone would count as two MAC addresses: one on the voice VLAN, and one on the access (native/untagged) VLAN due to CDP. So you may want to test your particular switch/phone combination on this limit before putting it into production.

[deanwebb]

Test before going into production?

If the DB guys don't have to do that, why should I?