Vlan questions? 1

[drewdown]

Currently have an office with 2 floors and 1 router (layer 3 stacked 3750's) handling all the traffic for the building, vlans exist on all switches, although not every vlan. Roughly 10 vlans total. Trunks running between all switches. Multiple vlans span both floors.

Current things I would like to change:
1) VOIP/DATA on same vlan across both floors
2) Switches daisy chained off layer 2 switch on second floor (not enough runs/patches to connect all 2nd floor switches to core switch)
3) VLANs across both floors (user, wirelss, UPS, etc..)

Solutions? Enable routing on 2nd floor 3750 stack? Separate all VOIP/DATA on both floors? etc...

Any input would be greatly appreciated.

 

[VinceWhirlwind]

1) You mean 1 DATA VLAN & 1 VOICE VLAN for the entire office? Sounds perfectly sensible to me if you only have a hundred or so users, otherwise 1 DATA VLAN & 1 VOICE VLAN per floor would be good.

2) If that's the only way to do it, then that's fine - just make sure you have Gb links between the switches and configure all trunks between switches as .1q trunks. Use etherchannel if you possibly can to improve resilience and bandwidth.

3) Just add the VLANs to the trunks where they are needed. Don't forget to add them to both interfaces on either side of each trunk.

Enable routing on switches? No. You need one Layer-3 device to route between VLANs. Minimum Layer-3 devices for maximum efficiency.

 

[drewdown]

1) Less than a 100 users, so I could get away with 1 DATA and 1 VOICE VLAN
2) Currently that is the only way to do it, have GB links between them all at this point
3)10-4

Enable routing on switches? No. You need one Layer-3 device to route between VLANs. Minimum Layer-3 devices for maximum efficiency.

I was referring to enabling routing on a 3750, which is what we have now as our layer-3 device.

Thanks Vince.

 

[VinceWhirlwind]

Yes, if your layer-3 device is going to be one of your switches, call it your "Core Switch" and do "ip routing" on it.
Create a VLAN interface for each VLAN, and give each interface that VLAN's subnet's default GW address.

Don't do "ip routing" on your other switches.

 

[drewdown]

I got all that.

Thanks man.

 

[drewdown]

Update to this. More concept questions.

In this scenario I have a stacked 3750 doing the core routing for the building. Less than a 50 users, 6 racks of equipment on the 2nd floor and the core switch-router on the 3rd floor. Certain vlans span the 2nd and 3rd floor. The question has been raised as to whether or not having traffic from the 2nd floor come up the 3rd floor and back to the 2nd floor can become an issue.

Currently there is a 2 port gig etherchannel (can add 1 more port) between the core switch-router and the core 2nd floor switch. All switches in the racks (on 2nd floor) are connected to the core 2nd floor switch. Therefore, if data from a user computer on the 2nd floor wants to reach a computer on the test vlan on the 2nd floor it needs to go up/down the pipe to get there.

Is that necessarily bad or considered poor configuration?

 

[VinceWhirlwind]

That's normal - you have a star-shaped network and traffic from 1 VLAN has to go to the core in order to get to a second VLAN.
This is one reason why we avoid spanning the same VLAN around multiple switches, or multiple VLANs on one switch.

Some traffic stats off the relevant switch uplink interfaces should demonstrate whether you have an issue or not.

 

[drewdown]

Thanks Vince.

What kind of stats can I look at?

 

[burtsbees]

sh interface, sh port (CatOS)

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[drewdown]

I know that much, but not sure how to test for bandwidth problems.

ET-ANN-SW-CORE#show interfaces port-channel 1
Port-channel1 is up, line protocol is up (connected) 
  Hardware is EtherChannel, address is 0014.694f.e681 (bia 0014.694f.e681)
  MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is unknown
  input flow-control is off, output flow-control is unsupported 
  Members in this channel: Gi1/0/1 Gi2/0/1 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:02:33, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 2250000 bits/sec, 622 packets/sec
  5 minute output rate 2647000 bits/sec, 701 packets/sec
     8548374324 packets input, 6164964448085 bytes, 0 no buffer
     Received 90036632 broadcasts (7010546 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 7010546 multicast, 0 pause input
     0 input packets with dribble condition detected
     8145655802 packets output, 5388101495126 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

Whats the best way to test bandwidth problems on that port-channel? Move a large file, wait 3 or 4 minutes and then check the stats?

 

[VinceWhirlwind]

Personally, I would get my favourite SNMP tool (eg Solarwinds) and monitor that switch non-stop for an entire day, or an entire week. Set the SNMP queries for very short intervals.

At the end of that time, generate graphs showing the interface utilisation RX/TX with high granularity.

If any of your graph peaks have flat tops, you have an issue. The longer the flat top the worse the issue.

The same tool will show you where the traffic is coming from - identify any interfaces which are producing a lot of network traffic and redesign your network to take them into account - move the hosts on those interfaces so they are closer to whatever they are trying to communicate with.

 

[burtsbees]

5 minute input rate 2250000 bits/sec, 622 packets/sec
5 minute output rate 2647000 bits/sec, 701 packets/sec

Another clue may be in sh proc cpu, and look at ip traffic % as well as interrupts. That would only be in the case of high spikes or high % across a time period.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!