HSRP Over layer 2 WAN

[Ryan Fisher]

Hi, I'm trying to extend a vlan across my layer 2 connection to my colocation DC using hsrp.  The two different sites are using two different vtp domains, and they are both their respective vtp servers.  I'm not sure if that has anything to do with the problems I'm having.

When both vlans are active, any server in the primary site on the extended vlan loses connectivity to all remote sites, including the the colocation DC site.  If I shutdown the vlan at the colo, then all servers at the primary site regain connectivity.  Sounds like a possible routing thing, but everything is using eigrp so I would've thought that would take care of any changes.  While this is happening, the servers at the primary site on the extended vlan are still accessible locally to all other vlans and networks.

Now, from a workstation on a different vlan at the primary site, I can see the hsrp failover happen for that network and work just like it's supposed to.  I can tell by running a ping, that when I shutdown the primary site's vlan interface, I can see the ping times increase on the latency that's on that circuit, so I know that the failover happened.  And when I bring back up the interface locally, the pings stop for a few seconds then start back up with low latency times so I know it failed back.  So it would seem that the operation of hsrp is happening properly.

Here are my configs:

Primary site:

interface Vlan15
 ip address 10.200.145.2 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 no ip mroute-cache
 standby 0 ip 10.200.145.1
 standby 0 priority 105
 standby 0 preempt
 standby 0 authentication xxxxxx
end

Secondary site

interface Vlan15
 ip address 10.200.145.3 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 no ip mroute-cache
 standby 0 ip 10.200.145.1
 standby 0 priority 85
 standby 0 authentication xxxxxx
end

sh standby primary site:

Vlan15 - Group 0
  State is Active
    17 state changes, last state change 00:28:56
  Virtual IP address is 10.200.145.1
  Active virtual MAC address is 0000.0c07.ac00
    Local virtual MAC address is 0000.0c07.ac00 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.176 secs
  Authentication text, string "xxxxxx"
  Preemption enabled
  Active router is local
  Standby router is unknown
  Priority 105 (configured 105)
  Group name is "hsrp-Vl15-0" (default)

sh standby secondary site:

Vlan15 - Group 0
  State is Active
    11 state changes, last state change 00:01:22
  Virtual IP address is 10.200.145.1
  Active virtual MAC address is 0000.0c07.ac00
    Local virtual MAC address is 0000.0c07.ac00 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.224 secs
  Authentication text, string "xxxxxx"
  Preemption disabled
  Active router is local
  Standby router is unknown
  Priority 85 (configured 85)
  Group name is "hsrp-Vl15-0" (default)

Network topology:

Primary site Core 6500 <--> 3750 edge <-- Layer 2 connection --> Secondary CoLo site 3560

<-- Layer 2 connection --> Remote office 3560

<-- Layer 2 connection --> Remote office 3560

<-- Layer 2 connection --> Remote office 3560

I'm abut 100% sure I'm not giving enough information for anyone, so just tell me what you'd want to see and I'll post it.  I'm by no means an hsrp expert, but just know enough to make myself dangerous.

Thanks!

[Ryan Fisher]

HI, guys.  Thanks again for all your help.  I have attached two files that have the config, vtp status, show vlan and show interface trunk.  These two are for the edge switch and the dr switch.

Thanks!

[Jon Marshall]

Ryan

From the output of your edge switch at the primary site there is a trunk link to the remote site.

But what port on that switch connects back to the 6500 ?

