Options

VTP domain mismatch

anisanis Member Posts: 34 ■□□□□□□□□□
I have a 3560 switch. The config is.

version 12.2
no service pad
service timestamps debug uptime
service timestamps log datetime
no service password-encryption
service sequence-numbers
!
hostname awccsw
!
enable secret 5 $1$y0F/$LskrU2W5hPk381h3LtqIr1
enable password 123456
!
no aaa new-model
vtp domain cisco
vtp mode transparent
ip subnet-zero
!
cluster enable test 0
!
!
no file verify auto
!
spanning-tree mode pvst
spanning-tree extend system-id
no spanning-tree vlan 1
!
vlan internal allocation policy ascending
!
!
interface FastEthernet0/1
no switchport
ip address 192.168.44.115 255.255.255.0
!

interface FastEthernet0/2
!
interface FastEthernet0/3
(...................output cut.....................)
interface FastEthernet0/47
!
interface FastEthernet0/48
!

interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface GigabitEthernet0/3
!
interface GigabitEthernet0/4
!
interface Vlan1
no ip address
!
ip classless
ip http server
ip http secure-server
!
!
snmp-server community public RO
snmp-server community public@es0 RO
!
control-plane
!
!
line con 0
line vty 0 4
password 123456
login
line vty 5 15
password 123456
login
!
end


Now, FastEthernet 0/5 is connected to a D-Link switch. This port is showing the following error message:

000195: *Mar 1 02:45:45: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotia
tion on port Fa0/5 because of VTP domain mismatch.


My point is:

1. If the VTP domain mode in the switch is transparent, where is the error coming from?

2. The other end is just a D-link switch, why its asking for trunk negotiation. I tried with setting it as a trunk port which did not solve the error.

At first, the port was not working at all (orange) and showing "Inconsistent port type". I turned off STP for the default vlan (I mean the vlan1, there is no other vlan configured here). Now the port is working, still its showing the above error.

How can I solve this issue?

