From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Sun Jun 01 2008 - 08:39:37 ART
Hi Thor,
As far as I know the type used by VTP is not reserved solely for its
use. The protocol identifier field is actually five bytes long and
includes cisco's OUI as well as type 0x2003, and I believe that type
could in theory be used differently by other vendors. The destination
address used by VTP, which also includes the cisco OUI, acts as a
safeguard against matching any such traffic.
I haven't seen a reference to this information on the doc cd, but some
of the protocols use similar values so they are not actually that
difficult to remember. I do not think we would need to remember
anything like this for the lab though.
0x2000 CDP (dst 0100.0ccc.cccc)
0x2001 CGMP (dst 0100.0cdd.dddd)
0x2003 VTP (dst 0100.0ccc.cccc)
0x2004 DTP (dst 0100.0ccc.cccc)
Paul.
Thor Kopp wrote:
> Excellent thanks for the details Paul. It's something that i've always
> read and thought to be true but I've never actually tried it. Just
> tested and confirmed. Crazy.
>
> Do you know if there is somewhere on the Doc-CD where the ether-types
> are if you want to filter something that you don't know about if it's
> not listed as a keyword ie decnet, appletalk etc. I remember arp 0x806
> but that's about it. Also why did you use 0100.0ccc.cccc as the
> destination mac out of all of these?
>
> Rack1SW3#show mac-add st
> Mac Address Table
> -------------------------------------------
> Vlan Mac Address Type Ports
> ---- ----------- -------- -----
> All 0000.0000.0000 STATIC CPU
> All 000c.30ac.cc80 STATIC CPU
> All 000c.30ac.cc81 STATIC CPU
> All 000c.30ac.cc82 STATIC CPU
> All 000c.30ac.cc83 STATIC CPU
> All 000c.30ac.cc84 STATIC CPU
> All 000c.30ac.cc85 STATIC CPU
> All 000c.30ac.cc86 STATIC CPU
> All 000c.30ac.cc87 STATIC CPU
> All 000c.30ac.cc88 STATIC CPU
> All 000c.30ac.cc89 STATIC CPU
> All 000c.30ac.cc8a STATIC CPU
> All 000c.30ac.cc8b STATIC CPU
> All 000c.30ac.cc8c STATIC CPU
> All 000c.30ac.cc8d STATIC CPU
> All 000c.30ac.cc8e STATIC CPU
> All 000c.30ac.cc8f STATIC CPU
> All 000c.30ac.cc90 STATIC CPU
> All 000c.30ac.cc91 STATIC CPU
> All 000c.30ac.cc92 STATIC CPU
> All 000c.30ac.cc93 STATIC CPU
> All 000c.30ac.cc94 STATIC CPU
> All 000c.30ac.cc95 STATIC CPU
> All 000c.30ac.cc96 STATIC CPU
> All 000c.30ac.cc97 STATIC CPU
> All 000c.30ac.cc98 STATIC CPU
> All 000c.30ac.cc99 STATIC CPU
> All 000c.30ac.cc9a STATIC CPU
> All 0100.0c00.0000 STATIC CPU
> All 0100.0ccc.cccc STATIC CPU
> All 0100.0ccc.cccd STATIC CPU
> All 0100.0ccd.cdce STATIC CPU
> All 0180.c200.0000 STATIC CPU
> All 0180.c200.0001 STATIC CPU
> All 0180.c200.0002 STATIC CPU
> All 0180.c200.0003 STATIC CPU
> All 0180.c200.0004 STATIC CPU
> All 0180.c200.0005 STATIC CPU
> All 0180.c200.0006 STATIC CPU
> All 0180.c200.0007 STATIC CPU
> All 0180.c200.0008 STATIC CPU
> All 0180.c200.0009 STATIC CPU
> All 0180.c200.000a STATIC CPU
> All 0180.c200.000b STATIC CPU
> All 0180.c200.000c STATIC CPU
> All 0180.c200.000d STATIC CPU
> All 0180.c200.000e STATIC CPU
> All 0180.c200.000f STATIC CPU
> All 0180.c200.0010 STATIC CPU
> Total Mac Addresses for this criterion: 49
>
> - Thor
> On Sat, May 31, 2008 at 5:12 PM, Paul Cosgrove
> <paul.cosgrove@heanet.ie <mailto:paul.cosgrove@heanet.ie>> wrote:
>
>
> The forwarding behaviour in VTP v1 & v2 has been discussed a few
> times here. Apparently the behaviour changed at some point in the
> dim and distant past, but the doc cd was not updated to reflect that.
>
> Have a look at following post which includes a response from cisco
> on the matter:-
> http://www.groupstudy.com/archives/ccielab/200704/msg01533.html
>
> It seems there is no difference in the forwarding behaviour
> between v1 and v2. If you define a VTP domain name on a switch
> set in transparent mode, it will only forward VTP messages
> containing that domain name. So having a different domain name on
> the transparent mode switch should be enough.
>
> If we were asked to block all VTP, regardless of domain name, we
> could use transparent mode with an inbound mac acl matching type
> 0x2003.
>
> mac access-list extended DENY-VTP
> deny any host 0100.0ccc.cccc 0x2003 0x0
> permit any any
>
> interface FastEthernet0/13
> mac access-group DENY-VTP in
>
> Paul.
>
>
> Thor Kopp wrote:
>
> With VTP V1 (the default) a switch in transparent mode will
> only forward vtp
> advertisments if the domain & version number match so if you
> use a random
> VTP domain for example you won't forward VTP messages learnt
> on trunk ports
> (because it's unlikely that the VTP domain will match).
>
> VTP V2 will forward VTP messages regardless of the VTP domain
> that is in the
> VTP message that it receives.
>
> - Thor
> On Sat, May 31, 2008 at 9:33 AM, Sadiq Yakasai
> <sadiqtanko@gmail.com <mailto:sadiqtanko@gmail.com>> wrote:
>
>
>
> Hmmm,
>
> I dont think setting the VTP mode to transparent will make
> the switch block
> all VTP advertisements. The switches will only not
> originate VTP but will
> still relay them from other switches.
>
> I agree with Paul, setting the switchport modes to access
> will do the
> trick,
> but not including the trunks that you have already set
> anyway, as doing so
> will revert them back to access switchports and not
> satisfy the previous
> ISL
> encap requirement.
>
> HTH
> Sadiq
>
>
> _______________________________________________________________________
> 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
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:20 ART