STP BPDU Qns

[sivam siva]

Hi

can anyone please help me to answer this qns?

1)In what two ways is the IEEE STP BPDU frames sent when you have a native VLAN 953 set? (Choose two.)
A. IEEE STP BPDU frames are sent untagged over VLAN 953.
B. IEEE STP BPDU frames are sent tagged over VLAN 953.
C. IEEE STP BPDU frames are sent untagged over VLAN 1.
D. IEEE STP BPDU frames are sent tagged over VLAN 1.
E. IEEE STP BPDU frames for VLAN 1 and VLAN 953 are sent untagged over VLAN 953.

Answer:? 

I believe only A is correct.

2)Question about the behavior of VLAN 1 BPDUs in a situation where the native VLAN configured as VLAN 99 and the native VLAN is tagged. (Choose two.)

A. Normal STP VLAN 1 BPDU travel across VLAN 99 untagged
B. PVST+ VLAN 1 BPDU travel across VLAN 99 tagged
C. Normal STP VLAN 1 BPDU travel across VLAN 1 untagged
D. PVST+ VLAN 99 BPDU travel across VLAN 99 tagged

I believe answer: AD
can anyone confirm it?

As per my knowledge

IEEE BPDU (vlan 1) sent on native vlan (untagged), (to IEEE multicast MAC).

SSTP/PVST+   native vlan BPDU  sent on native vlan (untagged) (to cisco PVST+ multicast MAC).

SSTP/PVST+   other vlan   BPDUs sent on their own vlan (tagged) (to cisco PVST+ multicast MAC).

Thanks 

Siva

[Giuseppe Larosa · Accepted solution]

Hello Siva,

the IEEE STP standard format should be used only on native vlan

so I agree that only answer A should be correct in Q1.

>>

2)Question about the behavior of VLAN 1 BPDUs in a situation where the native VLAN configured as VLAN 99 and the native VLAN is tagged. (Choose two.)

A. Normal STP VLAN 1 BPDU travel across VLAN 99 untagged
B. PVST+ VLAN 1 BPDU travel across VLAN 99 tagged
C. Normal STP VLAN 1 BPDU travel across VLAN 1 untagged
D. PVST+ VLAN 99 BPDU travel across VLAN 99 tagged

D is correct ,

C cannot be correct as native vlan is 99 not 1 and native vlan is tagged.

However, for the standard IEEE STP BPDUs should travel untagged.

B for me it is not correct PVST / PVST+ will not mix BPDUs of different instances so standard IEEE STP should travel in vlan 1 so PVST+ Vlan 1 BPDU cannot travel over vlan 99 tagged (this would cause a consistency check to fail comparing external vlan tag with internal vlan field in PVST+ BPDU).

A again should not happen as the Cisco PVST should know to avoid to mix different instances.

Ok I see the trick part now: IEEE STP BPDUs have no vlan concept inside them, so answer A can be considered correct.

Hope to help

Giuseppe

[sivam siva]

Thank you very much @Giuseppe Larosa 

you said "the IEEE STP standard format should be used only on native VLAN"

so Q2 answer A should be correct isn't is?  (because native VLAN is changed to VLAN 99 and tagged).

for Q1 I have to choose two answers is it possible?.

And one more Qns please help me to understand

If I configure trunk native VLAN 2, normally that trunk should expect to receive VLAN 2 frame as untagged. what if that trunk receives a frame with tag 2 what will it do?.

Thanks

Siva

[Giuseppe Larosa]

Hello Siva,

yes I agree on answer A for Q1.

>> If I configure trunk native VLAN 2, normally that trunk should expect to receive VLAN 2 frame as untagged. what if that trunk receives a frame with tag 2 what will it do?

The switch should accept the frame with vlan tag 2 and correctly consider it belonging to vlan 2.

The modern trend is to have all user traffic tagged on trunk links, also the native vlan tagged is useful in QinQ services to avoid to expose the inner customer Vlan.

Edit:

