the last digit of switch's base Ethernet MAC address changed in advertisements.

[ssreejesh]

Ive got a 3760 switch connecting via it's fa1/0/1 to a 3560 switch connecting on its fa 0/1.

the Base Ethernet MAC Address of my L3S1-3760 is    : 00:13:1A:E8:DC:00

and  Base Ethernet MAC Address of my L3S2-3650 is  : 00:1B:2B:E5:14:80

However in the mac tables the last digit of the neighboring switch's mac address is changed from a '0' to a '3'

L3S2-3560#sh dtp int fa 0/1 

DTP information for FastEthernet0/1: 

  TOS/TAS/TNS:                              TRUNK/AUTO/TRUNK 

  TOT/TAT/TNT:                              802.1Q/NEGOTIATE/802.1Q 

  Neighbor address 1:                       00131AE8DC03 
 

fyi: output trancated 

L3S1-3760#sh dtp int fa 1/0/1 

DTP information for FastEthernet1/0/1: 

  TOS/TAS/TNS:                              TRUNK/ON/TRUNK 

  TOT/TAT/TNT:                              802.1Q/802.1Q/802.1Q 

  Neighbor address 1:                       001B2BE51483 

fyi: output truncated 

L3S1-3760#sh mac- 

          Mac Address Table 

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

Vlan    Mac Address       Type        Ports 

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

    1    001b.2be5.1483    DYNAMIC     Fa1/0/1 

refer picture attached:

The Switch on the left, L3S1-3760 learns the MAC-address of the switch on the right as 001b.2be5.1483 

Via the interface fa 1/0/1 from incoming frames sent by the switch on the right L3S2.

the base Ethernet MAC address of L3S2 is  001b.2be5.1480. 

It however advertises its address as 001b.2be5.1483. The Last digit of the MAC address is changed from a

‘0’ to a ‘3’.

Both switches seem to have changed the last digit of their base mac address in their neighbor advertisements.

Why is that? Does DTP or some other protocol replace the last digit of the switch’s base MAC address with a code of some sort?

[milan.kulik · Accepted solution]

Hi,

I believe DTP is using the switch port MAC address as a source one.

Which is derived from the switch base MAC address by adding a port index to the end.

That is the change for 0 to 3 on port Fa 0/1.

If you try on port Fa0/2, you would see 4 in the end of the MAC address, I guess?

Best regards,

Milan

[ssreejesh]

Hi Milan,

Your guess is pretty close. Conceptually right. I saw that if I had multiple links between two switches,

dtp uses a different mac -address for each link.  this mac address is only used by the dtp protocol for

dtp traffic pertaining to a specific link. they show up in the mac address table. 

the numbers used by dtp are something like d,e etc., in the last field, it may have some logic to it.

If you loo at the mac address table and see closely resembling mac addresses that differs only in their last letter or number, they are most likely redundant links. for trunk links they show up in every vlan in the mac -address table. Rightly so. wonder if the switch then has to send dtp traffic duplicated for each vlan. this might drive up the bandwidth usage. a non-negotiate therefore helps a lot on trunk links. wonder if there are any cons to setting a trunk to non-negotiate.

thank you for your input.

[milan.kulik]

Hi, my understanding is: If looking at the mac address table you see closely resembling mac addresses that differs only in their last letter or number in every vlan on trunks, I believe they are not due to DTP traffic. As DTP negotiation should stop when the ports moves to the trunk status, shouldn't it? So I believe these MAC addresses could be also used by STP BPDUs? If I'm right you might see them on one trunk side only, not on the other trunk side? The cons to setting a trunk to non-negotiate are following: The port will become a trunk no matter of the other side port status. So it the other side port is configured as an access port (even with negotiaition enabled) or not supporting trunk negotiation (non-Cisco, e.g.), it will remain an access port. So you will finish in a discrepancy: a trunk port on one switch connected to an access port on the other switch. Best regards, Milan

[ssreejesh]

Will there be DTP traffic after negotiation?

All Layer-2 and Layer-3 protocols have hello timers.

DTP hello messages are sent every 30 seconds.

 In case you change the VTP domain name after the trunk is established, the DTP will send that ' text string ' in its packet across the trunk to the neighbor switch. the neighbor switch will notice the changed VTP domain name and take down the link.

Even in the Layer-2 trunk link down state the DTP hello packets go through and when you revert the VTP domain name to match on both sides, DTP will bring the trunk back up.

Whenever a change is configured on the trunk or in stp or in vtp, it triggers a dtp exchange even after the trunk is established.

the only time dtp is never sent is when the dtp non negotiate command is issued.

[milan.kulik]

Hi,

yes, you are correct, DTP frames are sent every 30 seconds on trunks.

But NOT in all VLANs.

DTP is sent in the native VLAN only, VTP in VLAN1 only on 802.1Q trunks.

See http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/24330-185.html#pre6

Best regards,

Milan

[ssreejesh]

yea, untagged frames pretty much is whats used by DTP frames.

native vlan on dot 1 q, ( can be changed from the default ,vlan 1 to any other vlan) but if its ISL, then its strictly vlan 1.

DTP need not transmit hello packets on every vlan (it cannot since it goes in untagged frames, and ) since it is meant for the switch and not an end device.

DTP generates a lot of dtp traffic. you can see it when you turn on a debug dtp all ( try it out in the lab )

here are the timers that dtp uses,

Hello timer

Access timer

Negotiation timer

Multidrop timer

am looking for and am interested to find the purpose of a Multidrop timer.

normally when there are redundant links, you want to have the preference of a bad link reduced automatically, one that

has a lot of errors on it even if spanning tree might prefer that link.

I have to figure out what each timer is used for. 

Apart from this DTP uses Finite state machines, that decide which state a trunk link should be in.

each redundant link uses a different neighbor base Ethernet mac that differs in the last one or two digits.

so if you can use the non-negotiate command , the switch will be very obliged.

Less load on the CPU.