Re: VTP

From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Mon Jul 14 2008 - 07:16:58 ART

Sorry Michael, think I misunderstood your point there.

So you tested without a domain set on the transparent mode switch and it
continued to relay VTP packets it received?

Paul.

Paul Cosgrove wrote:
> 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: 275301

Please 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