Provide Failover over L2 Replication Links

visio · ‎07-09-2009

Hello, thanks for the support of this expert forum.

I have a replication link issue involving the capabilities of automating failover across L2 circuits.

BOX A & B are 6513s running in Dual MPLS private WAN environment in 2 seperate Datacenter locations. Running BGP across MPLS for all routing within 300 site any-any MPLS network.

DETAILS:

Circuit 1: PROVIDER A 10.10.250.1 BOX-A

Circuit 1: PROVIDER A 10.10.250.2 BOX-B

Circuit 1 is 150Mb Optical Ethernet L2.

Terminating on GigE 10/42 on Box A

Terminating on GigE 9/37 on Box B

Circuit 2: PROVIDER B 10.10.250.7 BOX-A

Circuit 2: PROVIDER B 10.10.250.8 BOX-B

Circuit 2 is TDM DS3.

Terminating on S1/0/0:0 on Box A

Terminating on S1/0/1:0 on Box B

We split traffic manually & have placed

replication traffic across the links based upon server requirements and demand.

Routing: BOX A

ROUTES FOR DS3 LINK:

ip route 10.2.38.0 255.255.255.0 10.10.250.7 name <==Backup_Centera==>

ip route 10.2.39.0 255.255.255.0 10.10.250.7 name <==Backup_P2P_Centera_Items==>

ip route 10.2.40.0 255.255.255.0 10.10.250.7 20 <==Outlook==>

ROUTES FOR 100Mb Optical:

ip route 10.2.60.0 255.255.255.0 10.10.250.1 name <=Backup_SQL_DAL2ATL_==>

ip route 10.2.70.0 255.255.255.0 10.10.250.1 name <==Backup_SAN_DAL2ATL_==>

Box B:

ip route 10.2.38.0 255.255.255.0 10.10.250.8 name <==Backup_Centera==>

ip route 10.2.39.0 255.255.255.0 10.10.250.8 name <==Backup_P2P_Centera_Items==>

ip route 10.2.40.0 255.255.255.0 10.10.250.8 name <==Outlook==>

ROUTES FOR 100Mb Optical:

ip route 10.2.60.0 255.255.255.0 10.10.250.2 name <=Backup_SQL_DAL2ATL_==>

ip route 10.2.70.0 255.255.255.0 10.10.250.2 name <==Backup_SAN_DAL2ATL_==>

The problem is that our 100Mb optical link goes down in the provider core which is transparent to our network as both of our interfaces continue to show up/up at all times during these outages.

We have thought about inserting a IP SLA monitor task to routinely perform ICMP checks across the link (pinging 10.10.250.1 from 10.10.250.2 side etc) and this is the only way we have to prove that this link is down manually.

Is there an easier method that can be implemented and allow for failure of the L2 optical link (the only link that has ever gone down) and allow automated failover to the DS3 link?

If you need more details, please advise.

Thanks in advance for the support.

Andrew

vmiller · ‎07-09-2009

What kind of Optical link?

Sonet GIG/E ?

visio · ‎07-09-2009

Layer 2 Private Line GigE handoffs, not SONET.

vmiller · ‎07-09-2009

Ok. you currently use static routes between locations. I would consider a dynamic protocol, here is why. I had a similar issue, our trick was to capture the neighbor loss from the routing protocol. The L2 always stayed up (switch to ONS E100T)

visio · ‎07-09-2009

I am not running a 454 or even a 327 box. This is again not a SONET connection nor termination, just L2 ethernet private line handoff --- terminating directly onto a 6513-E.

What if I implement the utilization of unequal load balancing by having dual static route statements across the 2 unequal connections?

i.e.

ip route 10.2.60.0 255.255.255.0 10.10.250.1

ip route 10.2.60.0 255.255.255.0 10.10.250.7

Right now as configured above with the dual statics, it is using the DS3 & the 150Mb link as follows:

DS3 - 8Mb/sec out

150Mb - 66Mb/sec out

(All traffic is FROM one Datacenter to the other for replication --- always asynchronous)

What are the long-term issues with this configuration? What else can be done to resolve this?

visio · ‎07-10-2009

My biggest issue is that my interface on the GigE (L2 Ethernet) handoff never goes down when I have a failure, it stays up/up. The failure is transparent and usually in the provider core. If I setup an EIGRP process for these 2 unequal links with different variance levels would it automatically fail over? (if the absence of HELLO packets are noticed even without physical interface failure)

Thanks for the support.

vmiller · ‎07-10-2009

I don't think you need variance. you should get a trap when when the neighbor disappears. EIGRP should "know" the b/w difference between the links.