Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

DC design problem

We have test lab-2xCat6k in DC with connected server via 2 NIC.On server NIC teaming configured.

Traffic flows R1-R2(2.2.2.2)-SW1-Server

In case of failure interface fa0/1 on R1

traffic flows R1-R3(1.1.1.2)-SW2-FAILED because SW1 still active in HSRP.

Server have configured default gateway to 5.5.5.1 (and 5.5.5.2 active)

but link to 2.2.2.1 failed.

How to be in that situation?

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Blue

Re: DC design problem

Hi

I can't open the visio at home so i might be misreading this but when your fa0/1 link on R1 fails the advertisement for your client LAN should disappear from R2.

When the traffic returning from the server goes to sw1 shouldn't the traffic then be switched across the trunk link to sw2 then routed back out via R3.

Do the 2 6500 see each other as OSPF neighbours and exchange routes with each other. If not, this would be the simplest way to fix your issue.

Or, if you have the interfaces you could dual connect R2 & R3 so each router connects to both 6500 switches.

HTH

Jon

19 REPLIES
Hall of Fame Super Blue

Re: DC design problem

Hi

I can't open the visio at home so i might be misreading this but when your fa0/1 link on R1 fails the advertisement for your client LAN should disappear from R2.

When the traffic returning from the server goes to sw1 shouldn't the traffic then be switched across the trunk link to sw2 then routed back out via R3.

Do the 2 6500 see each other as OSPF neighbours and exchange routes with each other. If not, this would be the simplest way to fix your issue.

Or, if you have the interfaces you could dual connect R2 & R3 so each router connects to both 6500 switches.

HTH

Jon

New Member

Re: DC design problem

Hi!

6500 switches didn't see each others via OSPF. i puted them into same area 1 and it helped.

one moment still worried me - after failure it takes 8 losted pings to restore connection via new route. Is't ok? ( seems 10 sec ).

Hall of Fame Super Blue

Re: DC design problem

Hi

Glad it worked.

There will be a delay as OSPF recalculates the routing table on SW1. You could try fine tuning the OSPF timers to get a better convergence time.

One longer term solution is to run dual links from both your switches to each router. This way each switch (SW1 & SW2) should have equal cost paths to the remote network, so when you lose one path you will have another path in the routing table to use straight away.

Bear in mind with this solution that your traffic could be asymmetric, ie it goes out one exit point and enters another.

We use EIGRP in our data centre and it can be very fast to reconverge as long as it has a feasible successor in it's topology table. But i'm not suggesting you change to EIGRP !!

HTH

Jon

New Member

Re: DC design problem

yes, we are going to use dual links from both switches to each router.

you told about asymmetric traffic - is't for solution with dual links or not?

About EIGRP - it's critical for us if the convergence lasted over 10 secs( or 8 losted pings).

Can you give me few advices? as you can see from my picture we have something as backbone with 2 MEN clouds from 2 different providers and connected offices. Do you think it will be better have one EIGRP AS for all routers and for switches in datacenter or something else?

Hall of Fame Super Blue

Re: DC design problem

Hi

Asymmetric routing may or may not be a problem for you. It can create problems with firewalls if the traffic going out goes through one firewall and the traffic coming back in goes through another although there are ways around this.

If you do per-destination load balancing you should be fine.

As for running EIGRP. I wouldn't recommend changing without a lot of testing. The issue is if the link at the remote end goes the OSPF LSA's have to propogate from your remote site, through the provider cloud and into your DC and then the routers run the OSPF algorithm to compute new routes.

While this is happening you can lose packets because until the routing tables have converged you could still be sending packets out down the wrong path.

No matter how fast your routing protocol converges in the DC it still relies on the link failure being propogated to the DC.

Does R1 peer with R2 & R3 directly ie. is the provider cloud implemented as layer 2 ?

I think the best thing to do at the moment is to put dual links in, confirm that OSPF is seeing 2 equal cost paths from each switch (SW1 & SW2) to the remote network and then do some testing.

If you are still not happpy with the covergence times you could then think about looking to utilise another routing protocoll but this is not a trivial change and OSPF offers certain advantages over EIGRP even though it can be slower to converge.

HTH

Jon

New Member

Re: DC design problem

Jon,thank a lot!

We are going to test all solutions and decided based on the results!

if ok i'll inform you later about it and problems?

New Member

Re: DC design problem

You could just reduce the dead & hello interval on r2,r3 & r1 across the MEN links.

you can set dead-interval to 1 sec, newer versions of ios will then send hellos in intervals less than one second (upto 1/20th of a second).

use the interface commands

ip ospf dead-interval ...

ip ospf dead-interval minimal ....

this will allow you to keep the existing ospf design but reconverge in about 1 second.

Silver

Re: DC design problem

