We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Network VLAN Routing Conundrum - I have pictures.

Medium Priority
Last Modified: 2012-05-07
I am replacing some old network architecture (3com stuff) and the current architecture may not work with what I have to replace it.  I am replacing a 3 com router that can handle up to 100 vlans and 2 stacked 48-port 3com switches with a Cisco 871 Router and 5 HP Procurve switches, one of which is a L3 switch (2610) and the other 4 are 1700's.

I am sending attachments.  The first is the current setup.  It is fairly straight-forward.  The connection comes in frm outside via 2 T1 lines, goes into the DSU/CSU, connects to the switch in VLAN 2 (a "DMZ" VLAN), creating a public IP address pool (we have a pool of 62 addresses).  The 3com router connects to VLAN 2, with a public ip address assigned, and it routes all traffic to the various virtual interfaces, via the 2 stacked switches.

The second attachment (LOBC Procurve) is the original design for replacement.  A peer of mine tried to use the equipment at hand to duplicate what was already there.  Unfortunately, because the switches are not stackable, and the router cannot handle 35-40 VLANs, we had to go out and add a L3 switch to the mix to do our VLAN routing.  In this design, the DSU/CSU passes its signal to the Cisco 871, routes across to an internal VLAN 1 (172.16/0/1/24), created on the router, which plugs into VLAN 1 on the L3 switch in port 26 (which is shared out among all VLANS).  The switch, then, is doing all the routing, including routing addresses from the public IP "DMZ" VLAN (2) to the the private IP VLAN 1, through the router, which routes it back to a public IP network.  This seems like a lot of routing overhead.  

The third attachment is another setup entirely.  Given the equipment at hand (and yes, I know it is not the right equipment, but it is what the boss purchased.)  The DSU/CSU passes the incoming Public IP network off to the Cisco 871, plugged into one of the switch ports on the back of the router...  not the WAN port.  Another switch port on the back of the router (no VLANS established on the router in this scenario) passes the public IP network to VLAN 2 on the L3 switch, the "DMZ" at port 26, which is NOT shared by all other VLANS.  At this point, internal routing tables in the switch route all VLAN traffic between the VLANS, which are all tagged packets, and VLAN 2 which remains untagged.  VLAN 2 passes the traffic out tot he real world via the Cisco 871.  My problem with this one is this...  If the incoming cable is plugged into a LAN port on the Cisco 871, instead of the WAN port, does it do any stateful packet inspection?  Is the Firewall feature of the Cisco being used at all?

Thanks for the second pair of eyes.  I appreciate it.
Watch Question

Based on what is described, it doesn't appear to me that the router is doing anything at all.  Can you please post the config on the Cisco router?  I'll have a better understanding on what the router is doing and can give you some ideas here.
Also, on another note, you should consider adding a redundant path (L2) back to the L3 switch.


Sure.  I will post the router config file.  My general concern is more broad, though.  I can make the router config specific to whatever architecture is most promising.  It is currently on partially configured as I have not decided on a course of action relating to this broader design question.  

The comment about the router not doing anything at all, though.  Is that comment based on the new procurve design where the router only has LAN interfaces involved?  If so, that was my concern.  If the packets aren't being examined because they aren't being routed, then you are right... The Cisco 871 is not doing anything.  And it NEEDS to be doing its job.

Here is the config file.
Yes, that comment is about the new procurve design.


I have a new idea.  I think this will work better for my purposes.  It does not address the redundancy issue you brought up, but could you take a look at it and tell me what you think?  

In this one, I have added a switch to separate the DMZ from the internal VLAN array.  That way, all DMZ traffic (the public IP block) goes straight out to the DSU CSU without being tagged with VLAN packets, or routed or anything.

As for the VLAN traffic, all the routing occurs on the switch across its VLAN interfaces and that traffic is sent to the Cisco 871 for firewall inspection.  

Does this make more sense?
That makes more sense;
but couple questions, then I"ll send you a logical diagram for this:
1. Do you have a need for an actual DMZ (A segment, that's not inside,nor outside of your network either)
2. Do you plan on configuring any other hosts on the network directly?

What I am driving to here is that, if you answer "Yes" to question 1 and "No" to question 2, then you should perhaps do this:
CSU/DSU hand-off --> WAN PORT of Router --> ANY Lan Port of Router into --> L3 Switch.  I will also further recommend keeping that transit subnet ( even) between Router and L3 Switch.

so logically, internal routing is all done on L3 switch, outbound done through Router.
You can further experiment with assigning a different vlan on one of the router's interfaces (ie. VLAN50) and assign ip (ie. 192.168.X.X/X) to be used as a "DMZ" for hosts, that you want to expose to the outside.  You can expose them on the router via static NATs + ACLs, and you can even also apply some ACLs on the router to restrict what these hosts can or can not have access to on your internal network.

does that make sense?
if not, let me know i'll put together a quick Visio diag.


Keep in mind that we are replacing equipment that is already in place.  The problem is that the new configuration cannot be made to look like the old configuration because the hardware we purchased does not do the same thing in the same way as the old stuff.  Having said that...

It might help to know a little about the jobsite.  This is a one story building that is subdivided into little office spaces.  Each space is occupied by a different company.  Some spaces are suites (multiple rooms), but most spaces are just single rooms with a few wall ports.  Centrally located is a secretary who handles all voice traffic for ALL companies.  Each company has their own separate 10.0.x.1\24 subnet.

Some companies, the larger ones with suites, have their own public IP address (69.150.150.x\26).  Some of them have a block of addresses assigned to them (though these have not been subnetted out as far as I know).  Each of the suites with Public IP's assigned has their own router or firewall to protect them that they individually manage.  

So, yes, we have a need for a DMZ.  And yes, we have assigned a substantial number of the 62 available addresses out to these companies.  I want to stay away from assigning static NATs and ACLs on the router, as I am turning this over to non-tech people to maintain.  But thank you for making the point as I hadn't considered that aspect.
Unlock this solution and get a sample of our free trial.
(No credit card required)


Sorry it has taken so long to reply.  I had to call HP out onsite to take care of this issue.  And it turns out it was a hardware failure in the routing circuits on the Layer 3 subsystems of the switch.  We ordered a new one, had it overnighted, implemented it in our current configuration and it worked like a charm.


The author of this solution provided a complete answer to the question that I was asking which would have provided a perfectly acceptable alternative to our present configuration.  I want to thank you again for your time and patience.
great to hear.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.