1)In what two ways is the IEEE STP BPDU frames sent when you have a native VLAN 953 set? (Choose two.)
A. IEEE STP BPDU frames are sent untagged over VLAN 953.
B. IEEE STP BPDU frames are sent tagged over VLAN 953.
C. IEEE STP BPDU frames are sent untagged over VLAN 1.
D. IEEE STP BPDU frames are sent tagged over VLAN 1.
E. IEEE STP BPDU frames for VLAN 1 and VLAN 953 are sent untagged over VLAN 953.

I don't see a second answer that could be considered correct.

However, this can happen some exam questions and relative answers may not be totally accurate.

Hope to help

Giuseppe

[sivam siva]

Thank you very much @Giuseppe Larosa 

[sivam siva]

Hi @Giuseppe Larosa 

Sorry for posting again exam Qns, can you please help me to answer below Question?

What is the effect of the given configuration?
"spanning-tree extend system-id

spanning-tree mode pvst

spanning-tree backbonefast "
A. It enables the switch to become the spanning-tree root bridge.

B. It enables the reduced MAC address feature.
C. It enables spanning-tree to create dynamic system IDs.

D. It enables extended VLANs.

I believe Answer B

But many of them saying answer C is correct?

Thanks

Siva 

[Giuseppe Larosa · Accepted solution]

Hello Siva,

>> Sorry for posting again exam Qns, can you please help me to answer below Question?

What is the effect of the given configuration?
"spanning-tree extend system-id

spanning-tree mode pvst

spanning-tree backbonefast "
A. It enables the switch to become the spanning-tree root bridge.

B. It enables the reduced MAC address feature.
C. It enables spanning-tree to create dynamic system IDs.

D. It enables extended VLANs.

A and D are false.

B is true because with spanning-tree extend system id PVST instead of using a different MAC address for each STP instance it will use a Bridge ID made of base priority+Vlan-id  as Bridge Priority followed by the SAME MAC address.

C It enables spanning-tree to create dynamic system IDs.   

When you create a new vlan the corresponding bridge-id becomes priority+Vlan-id  as Bridge Priority followed by the SAME MAC address.

So we should understand what dynamic would mean here. Even in old way when creating a new Vlan PVST picks up an unused MAC address to build the Bridge-id for the new PVST instance. This could be considered "dynamic" too.

I agree that B is the most technically correct answer also because modern cisco switches cannot work without the command spanning-tree extend system-id as they have not enough MAC addresses to use the old way to build the bridge-id.

The MAC address reduction feature provides benefits to Cisco as a vendor to avoid to deplete its own MAC addresses when producing new switches. The OUI is registered with IEEE but it is better to minimize the number of used MAC addresses on each switch.

Hope to help

Giuseppe

[sivam siva]

Thanks a lot, @Giuseppe Larosa 

If you don't mind can I ask one more question?

[Giuseppe Larosa]

Hello Siva,

yes, of course, you can ask additional questions

Best Regards

Giuseppe

[sivam siva]

Thank you very much

Which two commands display IP Source Guard bindings? (Choose two.)
A. show ip source binding
B. show ip dhcp binding
C. show ip verify source
D. show ip dhcp snooping Binding 
E. show ip guard source

Below is my lab outputs

Answer: AC or AD?

source guard table can be is downloaded from snooping database so can we use "sh dhcp snooping binding" command to ensure the source guard bindings? 

the question asks "Bindings",   can we assume the output of "sh ip verify source"  is address bindings?

Thanks

Siva

[Giuseppe Larosa · Accepted solution]

Hello Siva,

in this case I would give preference to the most specific commands that show that ip source guard is configured and it is operating.

So I would choice A show ip source binding and C show ip source verify .

The D option provides the output of the show ip dhcp snooping table.

This output alone does not provide a proof that ip source guard is configured but only that ip dhcp snooping is configured and operational.

In cases like this you should prefer the most specific answers.

I agree that IP source guard relies on IP DHCP snooping enabled to simplify its configuration, but it is possible to use IP source guard without IP DHCP snooping enabled ( by creating manual binding entries that links together the IP address, the MAC address, the access port and the Vlan ) and what is more important is possible to use IP DHCP snooping without enabling IP source guard.