If sub second convergence for OSPF is a concern than you may want to consider BFD:

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper0900aecd80244005.shtml

-Brad

New Member

Re: DC design problem

Here another question based on previuosly publicated schema-

on R1 i've routing table with 2 equal routes-

R1#sh ip route ospf

.....

5.0.0.0/24 is subnetted, 1 subnets

O E2 5.5.5.0 [110/20] via 2.2.2.100, 00:07:59, FastEthernet0/1

[110/20] via 1.1.1.100, 00:07:59, FastEthernet0/0

and

R1#traceroute 5.5.5.100

Type escape sequence to abort.

Tracing the route to 5.5.5.100

1 2.2.2.100 0 msec

1.1.1.100 0 msec

2.2.2.100 0 msec

2 3.3.3.2 0 msec

3.3.1.2 0 msec

3.3.3.2 0 msec

3 5.5.5.100 0 msec 0 msec 0 msec

R1#

I think it's not good to have such behavior? Is't better to use only 1 route ( which i can select with cost on the interface)?

New Member

Re: DC design problem

The router will by default do per destination load-balancing , unless you specify per-packet load-balancing. So, it shouldnt be a problem.

You can also influence the above routes with cost on the interface, although you wont see that cost reflected in the metric for the OE2.

The cost to the ASBR that originated the OE2 will change and that will modify the path costs.

Worth a try.

New Member

Re: DC design problem

Here another additional question - as you can see from shema and config - the switch SW1-OR is active by HSRP. Links to router R2-OR and R1-GT are connected to gi5/1 and gi5/2 on Sup module. In case of failure Sup module or if somebody disconnected those both cables the switch is still active for servers ( for example 5.5.5.100). And server is unavailable from outside network.

How to be in that situation?

!

interface GigabitEthernet5/1

ip address 3.3.3.2 255.255.255.252

ip ospf dead-interval minimal hello-multiplier 10

!

interface GigabitEthernet5/2

ip address 3.3.1.2 255.255.255.252

ip ospf dead-interval minimal hello-multiplier 10

media-type rj45

!

....

!

interface Vlan5

ip address 5.5.5.2 255.255.255.0

standby 5 ip 5.5.5.1

standby 5 priority 110

standby 5 preempt

!

CAT6K-sw1# sh standby

Vlan5 - Group 5

Local state is Active, priority 110, may preempt

Hellotime 3 sec, holdtime 10 sec

Next hello sent in 1.336

Virtual IP address is 5.5.5.1 configured

Active router is local

Standby router is unknown

Virtual mac address is 0000.0c07.ac05

2 state changes, last state change 00:06:28

IP redundancy name is "hsrp-Vl5-5" (default)

Hall of Fame Super Blue

Re: DC design problem

Hi

How many Sup's do you hqve in each switch ?.

If you have only 1 sup per chassis then if the Sup goes the whole switch goes and the alternate path should be via your second switch. HSRP will transfer the VIP to the active second switch so you will be okay in that scenario.

As for having both router connections from the same Supervisor. As already mentioned if Sup goes then it shouldn't be a problem. As for both cables being disconnected this is more of a proedural thing, as you could argue that cables can be disconnected whichever module they are connected into.

If both your router connections were connected to a single ethernet module in the chassis then you would be right to be more concerned as that module could fail but the switch stay up. But if the sup fails the switch fails.

If you have 2 sups in each chassis then it would be better to run a connection from one Sup to one router and the other connection from the other sup to the other router.

HTH

Jon

New Member

Re: DC design problem

Hi!

I've only one Sup per chassis.

Business are crazy about availability and i should look into each every situation ( maybe if it's not happen).

I agree that the second Sup will be solution for that situation but....

Do you think it's better to place one connection to Router into first WS-X6748-GE-TX CEF720 48 port 10/100/1000mb Ethernet and connection to second router leave on the Sup module?

Do you think it'll impact on productivity?

Hall of Fame Super Blue

Re: DC design problem

Hi

It won't hurt to do this and in theory you have now spread failure across two modules. It won't impact on productivity as long as you run the connections at the same speed.

I would still argue though that if the supervisor module goes then your switch has gone anyway but by all means utilise the 6748-GE-TX for one of the router connections.

HTH

Jon

New Member

Re: DC design problem

Thank you!

New Member

Re: DC design problem

i have another question regarding that design - how to configure load balancing here? ( for use both links ).

New Member

Re: DC design problem

rmv72,

I noticed this interesting thread and if possible, could you post the current ospf config and other ospf command output, ie. ospf int, neighbors, etc.

Learned a lot from this thread!

New Member

Re: DC design problem

sorry, my lab is not working now.i can post info a little bit later when it'll be working on production net. let me know.

New Member

Re: DC design problem

That would be great, looking forward to it.

268
Views
12
Helpful
19
Replies
CreatePlease to create content