Cisco – Are VLANs necessary for the environment

It sounds like somebody in your organization wants to create VLANs w/o understanding the reasons why you'd do it and the pros/cons associated therewith. It sounds like you need to do some measurement and come up with some real reasons for doing this before moving forward, at least with the insane "VLAN for a room" silliness.

You shouldn't start breaking an Ethernet LAN into VLANs unless you have good reasons to do it. The best two reasons are:

• Mitigating performance problems. Ethernet LANs can't scale indefinitely. Excessive broadcasts or flooding of frames to unknown destinations will limit their scale. Either of these conditions can be caused by making a single broadcast domain in an Ethernet LAN too big. Broadcast traffic is easy to understand, but flooding of frames to unknown destinations is a bit more obscure (so much so that none of the other posters here even mention it!). If you get so many devices that your switch MAC tables are overflowing switches will be forced to flood non-broadcast frames out all ports if the destination of the frame doesn't match any entries in the MAC table. If you have a large enough single broadcast domain in an Ethernet LAN with a traffic profile that hosts talk infrequently (that is, infrequently enough that their entries have aged out of the MAC tables on your switches) then you can also get excessive flooding of frames.

• A desire to limit / control traffic moving between hosts at layer 3 or above. You can do some hackery examining traffic at layer 2 (ala Linux ebtables) but this is difficult to manage (because rules are tied to MAC addresses and changing out NICs necessitates rule changes) can cause what appear to be really, really strange behaviors (doing transparent proxying of HTTP at layer 2, for example, is freaky and fun, but is utterly un-natural and can be very non-intuitive to troubleshoot), and is generally difficult to do at lower layers (because layer 2 tools are like sticks and rocks at dealing with layer 3+ concerns). If you want to control IP (or TCP, or UDP, etc) traffic between hosts, rather than attacking the problem at layer 2, you should subnet and stick firewalls / routers with ACLs between the subnets.

Bandwidth exhaustion problems (unless they're being caused by broadcast packets or flooding of frames) are not solved with VLANs typically. They happen because of a lack of physical connectivity (too few NICs on a server, too few ports in an aggregation group, the need to move up to a faster port speed) and can't be solved by subnetting or deploying VLANs since that won't increase the amount of bandwidth available.

If you don't have even something simple like MRTG running graphing per-port traffic statistics on your switches that's really your first order of business before you start potentially introducing bottlenecks with well-intentioned but uninformed VLAN segmentation. Raw byte counts are a good start, but you should follow it up with targeted sniffing to get more details about the traffic profiles.

Once you know how traffic moves around on your LAN you can begin to think about segmenting the LAN for performance reasons.

If you're really going to try and button down packet and stream-level access between VLANs be prepared to do a lot of legwork with application software and learning / reverse-engineering how it talks over the wire. Limiting access by hosts to servers can often be accomplished with filtering functionality on the servers. Limiting access on the wire can provide a false sense of security and lull administrators into a complacency where they think "Well, I don't need to configure the app. securely because the hosts that can talk to the app. are limited by 'the network'." I'd encourage you to audit the security of your server configuration before I'd start limiting host-to-host communication on the wire.

Typically you create VLANs in Ethernet and map IP subnets 1-to-1 onto them. You're going to need a LOT of IP subnets for what you're describing, and potentially a lot of routing table entries. Better plan those subnets with VLSM to summarize your routing table entries, eh?

(Yes, yes-- there are ways not to use a separate subnet for every VLAN, but sticking in a strictly "plain vanilla" world you'd create a VLAN, think up an IP subnet to use in the VLAN, assign some router an IP address in that VLAN, attach that router to the VLAN, either with a physical interface or a virtual subinterface on the router, connect some hosts to the VLAN and assign them IP addresses in the subnet you defined, and route their traffic in and out of the VLAN.)

Pardon, in your cut and pasted configs, you appear to be describing Gi0/48 - your uplink to your router, but in your question refer specifically to hosts connected to Gi0/18. I'm going to assume you're describing two different ports here. Further, I'm assuming from details in your config statements and question, that vlan 3 is being used for the 192.168.0.80/28 traffic. I'm going to assume that the vlan has already been declared on your 3560. (Check sh vlan)

First of all, your port Gi0/18 should be configured for access mode on vlan 3. Likely, something like this:

interface GigabitEthernet 0/18
switchport access vlan 3
switchport mode access

As far as for other recommendations. Will all/most of your traffic from your IP subnets be to and from the internet. Basically, If you have enough traffic between subnets, it may suit you to have the 3560 act as your internal router and then dedicate your 3825 to be your border router. The problem is that if your router is baring the entire load for all routing, then a packet from one subnet will arrive at your switch, then be forwarded via the dot1q to your trunk on some vlan X, the router then makes a routing decision and sends the same packet back along the dot1q trunk on some new vlan Y now destined for the destination machine. Btw, I'm simply describing the situation of internal traffic to your customers/organization that crosses your different subnets.

Instead, you can configure the 3560 at the, assuming normal conventions, first address of each vlan/subnet. E.g. 192.168.0.81 and enable ip routing. The next step is you create a new subnet specifically for between the router and switch. For convenience, i'd use something completely different, for example, 192.0.2.0/24 is reserved for documentation examples. Configure the router at 192.0.2.1 and the switch at 192.0.2.2. Have the switch use 192.0.2.1 as the default route. Configure the router to reach 192.168.0.0/16 via the switch at 192.0.2.2. If your network is small enough, static routes should be sufficient. No need for OSPF or anything.

Of course, this would be a rather dramatic change; but it has potential for being a large improvement. It all depends on the nature of your traffic.

For reference, cisco lists the Cisco Catalyst 3560G-48TS and Catalyst 3560G-48PS having a 38.7 Mpps forwarding rate and the Cisco 3825 as having 0.35Mpps forwarding rate. Mpps, just in case you don't know, is millions of packets per second.

It's not bandwidth, but it's how many 64 byte packet routing decisions the device can make a second. The length of the packet doesn't affect how long it takes to making a routing decision. So the peak performance in bits/bytes will be somewhere in a range. In terms of bandwidth, it means that 350kpps is 180Mbps w/ 64byte packets and 4.2Gbps w/ 1500 byte packets. Mind you, that's in bits per second, so think of it as 18 Megabytes or 420 Megabytes per second in regular file-size terms.

In theory, this means that your 3560G can route somewhere between 19.8Gbps and 464Gbps or rougly 2GBps and 45GBps.

Actually, looking at those numbers, you most definitely should consider the plan I described above. Dedicate your 3825 to handling, presumably, NAT'd external traffic and let your 3560 handle the rest.

I'm sorry this is so long; I'm bored at work waiting for tapes to finish. Cheers.