For this reason answer D is to be not selected as there is no evidence if IP source guard is enabled or not.

You can see this also on your lab test.

Hope to help

Giuseppe

[sivam siva]

Thank you for the reply @Giuseppe Larosa 

[sivam siva]

Hello  @Giuseppe Larosa 

Sorry for asking again same Question 

1)In what two ways is the IEEE STP BPDU frames sent when you have a native VLAN 953 set? (Choose two.)
A. IEEE STP BPDU frames are sent untagged over VLAN 953.
B. IEEE STP BPDU frames are sent tagged over VLAN 953.
C. IEEE STP BPDU frames are sent untagged over VLAN 1.
D. IEEE STP BPDU frames are sent tagged over VLAN 1.
E. IEEE STP BPDU frames for VLAN 1 and VLAN 953 are sent untagged over VLAN 953.

you said only answer A is correct fine, 

If we enable "Vlan dot1q tag native"  answer B is also possible right?

so there is a chance of sending IEEE BPDU over VLAN 953 tagged/untagged two ways, isn't it?!.

some people say the answer D is correct but I don't think It makes sense (because IEEE BPDU always sent over native VLAN, isn't it?)

Thanks 

Siva

[Giuseppe Larosa · Accepted solution]

Hello Siva,

I can tell you what happened to me in job:

two devices one Juniper switch and one IBM switch part of an IBM blade server were not able to interoperate in RSTP, because the Juniper switch was sending the RSTP BPDUs untagged and the IBM switch was sending them tagged.

As a result of this when we added a second link between the two devices a bridging loop occurred, we removed one cable and then we made a packet capture on Juniper side and we had seen the difference between sent untagged IEEE RSTP BPDU and received tagged with vlan 1 RSTP BPDU sent by other switch. Changing the configuration on the IBM side solved this issue.

For IEEE standards the IEEE STP BPDUs should travel untagged as far as I know, this is why we say that it follows the native Vlan settings.

If you enable the Vlan dot1q tag native this command applies for sure to user traffic in native Vlan, to Cisco PVST+ / Rapid PVST, but some layer2 protocols may still travel untagged if required by their standard specifications.

However , this is implementation dependent and should be tested, but as I tried to explain with an example above tagging IEEE STP BPDUs can cause interoperability issues.

The modern trend of many vendors is to allow by default untagged traffic only for control protocols and to do not allow user traffic to travel untagged.

That in Cisco terms should be equivalent to have Vlan dot1q tag native enabled by default.

Edit:

You can find the 802.1D year 2004 specification here for free but you need to create an account as individual to access the content.

https://ieeexplore.ieee.org/browse/standards/number/ieee?queryText=802.1D%202004

Edit 2:

>> If we enable "Vlan dot1q tag native" answer B is also possible right?

After seeing your lab test results on the other thread I agree that answer B is acceptable, if native is 99 but the command for native Vlan tagging is enabled IEEE STP can travel tagged in Vlan 99.

If the native Vlan is 1 the default one the IEEE STP BPDU are sent always untagged regardless of native vlan tagging settings.

Hope to help

Giuseppe

[sivam siva]

@Giuseppe Larosa 

Need one more Help, please

A network engineer has just configured a fiber connection between two switches. The connection has been set up as an EtherChannel. Shortly after
powering the device on, the fiber port err-disables. What is the most likely cause?

A. UDLD standard mode has been set up on the interface.
B. Spanning tree has disabled the port.
C. UDLD aggressive mode has been set up on the port.
D. The EtherChannel configuration is incorrect.

I believe Answer D
but many people says Answer: C

Why D is correct:

Assume if UDLD aggressive mode is enabled. when device boot they don’t have any captured information about neighbor initially until another end device sends UDLD echo back. so it’s not possible to errdisable while booting.

The question says Etherchannel has just configured, so there could be a misconfiguration,
Note: “spanningtree etherchannel guard misconfig ” is enabled by default on cisco switches,
so answer D could be correct

I have not tested this in Lab because I don't have enough Fiber module

Any suggestion, please …

---

Thanks 

Siva