Hi - I'm not sure if my understanding of VLANS is correct. Let's say I am running a single VLAN on a 24 port switch at 75% capacity. Rather congested. If I identify those "heavy traffic ports" and configure them into seperate VLANS, I thereby reduce congestion and increase troughput? Is this a basic understanding?
This one's easier. To allow DHCP through my router, I simply configure the interface separating my 2 segments to point to the IP of the DHCP server?
Vlans limit broadcast domains. So if you create multiple vlans, broadcasts in one vlan doesnt see broadcasts in another. So configuring multiple vlans will give you some improvement in performance, but not always. Think of the heavy traffic ports, sending megs or gigs of data, nad your switch doesnt have enough backplane bandwidth to support that kind of data. So its probably better off to move those off to a separate switch/vlan. Give them gigabit ports if needed. (switch and nic).
When you multiple vlans, and an external router is routing between the two vlans, yes, you can configure a ip helper-address and specify the ip address of DHCP server.
Thanks - I understand vlans limiting broadcasts but I guess this is what I am struggling with. Unlike a hub, each port in the switch is capable of lets say 100mb throughput. Doest that mean the "backplane bandwidth" capability of the switch is 100 x number or ports?
Consquently, is the % utilization of a particular VLAN equal that of the the single highest port usage of that VLAN and or an aggregate of all ports in that VLAN.
Thanks...don;t know why I'm struggling with this.
Also, have enabled IP helper-address 10.0.1.7 on the interface closest to the client needing access to the DHCP server on the other segment and still no good. Anything else that I am missing. Have port forwarding enabled etc....seemingly everything in the cisco docs about this.
As you've presented it, no, VLANs are not going to help you much.
What it will help you with is not propagating broadcasts and multicasts to every host on the (non-VLAN'd) network.
When a host receives a broadcast, it *must* look at it, if the broadcast is not pertinent to that machine, you've wasted processing cycles, and (at the least) somewhat congested the incoming stack for that device.
For as much as I hate to use it, the water & pipe analogy still probably works the best:
If you have one hose (the path from one device to another through the network), and you have a valve that can feed four different colors of water into the hose (either direction ... the colors equate to VLAN traffic), and one source is feeding purple water through the hose at the hose's capacity ... then there is no room for the other colors of water to pass ... .in fact, the addition of the colors (VLAN tags in a trunk) REDUCE (a little) the amount of purple water that can pass, and reduce (a little) the overall capacity (regardless of the color).
Network management goes beyond the infrastructure. You can create VLAN segments on a switch ... that will keep the heavy traffic isolated to a portion of the switch (inside the switch, assuming a non-blocking fabric).
At some point, you'll need to aggregate the traffic and move it to some other portion of the network. At that point, you must decide to either limit the traffic somehow, or present a path that is equal to, or greater than, the amount of traffic that must use that path.
Other design issues, like many-to-one scenarios, require you to pay attention to where the traffic comes from (and in what volumes), and where the traffic is going (and in what volumes).
In some cases, you may decide to feed the users at ten megabit, and trunk to the core at 100 (or 100 & 1000 ... whatever the scale).
In a many-to-one scenario, about the worst thing you can do is have 23 ports @ 100Mb feeding the only egress port which is also running at 100Mbit (a 23:1 oversubscription). With any normal traffic flows, this switch is going to start buffering ... extra latency, occasionally-to-frequently causing frame / packet drop from excessive delay (and / or messing up your VoIP, Video, database apps .....).
For the scenario you've presented, you might want to look at partitioning the broadcast domain with VLANs, but use multiple trunks / paths to divide the VLAN's traffic (i.e., VLAN 100 goes on the trunk at fa0/1, VLAN 200 goes out on the trunk on fa0/2...) to different distribution / core switches. Send the high-traffic out on a trunk with another lower traffic VLAN, and pass several ~medium-level flows out another trunk.
Monitor and measure the flows (baseline!), develop a plan, implement the plan, monitor & measure, adjust .... then repeat.
Blind implementation is a bad thing; don't always assume that whatever action you've taken is automatically going to improve the system. Measure before, plan, implement, measure again after under similar circumstances, then compare & tweak as necessary.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...