If that port is not a trunk (and it doesn't look like it is) then what vlan is it in ?

Jon

[Richard Burts]

Jon

Good catch. Looking at the config I am guessing that the connection to the core is through the port channel which uses 1/0/24 and 2/0/24. But the port channel is configured for layer 3 and not as a layer 2 trunk. So vlan 15 is not getting out from the core.

HTH

Rick

[Ryan Fisher]

Yes, you are correct.  The core is connected with the port channel that is a routed interface.  That was done by our integrator that initially installed the network 5 years ago.  I wouldn't be able to talk to them about it anymore, but you have any ideas why they would've used a routed interface instead of a trunk to connect to the edge switch?  More secure?

Anyways, looks like I'll have to convert that to a trunk.  This will take some work and more than likely a downtime.  Do you recommend any particular config on those ports and port channel?  Or basic trunk should do?

Thanks a lot for helping figure this out.

[Richard Burts]

There are several reasons why you would want to design and implement a network with routed links connecting to the core. Among the reasons are these:

- it allows you to have redundant links without needing spanning tree.

- it reduces the size of broadcast domains.

- it isolates the core from the impact of spanning tree and reduces the interruption caused by spanning tree convergence.

- it makes it easier to control routing on the core.

- convergence following a network event is typically faster with routing protocols than it is with spanning tree (this was especially a factor before the introduction of Rapid Spanning Tree as an option for layer 2 convergence).

HTH

Rick

[Ryan Fisher]

Thanks for that.  So am I going to be doing a disservice to the network by changing this to a trunk?  Should I be thinking about doing this a different way?

Thanks

[Jon Marshall]

Ryan

Sorry I was posting while you and Rick exchanged posts.

See my last answer for a way to do it.

Rick makes good points about L3 and why you would want to use it.

In terms of doing it a different way, why exactly do you want to extend this specific vlan ?

Jon

[Ryan Fisher]

my ultimate goal is to be able to extend my server networks to my DR site so I can have the same address space at both locations.  That way I can fail my servers over to my DR site and I won't have to change the IP addresses on all the servers during failover.  This will greatly simplify my failover plan, decreasing my recovery times.

I figured hsrp would be the best way to do that.  That way the core router would be here and everything would go through that normally.  Then, if it failed over, the core router would be out there and all the servers would come up as if they were here.

From what you said above, this does seem to get a little complicated.  I think making a separate trunk from the core to the edge for those vlans would be the easiest.  So I'm thinking the config would be:

interface gix/x/x

switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,15
switchport mode trunk

and then make sure that in the eigrp router NOT add that interface as no passive-interface

This sound correct?  I'm also thinking there's no reason to make it a port channel, as it really is just passing trunk information through and doesn't need to be highly available.

Thanks!

[Jon Marshall]

You only need to allow the specific vlan on the trunk.

Yes you need to make sure the SVIs for that vlan on both switches, ie. the 6500 and the secondary site edge switch,  are passive because you don't want either switch seeing routes via that connection.

I'm not clear on what you mean by using the same IPs ie. do you mean literally the same IP on different servers because that would result in IP address conflicts.

If you want to use the same IPs in two different sites then the last thing you want is to extend the vlan between the two sites.

DC failover is a complicated subject and from what you have covered it's not clear how you see it working ie. are you providing DR for other remote sites etc.

Not trying to make things difficult but I'm not really understanding what you want to happen.

Jon

[Ryan Fisher]

So, what I'm doing is just providing disaster recovery to my one primary location.  I have server vlan 501 with ip space of 10.200.1.x/24 at the primary location.  I want that same vlan 501 with the same ip space 10.200.1.x/24 at the DR site for when the servers fail over so everything can come up and operate without the need for reconfiguration.

At the same time, I'm assuming that if the servers need to fail over, then the network is gone from the primary as well.  That is why I wanted to use hsrp to protect the server network, making the DR site the standby site for vlan 501.  That way, if the primary site went down, hsrp would fail the core routing of vlan 501 from the primary site to the DR and 10.200.1.x would be available at the DR site and core routing would then be local to the DR site.

Hope that makes sense.  Thanks

[Jon Marshall]

The problem is that if you extend the vlan between sites then they can see each other at L2.

So lets say your primary 6500 sends an arp for the IP of a server in that vlan. If you have used the same IP for a server in the primary site and a server in the secondary site they both respond because the arp is broadcast within the vlan.

More likely than not the response from the server in the secondary site will arrive after the response from the server in the primary site because of the extra latency and so this will overwrite the entry in the 6500 arp cache and all traffic is sent to the remote site server which probably isn't what you want.

Like I say DR is complicated and if I understand what you are proposing it just won't work.

You definitely don't want to extend the vlan between sites if you are reusing the same IPs in the secondary site.

What you could do is simply setup the vlan in the secondary site using the same IPs but then leave the SVI down so all traffic goes to the primary site unless it fails and then you have to manually bring up the SVI in the secondary site.

In effect they are actually different vlans but using the same IP subnet.

If you needed the servers in each site to synchronise  data between each other then it gets more complicated and you could extend the vlan but then you couldn't use the same IPs which would mean DNS changes if you need to failover.

Like I say DR failover is complicated ie. if you failover to servers in a DR site how do you synchronise data, what happens if the link is flapping so you are continually failing over and back again and how does that affect any data written to the servers.

There really is no easy solution to this ie. DR generally takes a lot of planning and costs quite a bit of money so it really comes down to just how automatic you need to make it and more importantly what the servers are doing ie. if you have database servers for example then it can become really tricky.

Jon

[Ryan Fisher]

My idea was that no servers in the DR site would be running on that vlan unless they were failed over.  I already have a different vlan out there for DR servers that are running now.  The extended vlan would sit empty out there and would only be used in the case of failover.  So I don't think I'd run into the issues you were mentioning.

I've thought about what you suggested of having a vlan ready to go but shut down, and that is an option.  I was just thinking this way would be a little more automatic than that.

Thanks for the help

[Jon Marshall]

So the servers in the secondary site would be readdressed in case of failover ?

If there are going to be no servers in that vlan until the main site has failed then yes you could do what you want and it would work.

And yes you would only need a trunk link but not necessarily an etherchannel for this because you are simply passing HSRP between the sites.

Jon

[Ryan Fisher]

No, I meant that the current servers that are running there now are on a different network, 10.100.205.x, so there would be no need for anything to be running in the vlan that is extended from the primary site.  That would only be used in case of failover.

Thanks all for sticking this out with me and giving me all the advice.  Once I get my downtime scheduled I'll get the changes in and will post back my results.

Thanks!

[Jon Marshall · Accepted solution]

Ryan

If po1 is the connection back to the 6500 then it's not that simple because you have WCCP applied to that interface and also other L3 SVIs on the edge switch.

So you are not just routing between sites you are also doing routing between local vlans on the edge switch.

I think what you need to do is -

1) create a new vlan on the 6500 and the edge switch and this vlan is used purely for routing between those two switches.

2) change the port channels on both switches to be trunk links and only allow the new vlan you have created plus the vlan you want to extend on those trunks.

This is important ie. you must only allow the two vlans

3) create an SVI for the new vlan on both switches and use the IP address assigned to the port channel interface on the SVI on each switch respectively.

You also then need to move the WCCP commands on the port channel interface on your edge switch to the SVI you have just created on the edge switch.

What you have then done is basically emulate your current L3 setup but also extended one specific vlan between sites.

As far as I can tell that should work but there are no guarantees as I don't know the full topology.

The alternative is to simply run another connection between the 6500 and the edge switch specifically for the vlan you want to extend although you may not want or be able to do this.

Edit - if you did run another connection you want to make sure no routing updates are exchanged across it ie. you only want this link for HSRP etc so you would need to make the SVIs for this vlan passive on both edge switches.

Jon