Comments

  • Options
    GT-RobGT-Rob Member Posts: 1,090
    Even though the switch is set to transparent mode, it still needs to be in the same domain as the switches it trunks with. I did this in a lab not too long ago but cannot remember my results as its 5:30 am and I have been at work with a network change for 7hrs now. Something about packets are still sent once in a while or something. My eyes hurt. I dont know your solution to this assuming you want to keep VTP on and the dlink in the mix.



    as for the trunk port, can you go into the d-link switch and set whatever you are plugging into to be a trunk? Just hardcode each side to be a trunk, not just one.


    dlink sux0r
  • Options
    Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    VTP is cisco proprietary, turn it off for interoperability.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • Options
    dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    Paul Boz wrote:
    VTP is cisco proprietary, turn it off for interoperability.

    You can't turn off VTP on a switch, and it's already in transparent mode which is as close as it can get.

    You need to add the command "switchport nonegoiate" on the interface to turn off DTP.


    If your goal is to form a trunk you will need to set the interface mode to "switchport trunk encapsulation dot1q" and "switchport mode trunk". If you want it to be an access link (if the dlink switch is not capaiable of trunking) then set it to "switchport mode access"
    The only easy day was yesterday!
  • Options
    Paul BozPaul Boz Member Posts: 2,620 ■■■■■■■■□□
    dtlokee - Thanks for clarifying. I was reading about IEEE vlan trunking and assumed that VTP was capable of being turned off to use the IEEE specification but I don't see any cisco support for it.
    CCNP | CCIP | CCDP | CCNA, CCDA
    CCNA Security | GSEC |GCFW | GCIH | GCIA
    pbosworth@gmail.com
    http://twitter.com/paul_bosworth
    Blog: http://www.infosiege.net/
  • Options
    ReardenRearden Member Posts: 222
    I just recently read something about a potential pitfall with trunk negotiation and VTP. Since the links in the config weren't explicitly set, they're dynamic desirable. I just can't remember exactly what the potential problems was. Can someone enlighten me? My Cisco books are at home and I'm in the library at the moment.
    More systems have been wiped out by admins than any cracker could do in a lifetime.
  • Options
    ReardenRearden Member Posts: 222
    Found what I was thinking of:

    Source: http://www.cisco.com/warp/public/473/21.html

    Dynamic Trunking Protocol (DTP) sends the VTP domain name in a DTP packet. Therefore, if you have two ends of a link that belong to different VTP domains, the trunk does not come up if you use DTP. In this special case, you must configure the trunk mode as on or nonegotiate, on both sides, in order to allow the trunk to come up without DTP negotiation agreement.


    The reason that it's trying to negotiate is that you haven't told it anything else. By default, the ports are in the dynamic desirable mode.

    However, I'm still not quite sure why you're getting the domain mismatch error.
    More systems have been wiped out by admins than any cracker could do in a lifetime.
  • Options
    APAAPA Member Posts: 959
    Rearden wrote:
    Found what I was thinking of:

    Source: http://www.cisco.com/warp/public/473/21.html

    Dynamic Trunking Protocol (DTP) sends the VTP domain name in a DTP packet. Therefore, if you have two ends of a link that belong to different VTP domains, the trunk does not come up if you use DTP. In this special case, you must configure the trunk mode as on or nonegotiate, on both sides, in order to allow the trunk to come up without DTP negotiation agreement.


    The reason that it's trying to negotiate is that you haven't told it anything else. By default, the ports are in the dynamic desirable mode.

    However, I'm still not quite sure why you're getting the domain mismatch error.

    Correct!! Major pitfall the dynamic deisrable state when connecting a non manageable switch......... If connecting an unmanageable switch or no intention to form a trunk I always lock the port down to an access port......

    I think you answered your own question as well....

    "Dynamic Trunking Protocol (DTP) sends the VTP domain name in a DTP packet. Therefore, if you have two ends of a link that belong to different VTP domains, the trunk does not come up if you use DTP"

    Because the switchport is still trying to negotiate a trunk via DTP due to not using the "switchport nonegotiate" command it is sending the vtp domain name in the DTP packets and then recognising that there is no domain name on the other side due to the unmanageable not supporting VTP......... Hence trunk not being established..... :D

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • Options
    ReardenRearden Member Posts: 222
    Ok, let me think about this for a second:

    Fact: Even though the switch is vtp mode transparent, IOS still forwards vtp packets.
    Fact: The OP didn't configure a domain. Oh wait, he did. . .


    So, it tries to send the vtp domain and sees that there is no domain on the other side of th link, hence domain mismatch, hence no link.

    So, in summary when using vtp transparent, you should use either no domain or the same name as the other switches or your trunk ports won't come up?
    More systems have been wiped out by admins than any cracker could do in a lifetime.
  • Options
    APAAPA Member Posts: 959
    If you use the following commands

    switchport trunk encapsulation dot1q (if neccesary)
    switchport mode trunk
    switchport nonegotiate

    Then the trunk will not be negotiated via DTP as you have told it not to negotiate dynamically and you have forced the port to trunk mode unconditionally. So trunk links will come up!!!! It's when you leave the port to negotiate trunks dynamically that you will come across this error as the DTP packets will have differing domain names.....

    In transparent mode you need to have the VTP domain matching (VTP v1) if you want the switch to forward on VTP advertisements to other switches connected to it...... In VTPv2 I'm 99% certain the domain name can be different and it will still forward on the VTP advertisements......

    Short answer....

    yes if you leave trunks to negotiate dynamically via DTP then the VTP domain names have to match as they are a vital part of the DTP packets..... :D

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • Options
    dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    A.P.A wrote:
    In transparent mode you need to have the VTP domain matching (VTP v1) if you want the switch to forward on VTP advertisements to other switches connected to it...... In VTPv2 I'm 99% certain the domain name can be different and it will still forward on the VTP advertisements......

    THe documentation is worded a little wierd on this one. It really works the same for both version 1 and 2. There is a little statement in the documentation that makes all the difference and it says something like "in version 2 the vtp domain name of all of the switches must match for it to be version 2". Youcan observe this by getting your VTP domain set up in version 1 then going to one of the servers and changing it to version 2. All of the server and client switches in the same VTP domain will also change their version.

    The short answer, for a VTP transparent switch to forward a VTP advertisement it's domain name must match what's in the VTP advertisement.
    The only easy day was yesterday!
  • Options
    APAAPA Member Posts: 959
    dtlokee wrote:
    A.P.A wrote:
    In transparent mode you need to have the VTP domain matching (VTP v1) if you want the switch to forward on VTP advertisements to other switches connected to it...... In VTPv2 I'm 99% certain the domain name can be different and it will still forward on the VTP advertisements......

    THe documentation is worded a little wierd on this one. It really works the same for both version 1 and 2. There is a little statement in the documentation that makes all the difference and it says something like "in version 2 the vtp domain name of all of the switches must match for it to be version 2". Youcan observe this by getting your VTP domain set up in version 1 then going to one of the servers and changing it to version 2. All of the server and client switches in the same VTP domain will also change their version.

    The short answer, for a VTP transparent switch to forward a VTP advertisement it's domain name must match what's in the VTP advertisement.

    Thanks for highlighting that dtlokee!!

    Yes I have noticed that once the Server changes to V2 all clients change to V2 in the same domain as well.......................in production and in my lab :D

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • Options
    ReardenRearden Member Posts: 222
    Thanks to both of you for clearing that up for me :)
    More systems have been wiped out by admins than any cracker could do in a lifetime.
Sign In or Register to comment.