Comments within and below.
---- On Sat, 14 Jul 2001, Priscilla Oppenheimer
([EMAIL PROTECTED]) wrote:
> Thanks, Paul!
You're welcome :-)
> OK, I don't really think VTP is evil. I can definitely
understand the
> problem that it solves.
It's just like any other protocol. It can do both good and
evil. It will tend to do more good as you know its
capabilities and limitations. It does have the ability to
scale to very large networks and greatly simplify the task of
managing VLANs. It can also bring your network down in an
heartbeat.
> I have it working now. I have one switch set to client and
one set to
> server, which works fine. I didn't think I could use client
on a Cat
> 1900
> because the documentation says you can't configure client.
Unless something dramatic changed, the switch will support all
three modes. The first reference to it in the command line
based version is here(watch wrap):
http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/192
8v67x/eescg67x/02vlans.htm#31633
>From the most current (9.x) version of the IOS you have:
http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/192
8v9x/cli/part2.htm#xtocid1826474
If you are referencing the ICND notes, you are correct, they
are wrong. They may have been fixed in a lter revision to the
course materials.
http://www.cisco.com/univercd/cc/td/doc/product/lan/28201900/192
8v9x/ee_scg/1vlans.htm#xtocid288056
I believe this reference is dated. What version of 1900 IOS
are you using? Go to global config mode and do a VTP ? and see
what the choices are. The docs don't always tell the truth,
and sometimes the truth changes.
> > > vtp trunk pruning-disable 10 50
> >
> >I think the effect of this was to have only VLAN1 span both
> >switches.
>
> The effect is that Pruning of 10 and 50 are Disabled so that
they DO
> span
> the trunk. They should have been spanning it anyway, though.
>
> > Somehow, I am still wondering if you got a trunk
> >established.
>
> Yes I had a trunk. "Show trunk a" said it was on and using
ISL.
>
> Once the network was stable I was able to remove the command
and all is
> working, so now so I'm not sure it really was the problem.
It's hard to say unless you did a very thorough job of
documenting every step that you took. It may have been some
anomaly that cannot be reproduced. It's happened to me before.
But, there
> was
> something funny going on, that's for sure. I couldn't see
multicasts
> with
> my Sniffer on the monitor port either and now I can.
>
> Regarding VLAN 1, I have one more question. If you give a
switch an IP
> address, that address is part of VLAN 1, right?
Well, generally yes. That assumes that you did not change the
management VLAN from VLAN 1 to something else. The command to
change this is:
switchA(config)#ip mgmt-vlan [vlan-number]
The problem with that is
>
> that you may not have any other ports that are part of VLAN
1, since
> VLAN 1
> is the management VLAN generally. So how do you ping or SNMP
the switch
> then? What is considered "best practice" for this?
Well, consider this possibility. First, let's assume that all
ports on a switch will be assigned to VLAN 1 unless told
otherwise. If you decide to change the management VLAN to VLAN
100, then in order for SNMP, telnet, and other types of
management traffic to work, you would only need to ensure that
you have your switches connected with trunks. As long as each
trunk passes VLAN 100, you will be able to communicate to all
managed devices (switches, managed hubs, routers, etc).
Another benefit is that user traffic will not pass on and
compete for bandwidth on the management VLAN 100. The only
traffic that should be on VLAN 100 is management traffic. User
traffic can flow on VLANs 10,20,30, and 40 for instance. They
might even correspond to the 1st floor, 2nd floor, 3rd floor,
and 4th floor of your building.
So what about VLAN 1 and all those ports that are assigned to
it by default? Technically, you have no user traffic there.
You have no management traffic there. What kind of traffic
could you have? My guess would be hackers who are trying to
access your network at layer 2. All you need is an Ethernet
jack to get it going. So, what do you do with those ports?
My bet would be to place them in a VMPS configuration and set
the port for ignore mode and turn the SNMP traps on. This is
equivalent to a silent alarm.
>
> Thanks again. I walked into this thinking, "what could be so
hard about
> configuring data-link-layer devices?" Hah!
Indeed. The deception is that people think that LAN switches
are just a souped of version of a hub with a few extra bennies
thrown in. The reality is far from that truth. Our discussion
of VTP only scratches the surface of the complexity of LAN
switches 8-)
Clark and Hamilton devote 900
>
> pages to it! ;-)
And they both did an excellent job explaining it all. Anybody
who is planning on taking the CCIE lab and has not read that
book is starting off at a major disadvantage.
It took me a whole day to get two switches, VLANs,
> DISL,
> VTP, trunking, STP, and load sharing working correctly. Give
me a router
>
> any day! ;-)
Admittedly, my penchant is for routers, but I developed a
liking for LAN switches, particularly when I saw the power of
multicasting.
Seriously, I think my problems all started with not using
> VTP
> correctly from the start. Thanks for all the advice on it.
Any time.
v/r,
Paul Werner
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=12449&t=11687
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
