Spanning-Tree with portfast enabled globally bad idea?

[Joshua_521]

I am new pretty new to networking and am trying to understand my orginizations current configs. We have a large hub and spoke network, but my question is for the remote side of the house. On the remote we have 3 seperate networks (2 user and 1 transport). On the transport we have a 2811 rtr and a 3560G. The 3560G runs to two HAIPE devices (KG-250's) that have our 2 user networks behind them.

On the user network it is just 1 3560G that is essentially an access switch for our users. We run 2-3 Vlan's on these switches, but all ports on the switch are access mode. We also use a Riverbed (network accellerator) on the user networks. The attached layout shows cabling layout and vlan association. Here is the configs  we have for our access switches.

Globally

spanning-tree mode rapid-pvst

spanning-tree portfast default

spanning-tree extend system-id

spanning-tree vlan 2-3 priority 24576

Interfaces 1 & 2

switchport access vlan 3

switchport mode access

switchport port-security

switchport port-security mac-address sticky

no cdp enable

spanning-tree bpdufilter enable

spanning-tree bpduguard enable

spanning-tree guard root

Interfaces 47 & 48

switchport access vlan 98

switchport mode access

no cdp enable

From my understanding running portfast on a port disables spanning-tree and the portfast default command enables it on all access ports which all of the ports on these switches are. Besides trunking ports, which we dont do, arent all ports on a switch layer 2 access ports? If so, why would you enable portfast and stp globally? Wont portfast override and cancel out STP? Also, isn't overkill or unneccessary to run bpdufilter, bpduguard, & guard root on all of our ports?

**Quick note: I did some testing to see how bpdu's ran through this layout. I took off filter and guard root just leaving bpduguard on all of the ports. And ports 47 (Riverbed WAN) and port 1 (Riverbed LAN) kept err-disabling.** None of the other ports received bpdu's**

[Peter Paluch · Accepted solution]

Hello Josh,

In RSTP networks, properly identifying edge ports (i.e. PortFast ports) is crucial to maintain rapid convergence and protect connected devices from being temporarily disconnected from the network should a topology change propagate through the switched infrastructure. The spanning-tree portfast default command activates the PortFast feature on access-mode ports only. Therefore, using this command is not dangerous as long as you do not use access-mode ports to connect to another Layer2-switching devices that may introduce loops into your network.

Running PortFast on a port does not disable STP on that port at all. The STP still sends and receives BPDUs on that port, just like on any other ports. The difference to a normal port is twofold: a PortFast port becomes Forwarding immediately after being connected, and second, connecting or disconnecting a station from a PortFast port does not generate topology changes in STP.

Besides trunking ports, which we dont do, arent all ports on a switch layer 2 access ports?

If they are configured with switchport mode access command then yes, they are access ports. However, not every access port is an edge port - that depends on the device that is connected to that port. If it is another switch or a similar switching/bridging device then the ports is not an edge port and hence should not be configured with PortFast. If the port connects to a PC, network printer, firewall, router, etc. - in general, if that device forms a boundary to a broadcast domain - then it is an edge port and should be PortFast-enabled.

If so, why would you enable portfast and stp globally?  Wont portfast override and cancel out STP? Also, isn't overkill or unneccessary to run bpdufilter, bpduguard, & guard root on all of our ports?

PortFast does not cancel STP in any way. STP still fully runs on PortFast ports. It's just that these ports do not cause topology changes, are not influenced by topology changes and become Forwarding as soon as they are brought up.

Regarding the overkill: In a sense, it is. In particular, running BPDU Filter and BPDU Guard simultaneously on a single port does not make sense. The BPDU Filter configured on a port prevents this ports from sending and receiving BPDUs completely. The BPDU Guard on the same port is therefore useless because received BPDUs will be dropped thanks to Filter sooner than they can hit the Guard. If you do not know about a particular reason to use the BPDU Filter on your ports, I suggest removing it from your configuration.

Best regards,

Peter

[Joshua_521]

I know currently in our remotes topology if bpduguard is enabled on ports 1 or 47 (Riverbed) they will constantly just be err-disabled and traffic will not go out, so I removed all guard and filter on these ports. I dont know where the bpdu's were coming from since there are no directly connected switches. Will Vlans propogate bpdu's to each other? Ports 1 & 47 are in different vlans.

[cadet alain]

Hi,

No BPDUs are not propagated between VLANs.

Regards.

Alain

[Edwin Summers · Accepted solution]

Cadet_alain is correct, but one point of clarification in your specific instance.  The switch does not propagate BPDUs between VLANS, but remember how VLANs work.  In your case, you noted you are not using trunking.  Therefore, VLANs will be significant only locally on the switch.  Therefore, for the purposes of your diagram, you can "cut" the switch so that there are two switches...with ports fa0/1-46 as one switch, and ports fa0/47,48 as the second.  So, the BPDUs you are seeing are coming from the same switch and traversing your Steelhead (as it will basically act as an L2 passthrough unless it is optimizing or actively blocking).

Question - I don't know the larger picture of your specific application, but is there any specific reason you are not connecting directly from the Steelhead WAN0_0 interface to the cyphertext interface of your crypto?  This would be perfectly fine for a production set-up, though I understand you may be trying to sniff the optimized traffic via a SPAN port or something.

[Joshua_521]

Wow thank you very much, I could not figure out where those bpdu's were coming from and why only those two ports were affected. This also makes clarifies another piece of the puzzle for me. Whenever the full transmission path was up this did not happen. (Riverbed was optimizing).

The CT side of our crypto plugs into an entirely different network. It is considered our "Black" or "Transport" network. We have several networks that tie into the black network. The layout of the diagram is for our remote kits that need to pull services over a satcom shot that resides on the black network.

[Edwin Summers]

Sorry, you are correct - it has been a long week.  I should have said "plain text"...  Can you link directly into your plain text (red) side from the Riverbed WAN port, or are you doing something else (such as SPAN) with the optimized traffic?

[Joshua_521]

We do not use SPAN as far as I know. I will be honest, I have no idea why we don't do that. The design of our networks and equipment layout comes from the engineering department (well above my pay-grade). I don't see why that wouldn't work. From my point of view it wouldn't affect anything. On our access switches the configs are pretty simple. I do know that in order to get traffic out I have to put an any any ip route statement to the PT of the KG. I was told it should work without the route statement, but for some reason I couldn't get it to work without it. Also, in the Riverbeds we set our gateway's to the PT.

For my area I am tasked with creating a baseline config (of course without straying to far from the engineers standard) for our switches and would love to better optimize traffic. Here is a running config from one of the switches, maybe you can see something I am overlooking that indicates why we don't plug directly into the KG and anything else that could be better, I would love your input.

no service pad

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname sw

!

logging buffered 16000 informational

logging console notifications

logging monitor informational

!

!

aaa new-model

!

clock timezone GMT 0

vtp domain xxx

vtp mode transparent

ip subnet-zero

no ip source-route

ip routing

ip tcp synwait-time 10

no ip domain-lookup

ip domain-name xxx

no ipv6 cef

!

!

ip dhcp excluded-address xx

ip dhcp excluded-address xx

!

ip dhcp pool VOICE

  network xx

  option 150 ip Call Manager

  default-router vlan 2

!

ip dhcp pool DATA

  network xxx

  default-router vlan 3

  dns-server xx

!

!

!

crypto key generate rsa

1024

!

!

ip ssh authentication retries 2

ip ssh version 2

!

!

spanning-tree mode rapid-pvst

spanning-tree portfast default

spanning-tree extend system-id

spanning-tree vlan 2-3 priority 24576

!

!

vlan internal allocation policy ascending

!

!

vlan 2

name Voice

no shutdown

!

vlan 3

name Data

no shutdown

!

vlan 98

name Riverbed_KG

no shutdown

!

vlan 900

name BitBucket

shutdown

!

!

!

interface GigabitEthernet0/1

description // CONNECTION TO RIVERBED LAN_0 \\

switchport access vlan 3

switchport mode access

no cdp enable

spanning-tree bpdufilter enable

no shut

!

interface GigabitEthernet0/2

description // CONNECTION TO RIVERBED PRIMARY \\

switchport access vlan 3

switchport mode access

no cdp enable

spanning-tree bpdufilter enable

no shut

!

interface range GigabitEthernet0/3-16

description // *****DISABLED***** \\

power inline never

switchport mode access

switchport access vlan 900

switchport port-security

switchport port-security mac-address sticky

no cdp enable

spanning-tree bpdufilter enable

shutdown

!

interface range GigabitEthernet0/17-32

description // DATA PORTS \\

power inline never

switchport access vlan 3

switchport mode access

switchport port-security

switchport port-security max 5

switchport port-security mac-address sticky

no cdp enable

spanning-tree bpdufilter enable

no shut

!

interface range GigabitEthernet0/33-46

description // PHONES \\

switchport mode access

switchport access vlan 2

switchport port-security

switchport port-security max 5

switchport port-security mac-address sticky

spanning-tree bpdufilter enable

no shutdown

!

interface GigabitEthernet0/47

description // CONNECTION TO RIVERBED WAN_0 \\

switchport access vlan 98

switchport mode access

no cdp enable

no shut

!

interface GigabitEthernet0/48

description // CONNECTION TO RED LAN OF CRYPTO \\

switchport access vlan 98

switchport mode access

no cdp enable

no shut

!

interface range GigabitEthernet0/49-52

description // Unused Port ----- Disabled ------ \\

switchport access vlan 900

switchport mode access

switchport port-security

switchport port-security mac-address sticky

no cdp enable

spanning-tree bpdufilter enable

shutdown

!

interface Vlan1

description // UNUSED VLAN \\

no ip address

shutdown

!

interface Vlan 2

description // VOICE VLAN \\

ip address yyy

no ip redirects

no ip unreachables

no ip proxy-arp

no Shutdown

!

interface Vlan 3

description // DATA VLAN \\

ip address xxx

no ip redirects

no ip unreachables

no ip proxy-arp

no shutdown

!

!

ip classless

!

!

ip route 0.0.0.0 0.0.0.0 (PT side of KG)

no ip http server

no ip http secure-server

!

!

ip access-list standard VTY_in

permit any

deny   any log

!

no cdp run

radius-server source-ports 1645-1646

!

control-plane

!

!

line con 0

exec-timeout 0 0

logging synchronous

line vty 0 4

access-class VTY_in in

transport input ssh telnet

transport output ssh telnet

line vty 5 15

transport input none

transport output none

!

end

[Edwin Summers]

I think I see your "issue".  Your dhcp statements include "default router" statements that instruct your clients to use the vlan interfaces (2 and 3) as their default router. You could change the default router to your KG's PT interface (same as your Riverbed gw) for your data network (vlan).  I'm assuming you separate your data and voice traffic, so if the KG PT, Riverbed, and vlan3 are in the same network, vlan 2 / voice will be in a different network and will need a router to find its way to the KG.  So, the vlan2 interface would remain the default router for voice, while the KG PT could be the default router for data.  You would still need the default route statement to get the voice traffic to the KG and out, however, so it's somewhat of a wash.

As far as other configs, you're not performing anything complex (which is always good!  less management strain...) so I'd just recommend what you already know or have been told: follow your IA guidance or design to DISA STIGs or NSA SNACs.  At a minimum, that would probably include modifying your ip access-list for VTY-in (currently permits any), and perhaps removing telnet as a management protocol.

[Joshua_521]

We try to stick to the STIG's as much as possible. The config above is implemented in a training environment and then adjusted slightly before put into a real world environment. That's when we will modify the access-list, remove telnet, & add authentication.

I will get with my engineering department on Monday to see why we are not plugging the WAN to the PT, then post their response.

Thank you very much for your help,

Josh

[Joshua_521]

Just wanted to follow up on the why we don't plug the WAN directly into the PT. One of the engineers told me it is because we use a couple different types of encryption devices that each require a different MTU size. This can sometimes cause an issue when trying to GUI into the crypto. Instead of having techs change the MTU size in the computers registry or on the encryption device just to GUI in, they set it up this way.

I did some testing on my own by plugging the WAN directly into the PT and it worked perfectly fine and freed up two ports so who knows.

[cadet alain]

Hi,

PortFast doesn't disable STP, what it does is bypass the listening and learning phase( which take 15 sec each) to speed up STP convergence and also it disables TCN BPDUs sending when you shut/no shut the port.

You can enable PortFast either globally and then it will apply to all access ports or per port.

I don't see the advantage of enabling the three security features on a port.On access port I would only configure BPDU guard as it is supposed to be linked to a host so no BPDUs should be seen on this port and if it is the case then the port will be put in errdisabled state.To get it out of that state you have to shut/no shut the port or configure errdisable recovery.

Regards.

Alain.