Topology Design Feedback

[Cody Ridge]

Hello,

I have been working on a network topology design for one of my clients.  Please see the attached pdf detailing the diagram and traffic flow scenarios.

The routers have a 4 port switch module that connects to Switches A Primary and B Secondary.  There will be 1 Vlan50 LAN interface on the router, with Switchport access vlan50 on the Switch ports.   Additional vlans may be added in the future and the Switch ports will be changed to Trunks.

Based on this cabling, do I need to simply enable spanning-tree on the switchports and switches?  Or will this design require more specific spanning-tree configuration options?  Is the portfast command required on any of these ports?

I am looking for feedback on this design.  Are there any apparent routing issues that would prevent traffic flow under the normal operation and failover scenarios detailed in the pdf document?

Thank you for your comments and feedback.

[andrew.prince]

Cody,

Why are the routers on the outside?

Why are the firewalls being used as routers?

From the diagram - no switch actually connects to another switch, why would you want spanning-tree, you have no physical loops?

I my opnion you have designed the failover in the wrong part. Unless you are running BGP on the routers - your internet is your single biggest point of failure, and you are providing all resiliancy for that.

What happens if the uplink from switch 1 to the active firewall fails, all devices on switch 1 will have no network access????

HTH>

Andrew.

[Cody Ridge]

Hi Andrew,

Thank you for your valuable feedback.

The Metro Ethernet is supplied by the ISP and not managed by the client.  Redundant ISP equipment and links are not really an option at this time.  The goal was to reduce the failure potential of all the client owned equipment.

Why are the routers on the outside?

No really clear on this query.  From what I understand the ISP needs a router to connect the Metro Ethernet and route the traffic to the LAN.

Why are the firewalls being used as routers?

The firewalls have an Outside interface that routes all LAN traffic to the outside and forwards all incoming traffic to the LAN.  In my experience with PIX firewalls, this is required.

From the diagram - no switch actually connects to another switch, why would you want spanning-tree, you have no physical loops?

The Switchports on the 2821 do connect to SwitchA/SwitchB.  This is why I inquired about spanning tree.  My experience with advanced switching is limited and was looking for information on whether spanning tree would be needed or not.

The Internet and Metro Ethernet are the single point of failure.  However, the service is redundant in the building.  Again, this can not be avoided at this time.

The current configuration of Switch1 and Switch2 does provide resiliency for internal LAN traffic to the PIX firewalls.  I was not involved in that phase of the configuration and am responsible for the firewalls up.

Thanks again

[andrew.prince]

Hi Cody,

"Why are the routers on the outside?

No really clear on this query.  From what I understand the ISP needs a router to connect the Metro Ethernet and route the traffic to the LAN".

*** No all the ISP requires is a next hop to pass the internet traffic onto - this can be ANY interface capable of LAYER 3 routing ***

"Why are the firewalls being used as routers?

The firewalls have an Outside interface that routes all LAN traffic to the outside and forwards all incoming traffic to the LAN.  In my experience with PIX firewalls, this is required"

*** This is not an optimum design *** What protection are you providing for the routers?

"From the diagram - no switch actually connects to another switch, why would you want spanning-tree, you have no physical loops?

The Switchports on the 2821 do connect to SwitchA/SwitchB.  This is why I inquired about spanning tree.  My experience with advanced switching is limited and was looking for information on whether spanning tree would be needed or not."

*** Which switches in the diagram are the 2821 ***

The Internet and Metro Ethernet are the single point of failure.  However, the service is redundant in the building.  Again, this can not be avoided at this time. IS the Metro Ethernet connecting to another site of the customer??

The current configuration of Switch1 and Switch2 does provide resiliency for internal LAN traffic to the PIX firewalls.  I was not involved in that phase of the configuration and am responsible for the firewalls up. *** This is not an optimum design ***

[Cody Ridge]

Hi Andrew,

I appreciate your insight into this design.

The client will have little or no ability to manage and configure the Metro Ethernet.  They also do not want to rely heavily on the ISP for major technical modifications or changes.

This design proposal is working within the technical and budgetary realities of the client.  Most of this equipment is presently purchased and may not easily be discarded.  I agree this equipment may not be the most optimal approach.  If I were to design an optimal topology from scratch, this is probably not what I would suggest.

That being said, could you offer any suggestions on using this present equipment in the most optimal manner?

Thanks again for your time, effort and assistance.

[andrew.prince · Accepted solution]

Hi Cody,

