Have never seen this..portfast prevents mac learning ?

[gnijs]

I have a C3750v2 running 12.2(50)SE4. On this switch we connected a Fortigate 50B device with a static ip address.

I configured the port standard as "switchport access , switchport access vlan xxx, spanning tree portfast". We are running

rstp. Now, the interface comes up, but i don't see any inbound packets. The port also doesn't learn any mac addresses (no inbound packets).

When i disable "spanning tree portfast", the port walks true standard spanning tree states: blocked, learning, forwarding and then everything works.

At learning state, i can see the mac address being learned and at forwarding state, a ping request works.

This is very strange. The box is not running spanning tree itself (i don't see any BPDUs, it also does not get blocked by bdpuguard). It just seems that when using "portfast" the port initialises too fast for the box. I checked with a sniffer and the box itself is sending ARP requests regularly for the default gateway (and multiple requests). I don't know why in "portfast mode" even after several seconds and ARP requests , the mac is not added. I tried changing auto mdix, power inline never, carrier delay 5, all made no difference. Freaks me out...

[Peter Paluch]

Hi Geert,

I am not sure if I understand the exact problem you are trying to solve. Are you saying that with spanning-tree portfast, the 3750 switchport merely does not learn MAC addresses but the Fortigate can communicate, or is also the connectivity broken?

Are you by any chance using switchport block on the switchport, or any other not-that-typical commands? What global spanning tree features are activated?

Haven't seen this before It piques my interest. Certainly, the spanning-tree portfast should have absolutely no impact on MAC address learning, quite the contrary - it prevents MAC address flushes from edge ports during TC handling in RSTP.

Best regards,

Peter

[gnijs]

Peter,

[1] with the command "spanning-tree porfast", the port comes up. I can see outbound packets. Inbound packets remains at 0 and the port does not learn any mac addresses. A sniffer capture on the fortigate shows that it is receiving (the outbound) packets and it is sending ARP requests for the default gateway.  But apparently, they are not received by the switch since inbound statistics remain at 0. I connected the fortigate to my PC and sniffed the ARP requests. They are normal ARP requests without VLAN tagging or so. (i have already changed the cable and so)

[2] when i remove "spanning-tree portfast", the port comes up. Goes to block mode, then learning mode then forward mode. At learning mode, now, the switches DOES learn mac addresses and at forward mode everything works. (ping/connectivity/etc).

[3] i removed the "spanning tree portfast default" global command.

[4] we did have some special features on the port configured (ie port security etc), but i removed them all (default interface fa1/0/11). Then i configure the port with the absolute minimum to reproduce the issue and all it takes to reproduce the issue is:

switchport mode access

switchport access vlan 103

spanningtree portfast

[5] note: the issue happens at port link up. Once the mac is learned, i can enable portfast , then it continues to work, until i disconnect the cable or do a shut/no shut. Once the mac is removed and the cable is reconnected, with portfast, it doesn't learn any mac.

[6] it might be that the fortigate doesn't like rapid spanning tree packets. when i disable portfast, i fallback to standard stp (?)

[Peter Paluch]

Hello Geert,

[1] with the command "spanning-tree porfast", the port comes up. I can  see outbound packets. Inbound packets remains at 0 and the port does not  learn any mac addresses. A sniffer capture on the fortigate shows that  it is receiving (the outbound) packets and it is sending ARP requests  for the default gateway.  But apparently, they are not received by the  switch since inbound statistics remain at 0. I connected the fortigate  to my PC and sniffed the ARP requests. They are normal ARP requests  without VLAN tagging or so. (i have already changed the cable and so)

It would seem as if the port configured with the spanning-tree portfast was not unblocked for the particular VLAN at the hardware level when it jumps from Disabled to Forwarding state. What would show spanning-tree interface fa1/0/11 detail command display after connecting the Fortigate and having PortFast enabled on that port? Can you post the output here?

[3] i removed the "spanning tree portfast default" global command.

Consider putting it back. In RSTP environment, having ports to end stations designated as edge ports is crucial. If you need to avoid PortFast on the Fa1/0/11 port for our experiments, configure that port with spanning-tree portfast disable

[4] we did have some special features on the port configured (ie port  security etc), but i removed them all (default interface fa1/0/11).

This is actually a hint. There may be some kind of leftover programmed in the hardware that was not properly removed when you cleared the interface config. My suggestion: configure the port as follows:

interface Fa1/0/11

  switchport mode access

  switchport access vlan X

  spanning-tree portfast disable

  switchport port-security mac-address sticky

  switchport port-security violation restrict

  switchport port-security

Let's try to see if the interface first learns and correctly adds the MAC address of the Fortigate into the list of secure MAC addresses. If it does, and the connectivity is fine, remove the spanning-tree portfast disable command (or replace it with spanning-tree portfast - simply I want you to activate PortFast on this port at this point), shut it down, wait a couple of seconds and put it back up. Let's see then if the port can communicate even if it jumps into Forwarding mode immediately, already knowing the MAC address of the station connected to it.

[5] note: the issue happens at port link up. Once the mac is learned, i  can enable portfast , then it continues to work, until i disconnect the  cable or do a shut/no shut

This is logical. The PortFast does not have any immediate influence on the port operation once the port has reached the Forwarding state, apart from preventing the port from generating TCs and being influenced by TCs and Sync operations in RSTP.

[6] it might be that the fortigate doesn't like rapid spanning tree  packets. when i disable portfast, i fallback to standard stp (?)

No, this cannot be the case. Running or not running PortFast on a port does not change the STP version on that port, nor in any way influences the way how BPDUs are sent and received.

Looking forward to your answer!

Best regards,

Peter

[Aninda Chatterjee · Accepted solution]

Wonderfully analyzed, Peter. I would also be interested in how the hardware programming looks while the port is 'broken'.

Could we get the following outputs please?

1. show platform pm if-numbers | in 1/0/11 |port

As an example, the output should look something like this:

Switch#show platform pm if-numbers | in 1/0/1 |port

interface gid  gpn  lpn  port slot unit slun port-type lpn-idb gpn-idb

Gi1/0/1   1    1    49   1/0  1    1    1    local     Yes     Yes

I am looking for the value under the 'port' column. This is of the format ASIC/PORT. So, this port is port 0 on ASIC 1.

2. show platform port-asic mvid asic

As an example, the output should look something like this:

Switch#show platform port-asic mvid asic 1

=====================================================================================

Mapped Vlan Id Table (port-asic: 1)

Index Labels  ttl st vlan mtu  bg i2q df  m64a svi untagged blk-lrn blk-fwd vp-errd site-id

-------------------------------------------------------------------------------------

1     00000000 2   0  1    1518 0  1    0 0010 240 3FFFFFF  3FFFFEF 3FFFFEF 0000000 1

2     00000000 2   0  2    1518 0  2    0 0000 200 3FFFFFB  3FFFFFB 3FFFFFB 0000000 2

3     00000000 2   0  103  1518 0  3    0 0000 200 3FFFFFB  3FFFFFB 3FFFFFB 0000000 3

4     00000000 2   0  104  1518 0  4    0 0000 200 3FFFFFB  3FFFFFB 3FFFFFB 0000000 4

5     00000000 2   0  105  1518 0  5    0 0000 200 3FFFFFB  3FFFFFB 3FFFFFB 0000000 5

6     00000000 2   0  10   1518 0  6    0 0010 241 3FFFFFB  3FFFFFB 3FFFFFB 0000000 6

Several important things here and all of these are what Peter is looking for, I believe. We'd want to check what the bit values are for the port we are interested in for the blk-lrn and the blk-fwd columns. The blk-lrn decides if mac-learning is allowed or not and the blk-fwd determines if the port is forwarding or not. The 'vlan' column, of course, lists the corresponding VLANs.

You need to read this from right to left and convert every bit into its hex value. So, F would be 1111 and so on - this is very similar to how the CBL values are read on a 6500 as well.

If the bit is set, the port is blocking for that VLAN. If the bit is not set, it is forwarding for that VLAN. Similarly for the blk-lrn, if the bit is set, the port has mac-learning disabled. If the bit is not set, mac-learning is enabled.

I am not very familiar with this platform but I hope this helps in some way.

Regards,

Aninda

[gnijs]

Thanks guys for the feedback. Unfortunatly, the supplier had to return to his home country and take the fortigate device back with him (it was part of a test). We will initiate the procedure to buy a device, however, this will take time (at least 2 months i guess, heavy logistics i know). So i will put this topic on hold, but i will for sure return to continue the above tests. See/Hear you in a couple of weeks/months....

[Peter Paluch]

Hi Geert,

I strongly suspect that this issue was not related to the Fortigate device at all, and you can perform the test with any PC or an ISR router. Would you be willing to give it a try?

Best regards,

Peter

[Peter Paluch]

Aninda,

There are some very interesting internal information being shown by you here! Thank you!

Best regards,

Peter

[paolo bevilacqua]

Update IOS and check again.