Hello Stephane,
To your question 1)
I am somewhat confused by the picture you have included - you are talking about switches, yet the topology as depicted in your exhibit contains routers.
If the topology consisted of routers then by definition, routers would neither forward nor flood link-layer broadcasts so no loops would occur.
If the network consisted of switches without STP running, there is indeed a possibility of a frame looping. A frame would certainly loop if its destination MAC address is unknown to switches, or if its destination MAC is a broadcast/multicast address. The reason is that all such frames are flooded through all ports except the incoming port, and would eventually reach the same switch they originally came from.
If the switching tables were already correctly populated with correct MAC addresses and outgoing ports (i.e. knowing all connected stations and pointing towards loop-free shortest paths), loops would not occur because the frame would be forwarded through a single port only, presumably on the shortest switched path towards the recipient. However, as soon as a frame towards a new so-far-unknown destination or multicast/broadcast address was received, it would again get stuck in a loop. In a switched topology where no Layer2 loop protection is activated, the apparent loop-free operation is a very volatile and unstable state.
To your question 2)
I am afraid there is no command of the form spanning-tree portfast edge bpduguard default - the "edge" keyword here is superfluous. The correct syntax should be simply spanning-tree portfast bpduguard default
In any case, the command spanning-tree portfast bpduguard default does not activate PortFast on all non-trunking interfaces. It simply activates the BPDUGuard feature on those ports which are already PortFast-enabled. How the ports came into the PortFast mode is not relevant to the command.
Writing simply spanning-tree portfast bpduguard default without using the spanning-tree portfast default would therefore enable the BPDUGuard only on those interfaces which have explicitly been configured using the spanning-tree portfast command in their interface configuration mode (note that this command has no effect on trunking interfaces, and hence the BPDUGuard would also not be activated on them as a result).
Writing both spanning-tree portfast bpduguard default and spanning-tree portfast default would make all non-trunking ports implicitly behave as PortFast ports, and exactly those ports would then be protected by the BPDUGuard feature. No spanning-tree portfast interface-level command would be necessary here.
Please feel welcome to ask further.
Best regards,
Peter
