Routing to multiple Default Gateways

[davidjknapp]

This may be a simple process, but I can not find a difinity answer.  Hope someone can help.  I am designing a template that allows for multiple sites to connect to an MPLS network as well as support a separate isolated network at each site.  the isolated network will need to route to some of the subnets so I need to point the gateway to the core (3750).  The MPLS connected network will also be pointed to its respective vlan ip on the core switch for the site.  The issue I have is I need the isolated network to utilize a local internet connection while the MPLS side of the house will be connected up to the primary hub via the MPLS. 

In the example below VLAN 100 and 120 will be routed to the MPLS via the switches default gateway; VLAN 200 and 220 need to be routed to the local gateway (10.2.4.1).  So if my default route is as configured below, how do I redirect LANS 200 and 220?

interface GigabitEthernet1/0/1
description Network 1
switchport access vlan 100
!
interface GigabitEthernet1/0/2
description Network 2
switchport access vlan 120
!
interface GigabitEthernet1/0/3
description Network 3
switchport access vlan 200
!
interface GigabitEthernet1/0/4
description Network 4
switchport access vlan 220
!
interface Vlan100
description LAN1
ip address 10.100.100.1 255.255.255.0
!
interface Vlan120
description LAN2
ip address 10.4.123.254 255.255.255
!
interface Vlan200
description LAN3
ip address 10.100.200.1 255.255.255.0
!
interface Vlan220
description LAN4
ip address  10.2.4.254 255.255.255.0
!
Route 0.0.0.0 0.0.0.0 10.4.123.1

[Jon Marshall]

Greg

A number of things spring to mind. Couple of clarifications needed

1) are all the vlans on the 4500 are on the 3750s. From your description it sounded lilke you only had vlan 110 on the switches but is that just the management vlan ie. all the other vlans are on the IDF switches as well ?

2) the 2800 router and the 4500 switches share a common vlan with HSRP running on it, actually the same vlan that the IDF switches uses ie. 10.68.32.0/24 ?

If so you could -

1) load-balance the vlans by having half the vlans have 4500_1 as STP root and the other half having 4500_2 as STP root. You would need to match the HSRP active gateway for the vlan with the STP root. That way traffic flows to both 4500 switches from the IDF switches.

You then need to get the MPLS admins to change the static route for 10.68.32.0 which points currently to the HSRP VIP of .1 to 2 static routes which point to the actual physical interface addresses of the 4500 connections.

With the above you then use both switches from the 3750 switches and both 4500 switches in the return traffic from the 2800  router.

2) a modification on this is to use GLBP which would automatically load-balance between the 2 4500 switches from the 3750 IDF switches. However problem here is that because you have a L2 trunk between the 4500 switches (which i'm assuming it is) then traffic for one of the 4500 switches from the IDF switches ie. the 4500 switch which has a blocking link to the IDFs, would need to keep going across the interconnect all the time.

GLBP works better if the link between your distribution switches (4500s) was a L3 links so both uplinks from the IDFs are non-blocking.

You would still need the MPLS group to modify the static route.

3) the other alternative would be to route the vlans off the IDF's and have L3 routed uplinks. This would automatically load-balance your traffic. However i can't see a lot of point in this as the 4500 then almost becomes a L2 switch only. And you would need to readdress some things because the 10.68.32.0/24 network exists both on the IDF and 4500 switches which it couldn't with this setup.

So, depending on the answers to the clarifications above i would go with 1). Note that all of the above have concentrated on the load-balancing aspect although they obviously cover redundancy as well.

If however you want to keep config to a minimum and only want redudancy then simply connect up the 2nd switch. I can't see anything from your description that would stop that being redundant ie. -

the 3750s have 2 uplinks one to each switch so if one of the switches fails it smply uses the other uplink.

same goes for the 2800 router , it has a route pointing to the VIP so if the active VIP 4500 fails it should move over to the other switch.

If i have misunderstood anything in the setup please let me know.

Jon

[Jon Marshall]

Greg

Follow up to previous thread.

There is actually something that doesn't make sense. You say that the router points to the VIP for 10.68.32.0/24 network on the 4500 switches. And that the router interface that is connected is using 10.68.32.4 ?

If so you won't be able to give the 2800 router another IP from the 10.68.32.x network on another interface because it won't let you. So you won't be able to just connect up the 2nd switch without modifying the addressing on the MPLS router.

So what i would do is have 2 new P2P subnets eg.

192.168.5.0/30

192.168.5.4/30  (you can choose any addressing, this is just an example)

4500_1

