From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Mon Jul 14 2008 - 07:10:43 ART
Hi Michael,
Do you know what version of software you were testing with?
When I tied it myself a while ago with a couple of switches, and didn't
even see vtp debug output on a transparent mode switch if the domain
name of the incoming vtp packets did not match its own. Would have been
using 12.2(44)SE1 myself.
Will try to scavenge another switch and check it out tonight.
Paul.
Michel Grossenbacher wrote:
> I did some VTP tests a few days ago while the transparent switch without a
> domain was a part of one of the tests, even though I did not test the
> behavior itself. But via the *debug sw-vlan vtp* *events *command I got the
> following output on the transparent switch, after he was integrated into a
> VTP Domain with a domain name set:
>
> 4w1d: VTP LOG RUNTIME: *Relaying* packet received on trunk Fa0/13 - in
> TRANSPARENT MODE (nc = false)
>
> I interpret the output that it is relaying the packet it received on fa0/13.
> But as I said I did not test that behavior by itself.
>
> best regards
>
> Michel
>
>
> 2008/7/14 paul cosgrove <paul.cosgrove@gmail.com>:
>
>> Depends what you want to achieve. A transparent mode switch will pass on
>> VTP advertisements it receives if the domain name contained within them
>> matches its own.
>>
>> A (made up) practical scenario might be that you have a switch at a
>> boundary
>> between your trusted network and someone elses, their network being
>> untrusted. Your aim may be to prevent deliberate attacks on your vtp domain
>> by injecting vtp messages which spoof your domain name. If policy means
>> that you must use VTP elsewhere within your own infrastructure you could
>> set
>> a different vtp domain (e.g. "edge") on your transparent mode edge switches
>> to prevent this. Even if someone spoofed the egde domain name they could
>> not affect your other switches which use different domain names (e.g.
>> "internal") as well as vtp modes. If they sent vtp advertisements
>> spoofing
>> your internal vtp domain name the edge switches would not forward them.
>>
>> Alternatively you could use the same domain name everywhere and filter
>> incoming vtp with a mac acl. Using this approach means that you could, if
>> you wanted to, use vtp client mode on your edge switches - if you don't
>> mind
>> vtp advertisements leaking out. Often people just use vtp transparent mode
>> everywhere.
>>
>> Haven't tested transparent mode with an undefined vtp domain name (and will
>> try to get a few switches to do so later unless someone else does) but
>> switches in other modes with an undefined vtp domain will accept and
>> forward
>> vtp advertisements which have a vtp domain set.
>>
>> Paul.
>>
>> On Mon, Jul 14, 2008 at 5:28 AM, Hong Chan <howard.chan34@gmail.com>
>> wrote:
>>
>>> I think using the transparent mode is engough. Do we really need to
>> change
>>> the domain name to be the different one?
>>>
>>>
>>>
>>> 2008/7/13 akyccie <akyccie@gmail.com>:
>>>
>>> This is what is mentioned in the DOC CD. So VTP trnasport mode and
>>>> configure
>>>> the different domain is the ans to this.
>>>>
>>>> VTP Transport mode
>>>> transparent Place the switch in VTP transparent mode. A switch in VTP
>>>> transparent
>>>> mode is disabled for VTP, does not send advertisements or learn from
>>>> advertisements sent by other devices, and cannot affect VLAN
>>>> configurations on other devices in the network. The switch receives VTP
>>>> advertisements and forwards them on all trunk ports except the one on
>>>> which
>>>> the advertisement was received.
>>>> When VTP mode is transparent, the mode and domain name are saved in the
>>>> switch running configuration file, and you can save them in the switch
>>>> startup configuration file by entering the copy running-config startup
>>>> config privileged EXEC command.
>>>>
>>>> ----- Original Message -----
>>>> From: Jason Madsen
>>>> To: paul cosgrove
>>>> Cc: ccielab@groupstudy.com ; akyccie@gmail.com
>>>> Sent: Sunday, July 13, 2008 5:36 AM
>>>> Subject: Re: VTP
>>>>
>>>>
>>>> sounds good to me.
>>>>
>>>>
>>>> On Sat, Jul 12, 2008 at 6:03 PM, paul cosgrove <
>> paul.cosgrove@gmail.com>
>>>> wrote:
>>>>
>>>> Hi Jason,
>>>>
>>>> A five octet PID may be equivalent to a 2 octet Ethertype when
>>>> OUI=00:00:00, but they are not the same for VTP, CDP etc, since their
>> OUI
>>>> is
>>>> set to the Cisco OUI and so all five octets of the PID are used. The
>>>> values
>>>> you have listed are not the full PID values.
>>>>
>>>> There clearly is confusion about this, and I know that some sniffer
>>>> programs list the PID as being just the last two octets, but I do not
>> see
>>>> an
>>>> explanation for such a useage in IEEE 802-1990:-
>>>>
>>>> "5.3 Protocol Identifier
>>>> 5.3.1 Concept
>>>> ...
>>>> All SNAP PDUs contain a Protocol Identification Field. An
>> organization
>>>> uses its OUI to identify, using a universal unique value, its own
>>>> protocols.
>>>> The protocol identifier is 40 bits in length....The first 24 bits of
>>>> the
>>>> protocol identifier correspond to the OUI in exactly the same fashion as
>>>> in
>>>> 48-bit LAN MAC addresses. The remaining 16 bits are locally
>> administered
>>>> by
>>>> the assignee."
>>>>
>>>> "5.3.2 Represention of a Protocol Identifier.
>>>> The protocol identifier is represented as a string of five octets
>>>> separated by hyphens. The octets are displayed left to right in the
>> order
>>>> they are transmitted on the LAN medium. Each octet is displayed as two
>>>> hexadecimal digits. The M bit of the first octet is the first bit of
>> the
>>>> Organizationally Unique Identifier and is the least significant."
>>>>
>>>> Paul.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jul 12, 2008 at 10:51 PM, Jason Madsen <
>> madsen.jason@gmail.com
>>>> wrote:
>>>>
>>>> I think ethertype and PID are essentially one in the same. It just
>>>> depends on which source you reference. In MACLs they use the term
>>>> ethertype,
>>>> but in packet captures the actual value is the PID (protocol ID). At
>>>> least
>>>> they seem to directly coincide:
>>>>
>>>> VTP 0x2003
>>>> CDP 0x2000
>>>> DTP 0x2004
>>>> UDLD 0x0111
>>>>
>>>> ...but great write ups you provided. i think aky is about a
>>>> blocking
>>>> VTP kind of person as any now:-)
>>>>
>>>> Jason
>>>>
>>>>
>>>> On Sat, Jul 12, 2008 at 2:05 PM, paul cosgrove <
>>>> paul.cosgrove@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> MAC acls can be used to stop VTP being received, they cannot be
>>>> used
>>>> to
>>>> stop advertisements being sent; vtp transparent mode will do
>> that
>>>> for
>>>> you. In later versions of IOS there is also a "vtp mode off" command.
>>>>
>>>> The (ether)type values can be used to differentiate the
>> protocols.
>>>> You
>>>> cannot match the PID, only the (ether) type part of it.
>>>>
>>>> You can find a discussion about this including examples of MAC
>> ACLs
>>>> here:-
>>>>
>> http://puck.nether.net/pipermail/cisco-nsp/2008-April/050185.html
>>>> Paul.
>>>>
>>>>
>>>> Jason Madsen wrote:
>>>> > to be further specific you could block it by it's PID, which is
>>>> 0x2003,
>>>> > along with 01:00:0C:CC:CC:CC. CDP's is 0x2000 etc.
>>>> >
>>>> > Jason
>>>> >
>>>> > On Sat, Jul 12, 2008 at 12:32 PM, Jason Madsen
>>>> <madsen.jason@gmail.com>
>>>> > wrote:
>>>> >
>>>> >
>>>> >> hmmmm, that's a good one. of course vtp mode transparent may
>>>> prevent the
>>>> >> device from participating in vtp (especially VTP v1), but to
>>>> actually block
>>>> >> it is another thing. i believe you could use a MACL and block
>>>> 01:00:0C:CC:CC:CC,
>>>> >> but i also believe that CDP, UDLD, DTP, and PAGP also use this
>>>> address so
>>>> >> you might have to look at the implications of doing such a
>>>> thing.
>>>> you might
>>>> >> want to use different VTP domain names to further prevent
>>>> compatibility
>>>> >> between the systems, although that could be considered
>> overkill.
>>>> >>
>>>> >> just some thoughts,
>>>> >> Jason
>>>> >>
>>>> >> On Sat, Jul 12, 2008 at 12:12 PM, akyccie <akyccie@gmail.com>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>> How to block VTP advertisement ???
>>>> >>>
>>>> >>>
>>>> >>>
>>>> _______________________________________________________________________
>>>> >>> Subscription information may be found at:
>>>> >>> http://www.groupstudy.com/list/CCIELab.html
>>>> >>>
>>>> >
>>>> >
>>>> >
>>>> _______________________________________________________________________
>>>> > Subscription information may be found at:
>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
-- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301Please consider the environment before printing this e-mail.
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART