Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ISL 1 on two interfaces servicing two separate VTP domains/IP networks

What I'll describe below has been setup since 2000 by someone I respect technically and is now employed by Cisco as a L3 tech in Cat6500 group. This setup has worked flawlessly since and has NEVER given an indication of failure. A different certified person believes the below is the reason one single switch (a VTP client) was rebooting with power messages. (I know, its odd, but I need to write up a report on the entire situation)

One 7507 router has three FEs. Two FEs are PortChanneled. PC1 connects to one switch, the single FE connects to another switch. Each switch is the server of their own unique VTP domain and they service other VTP member client switches. NEITHER VTP domain "touches" each other directly. They are also servicing completely unique IP networks. The VTP domains don't overlap, the IP networks don't over lap, there is no overlap.

This certified person said that because both routers interfaces (the single FE and the PC int) had and ISL encap # of 1, that it is very wrong. Now, bear in mind, these are going to two completely UNIQUE VTP domains and UNIQUE IP networks, they are not the same. Basically in this setup, we have one router, servicing two large remote user facilities.

I do not believe this current config is wrong, and that it will NEVER explain a switch rebooting for power failures. In addition, it have never at any point given any indication that there where operational failures due to this setup.

What is need is genuine Cisco documentation that says this is and incorrect setup or a valid setup.

Any help greatly appreciated.


  • Other Network Infrastructure Subjects
New Member

Re: ISL 1 on two interfaces servicing two separate VTP domains/I

Hi there

Cannot provide a genuine Cisco documentation on the matter but I can say to you that VTP information does NOT cross from one routed interface to another (unless there are some major OS bugs that leak out VLAN info). Because of this behaviour, I can have multiple VTP domains at different locations in my network (different geological location). I have never tried running multiple instances of VTP in a single office/location but can't see the reason why I can't do it or similarly, cannot understand how VTP can cause a switch to reboot for power failure.

New Member

Re: ISL 1 on two interfaces servicing two separate VTP domains/I

Thanks for the reply.

Well, that is the way it was setup in '99. It has been working flawlessly since. I don't know why the engineer that originated this design didn't put them all in the same VTP domain, but it ended up the other way. Consultants love to sell more hardware, and another VIP and PA-FE-TX is a nice income addition in lieu of utilizing an existing switch port for the link to the other building.....

I know that VTP isn't a routable protocol, but if there was a problem with the arrangement, my suspicions was that one router couldn't have the same ISL encap number servicing two unique sets of networks, VTP domains and buildings.

Anyone else have comments on the above paragraph's issue?

But, last week somebody latched onto that as the cause. Scary isn't it. The switch rebooting was resolved by addressing the power source which the switch relied upon.

New Member

Re: ISL 1 on two interfaces servicing two separate VTP domains/I

As an observation, the old addage, "what is good for the goose is good for the gander" seems to apply to your situation.

Has the certified Cisco person produced supporting documentation explaining why you should not configure the router that way. It may be a current recommendation based on current IOS code levels.

Additionally, the IOS version may play a role in how the equipment was configured. Often supporting features are added that were not applicable when the original equipment was installed.

Also, Cisco does change what they recommend over time, as software and hardware capabilities change. It may have been an acceptable practice when the configuration was setup.

Since the resolution was not associated with this configuration, it sounds more like a best practices recommendation rather than a cause and effect situation...


This widget could not be displayed.