int gi0/1 <-- this connects to 2800

no switchport

ip address 192.168.5.1 255.255.255.252

ip route 10.0.0.0 255.0.0.0 192.168.5.2

4500_2

int gi0/1 <-- this connects to 2800

no switchport

ip address 192.168.5.5 255.255.255.252

ip route 10.0.0.0 255.0.0.0 192.168.5.6

2800 router

========

int gi0/1   <-- to 4500_1

ip address 192.168.5.2 255.255.255.252

int gi0/2  <-- to 4500_2

ip address 192.168.5.6 255.255.255.252

ip route 10.68.32.0 255.255.240.0 192.168.5.1

ip route 10.68.32.0 255.255.240.0 192.168.5.5

Jon

[Gregory Flett]

Jon -

These are some great suggestions. First let me clarify - the access switches (IDFs) have an IP address on VLAN 110 but they are VTP clients so they know of all the VLANS.

PvSTP is something I hadn't thought of, our VLANs aren't specific to areas but rather types of devices, so finding the "middle" of the traffic between VLAN 115 which is workstations and VLAN 117 which is phones would require a little analysis on my end so I could balance them manually by choosing which ones should go where. GLBP would also be a good technique to load-balance the access switches and I'll do some further research on that, should be pretty easy to implement. I can see if I can get approval for the licenses to implement L3 on the access switches.

You were correct in sniffing out the error in our communication. The router is at 10.68.32.4/24 and the single static route is to the VIP for 10.68.32/20.

Since as you said we can't put two interfaces in the same subnet then we have to transition to something like you suggested - using /30 networks like we were going to do with the routing protocol. Your example looks good except I don't see the reduncency... that is:

If the port on either side of let's say the 4500_1 connection goes down on either the router or the switch how would the switch know that it can send the traffic to 4500_2 to complete the connection. This could be said for 4500_2 as well. Would a second static route using the other switch with a higher AD solve this?

so on 4500_1 there would be:

ip route 10.0.0.0 255.0.0.0 192.168.5.2

ip route 10.0.0.0 255.0.0.0 10.68.32.3 100

and 4500_2:

ip route 10.0.0.0 255.0.0.0 192.168.5.6

ip route 10.0.0.0 255.0.0.0 10.68.32.2 100

the router would stay the same.

Essentially the end goal is the same as what a routing protocol would do except it's a little more dangerous because it's hardcoded. A coworker also told me this has the potential to create a loop which is why I didn't just go with this the instant the MPLS group told me no OSPF. Could you attest to this?

Thanks again for the information.

Greg

[Jon Marshall]

greg

This could be said for 4500_2 as well. Would a second static route using the other switch with a higher AD solve this?

Good catch, yes you would need this or alternatively run EIGRP/OSPF between your 4500 switches so they know about each others routes. I was thinking only of a switch failure which meant the 3750s would never send traffic to the failed switch.

Essentially the end goal is the same as what a routing protocol would do except it's a little more dangerous because it's hardcoded. A coworker also told me this has the potential to create a loop which is why I didn't just go with this the instant the MPLS group told me no OSPF. Could you attest to this?

Could the coworker be a little more specific If you use floating statics you should be okay as far as i can see.

GLBP would also be a good technique to load-balance the access switches and I'll do some further research on that, should be pretty easy to implement. I can see if I can get approval for the licenses to implement L3 on the access switches.

Just to clarify, GLBP does not require L3 at the access-layer. I'm not even sure you gain that much from routing from the access-layer in this situation although it would mean not having to manually configure the vlan load-balancing.

GLBP would work much better if you used a L3 link betwee 4500 switches, that way both L2 uplinks from each 3750 are non-blocking because there is no L2 Loop anymore.

Jon

[Gregory Flett]

Short and sweet. But it works.

Tried it out in a simulation and it worked perfectly. I like to think about routers and switches as fragile items hence I like to load-balance as much as possible. Even though these switches are capable of gigabits per second and they're doing probably 50Mbps I still like to treat them gingerly and share the load as much as possible. And who knows, in a few years it might turn out to be needed.

I'm going to toy around with GLBP because getting a L3 link between the networks will be easy as we have a /20 for the site, and I'd still be able to have HSRP and be able to simulate the etherchannel with an equal cost route. My manager may think I'm obsessed with this network because it's working perfectly fine in its current configuration but since this is my first major design/deployment I feel I need to make it as good as can be!

Thanks for all your help Jon, you are a gentleman and a scholar; I'll make sure to pay it forward by contributing back to the forum.

Thanks again

Greg