Firstly having routers outside your firewalls is a waste - what are they routing?? They have a default gateway to the ISP and that's it.  How are you securing them?  I presume the customer wants to be able to connect to them/manage them? If the routers are compromised, you compromise the inside network, from either bad security or config mistakes on the firewalls/routers.

This design merely fulfils current requirements - you should design your topology to be future proof and fulfil requirements the customer has not even considered yet.

Connect the metro Ethernet directly to the outside of the PIX firewalls on the "outside" interfaces of the active/standby PIX/ASA.

Move the routers back inside the topology, have your redundancy there.  Have RTR Primary connect to switch 1, and RTR Secondary connect to Switch 2, run HSRP between the routers, give switch 1 & 2 vlan management interfaces.  Connect switch 1 to switch 2 - you now have a fully redundant layer 2/3 topology.  This topology allows you to connect remote customer sites if desired in the future, via VPN's or direct circuits to the "Inside" protected network. You now have the option to run multiple IP subnets, easily configured/managed - you can have multiple VLAN's perhaps separating servers from workstations or even the finance department from the typing pool etc.  They may even want to host services in a DMZ...

Attached is how I would change the proposed topology using existing equipment and providing future expansion.

HTH>

Andrew.

[Cody Ridge]

Hi Andrew - Intersting way to look at this issue.  Thank you.

I am a little unclear about the connectivity with the routers.  Would I not want to connect the inside interface of the pixs with an interface on the router?  Or are they there just for intervlan routing?

Thanks.

[andrew.prince]

Why would you directly connect from the router to the pix, and waste IP addresses and you then need another interface to connect to the LAN?

[jgraafmans]

*** Which switches in the diagram are the 2821 ***

The 2821 routers have switch modules installed and this modules connects both routers witch each other’s and with the switches.

With this design you can make “RTR Primary” the spanning-tree root and the other router the secondary root. If you do this traffic will flow as stated in the PDF.

The disadvantage with this design is that only common spanning-tree is supported on the switch modules. To solve this you can enable uplinkfast on “Switch A Primary” and “Switch B Secondary”.

But why don’t you connect both ASA’s directly to the Metro Ethernet. If you do that you save 4 devices and you don’t have to worry about spanning-tree. Or you can leave the switches between the ME and the ASA’s with the switches interconnected and “Switch A Primary” configured as spanning-tree root. This gives you the possibility to connect more devices directly to the ME.

[Cody Ridge]

Hello jgraafmans,

Excellent information on the spanning-tree issue.  Thank you.

I would love to utilize the ME to handle more features and eliminate any devices.  Unfortunately, the ME is not owned or managed by the client.

Therefore, making new and ongoing modifications would be difficult.

*** Which switches in the diagram are the 2821 ***

The 2821 routers have switch modules installed and this modules connects both routers witch each other’s and with the switches.

With this design you can make “RTR Primary” the spanning-tree root and the other router the secondary root. If you do this traffic will flow as stated in the PDF.

The disadvantage with this design is that only common spanning-tree is supported on the switch modules. To solve this you can enable uplinkfast on “Switch A Primary” and “Switch B Secondary”.

But why don’t you connect both ASA’s directly to the Metro Ethernet. If you do that you save 4 devices and you don’t have to worry about spanning-tree. Or you can leave the switches between the ME and the ASA’s with the switches interconnected and “Switch A Primary” configured as spanning-tree root. This gives you the possibility to connect more devices directly to the ME.

[shailesh.h]

Nice elaborative diagram but can have more information to provide you few suggestions

1. Is this currently been deployed
2. What is your scope
3. What are the issues currently you faced
4. Is there outage would be agreed if downtime required?

[Cody Ridge]

Hello shailesh.h,

Is this currently been deployed

No.  Some of this equipment is presently in production.  The client was not satisfied with their ability to respond to device faults.

What is your scope

The client has already purchased most of the equipment in the diagram.  The goal was to design a way to successfully interconnect the devices and produce an acceptable level of resiliency.

What are the issues currently you faced

When looking at this project I was not well versed in spanning-tree.  I felt connecting the switchports and switches would bring specific spanning-tree configuration into play.  As previously stated, I don't see this as the most optimal solution.  However, is it a workable model?

Is there outage would be agreed if downtime required?

The client understands a redesign may result in downtime to allow for deployment and testing.  It does not appear to be a concern.

Thank you

[shailesh.h]

Hi,

1. Can you please share the list of inventory with versions
2. It would be great to see if IP Addressing scheme if any either planned or available
3. What would be communication requirement from inside to outside and outside to inside
4. Is this small size data centre / mid-size data centre or branch office kind of location?

With regards,

Shailesh