HSRP and IGP Design

[Nick Cutting]

I would like to get a feel for how people using eigrp and ospf with hsrp in the LAN.

For example you have 4 SVI's on 2 3560's that are trunked between each switch

Switch 1 is connected to Switch2 via a trunk

Switch 1 is connected to Active firewall Via SVI vlan64 10.250.64.2 (HSRP .1)

Switch 2 is connected to Standby firewall Via SVI vlan64 10.250.64.3 (HSRP .1)

Active firewall is 10.250.64.6, and is particiatring in eigrp.

Switch 1 is connected to another office via a singell routed port

Switch 2 is connected to a third office via a singell routed port

router eigrp 100

network 10.250.64.0 0.0.0.7 (Firewall transit network)

network 10.250.64.8 0.0.0.3 (Point-to-Point out Gig0/45)

network 10.250.65.0 0.0.0.255 (users)

network 10.250.66.0 0.0.0.255 (monkeys)

network 10.250.67.0 0.0.0.255 (Coffee machines)

passive-interface default

no passive-interface Vlan64

no passive-interface Vlan65

no passive-interface Vlan66

no passive-interface Vlan67

no passive-interface GigabitEthernet0/45

There are other offices connected via P2P networks, and the other switch participating in HSRP also has another p2p to anpther office:

for example here is the ECMP for routes learned from the second switch, across the P2P from, office3

D       10.88.73.0/24 [90/3328] via 10.250.67.3, 01:00:47, Vlan67

                       [90/3328] via 10.250.66.3, 01:00:47, Vlan66

                       [90/3328] via 10.250.65.3, 01:00:47, Vlan65

                       [90/3328] via 10.250.64.3, 01:00:47, Vlan64

D       10.88.72.0/24 [90/3328] via 10.250.67.3, 01:00:47, Vlan67

                       [90/3328] via 10.250.66.3, 01:00:47, Vlan66

                       [90/3328] via 10.250.65.3, 01:00:47, Vlan65

                       [90/3328] via 10.250.64.3, 01:00:47, Vlan64

D       10.88.75.0/25 [90/3328] via 10.250.67.3, 01:00:47, Vlan67

                       [90/3328] via 10.250.66.3, 01:00:47, Vlan66

                       [90/3328] via 10.250.65.3, 01:00:47, Vlan65

                       [90/3328] via 10.250.64.3, 01:00:47, Vlan64

D       10.88.74.0/24 [90/3328] via 10.250.67.3, 01:00:47, Vlan67

                       [90/3328] via 10.250.66.3, 01:00:47, Vlan66

                       [90/3328] via 10.250.65.3, 01:00:47, Vlan65

                       [90/3328] via 10.250.64.3, 01:00:47, Vlan64

D EX    10.88.71.0/27 [170/3584] via 10.250.67.3, 01:00:47, Vlan67

                       [170/3584] via 10.250.66.3, 01:00:47, Vlan66

                       [170/3584] via 10.250.65.3, 01:00:49, Vlan65

                       [170/3584] via 10.250.64.3, 01:00:49, Vlan64

To reach networks on the point to point links on the opposite switches, to remove the ECMP would you:

Not advertise the HSRP SVI's into EIGRP, and get the networks into EIGRP via static routes  to null zero (eigrp auto redist via network statements as the statics to interfaces are connected) - shows as internal.

To clean up the possible adverse routing if HSRP fails over OR if the firewalls failover, but not both - by chaning B/W or Delay on the primary switch for the transit VLan (64)

Change metric on all SVI's on the second switch to make the first preferred.....nightmare when HSRP fails over...

As outlined here:

http://ccie-in-3-months.blogspot.co.uk/2008/11/solving-routing-asymmetry-due-to-hsrp.html

Not scalable, not practical in real world.

There has to be a better design in these types of scenarios - anyone have any deisgns that they have implemented that look at this sort of thing?

[Jon Marshall]

Nick

It's not clear exactly what issue you are trying to solve but a few considerations based on what you have -

1) why run EIGRP on the firewalls if they are pointing to an HSRP address ?

2) the multiple peerings between your 3560s. We used to make all the  HSRP vlans passive and then use a dedicated vlan (or a pair of vlans) for the peering between switches for which there was no need to run HSRP on. 

Another option is to use a separate L3 connection for peering and only use your L2 trunk for HSRP but that depends on spare ports etc.

You mention asymmetric routing but that is not an issue in your design as there is no asymmetric routing with the firewalls assuming you are pointing to the active firewall IP.

Perhaps you could clarify what your exact concerns are ?

Jon

[Nick Cutting]

Thanks Jon,

I guess I was wondering how people advertised connected networks into eigrp, when using HSRP, without getting a bunch of useless ECMP's.

Running HSRP on the firewalls - was purely food for though with the HSRP next hop on the 3650's - I had this scenario recently with a client - and he kept running ospf on his 5555x's.  The argument I gave here was the same as yours. - however in some cases we have home users with asa5505's and use RRI. - I usually up the delay on the second switch's transit SVI for this to remove the ECMP from the ASA's routing table.

I cannot rememever what the Assymetric scenario was sorry - It was keeping me up early one morning - but it escapes me this evening!

regarding your 2) - would you choose perhaps only the Firewall transit vlan for the neigborships - use network statements + passicve interfaces on the user/printer/devices Vlans using HSRP?

My other question about the ASA's - is what to do If you have a over 100 L2L VPN's on the firewalls, that you need to get into EIGRP, out to the other offices.  If using the example above, would you prefer to use multiple static routes on the ASA, then redistribute there down to the 3560's then out to the other offices - maybe summarise these to

rfc1918 address when sending the updates to the switches.

Or would you not run eigrp on the ASA's - and on the switches statically route all rfc1918 address space to the ASA, then redistribute those routes.

Cant really advertise default information, as each office would have its own internet connection, and only routes to the subnets on the other end of the 100 VPN's, across p2P links and up to the ASA's would need to be learned.

Sorry for the scenario overload - but I think about these things - and while I know how it all wqorks - its good to get a feel for how people are doing these things. I am always interested in a simpler, more scalable and resilient design.

[Jon Marshall]

Nick

In terms of the peering vlan i generally didn't use any of the HSRP configured vlans. Like i say i just created a new vlan |(or two just in case someone accidentally shut one down)  for peering without using HSRP. We did have a lot of sites though so we needed a standard and we used the same vlan number in all sites. Then all HSRP vlans would be made passive.

Doing this does clear up your routing table and peerings between the two 3560s so i would definitely look to do that. You can use an existing vlan or vlans for the peerings ie they don't need to be new.

In terms of the firewall and HSRP/EIGRP i'm not sure what the benefit is to running both. You mention needing to send EIGRP routes to remote sites via VPN but how are you doing that ? I haven't used ASAs for a while so i may be a bit out of date but my understanding was you needed GRE with IPSEC to pass EIGRP updates and the ASAs don't support GRE.

I would have thought each site only needed a default route pointing to their firewall and then a default route on the firewall pointing out of the outside interface. The crypto map actually defines what traffic is sent via the IPSEC tunnel.

But i suspect i am not fully understanding your firewall setup in terms of remote sites so perhaps you could clarify ?

Jon

[Nick Cutting]

Sorry I have been unclear, The firewalls are old school VPN's as they dont do ipsec + gre or the newer VTI, which are limited to routers only.  - I run VTI wherever I can, but sometimes clients dont want to buy a router, when they have a layer3 switch and a FW for vpns.

Imagine a branch site with one switch, and one firewall. The switch is running ospf/eigrp with a /30 Point-to-point link back to the main site.  The Firewall is used for internet access only.

The main site learns the LAN subnets of the branch site via eigrp, and vice versa. The firewall at the main site has many many vpns to 3rd partys.

These remote subnets of the third parties need to be accessed by the branch site, via the P2P.

There is no Site2Site vpn between the branch site and the main site.

Would you redistribute individual static routes that point to the firewall at the main office, or create statics to null0 for rfc1918 address space, then send summary addresses from redistributed statics?

[Jon Marshall · Accepted solution]

Nick

I see what you are saying know, thanks for clarifying.

This is going to be a bit of a long post and i hope i can explain it clearly but if not then please come back. I'm going to assume as per your original diagram that you have a pair of firewalls with the VPNs running active/standby and that they are ASAs.

The main issue is not how you get traffic from the branch sites to the core switch(es) but the firewalls and how they handle routing so i'll concentrate on that as it may also answer your question in the process.

If you have active/standby firewalls then they need to be on a common vlan for failover of the interfaces. If you use EIGRP instead of HSRP the active firewall sees two equal cost paths to both switches (as they are in a common vlan so no L3 hop between switches). But the active firewall is only connected to one switch. This means that some traffic will go to the switch it is connected to but other traffic will be destined for the vlan IP of the second switch ie. the path is via the switch the active firewall is connected to and then across the interconnect to the second switch. This is not necessarily a problem but looking at your original diagram it could mean going across the interconnect to be then routed back across the interconnect to get to a branch office subnet.

This is why HSRP is usually used because it means that in normal operations only the active firewall and active HSRP switch are in use.

So the issue is normally on an ASA you have a default route pointing out of the outside interface to the next hop. Usually the IPSEC VPNs are also terminated on the outside interface so the firewall routes traffic to the outside interface and the crypto map acls pick up any VPN traffic. But you also need routes to the internal subnets. Now if you can summarise your internal subnets for all sites then you are fine but if the 3rd party VPNs are using private addressing which they probably are then it may be that a 3rd party subnet which is not in use within your network actually falls within a summary address you want to use. So traffic would get to the main site and to the firewall but then the firewalll does a route lookup and sees the summary route pointing back to the core switch. So you would need a specific route on the firewall pointing to the outside interface to make sure it gets routed correcty.

So it all depends on your internal addressing and how you want the firewall to learn those routes. You have a number of options -

1) configure statics on the core for the 3rd party VPNs or use three summary addresses for each RFC private range and redistribute into EIGRP. The firewall is not running EIGRP. Assuming all your branch sites and main sites have more specific routes (even if they are summary addresses) for all internal subnets internal routing will work fine and also getting VPN traffic to the core switches.

Using summary ranges rather than specific subnets here is just a matter of personal preference ie. the size of the routing tables.

You would then run HSRP between the firewalls and the core switches. On the firewalls you would have static summary addresses for all the internal networks and they could not overlap with any 3rd party VPN or you would need to then add specific routes for the 3rd party VPNs via the outside interface.

2) run EIGRP between the firewalls and the core switches. For each 3rd party VPN configure a static route pointing to the outside interface and then redistribute into EIGRP. Receive all internal subnets via EIGRP as well so no need for any static summary addresses for the internal subnets.

Obviously as described this would mean that both switches from the firewalls perspective are equal paths so traffic could go to either switch from the firewall and this would mean more use of the interconnect between your switches.

If you do this i can't see the need for HSRP.

3) a sort of hybrid of the above. Run EIGRP and redistribute 3rd party VPN statics into EIGRP but then configure summary routes for the internal networks pointing to the HSRP active IP. These statics would not be redistributed into EIGRP.  You would also filter all EIGRP routes from the core switches as you don't need them.

So with this you are running EIGRP only so the internal network learns of the 3rd party VPN networks but not for the firewalls to learn the internal networks.

As i say a lot depends on your addressing and whether or not it overlaps. If it doesn't then simply using statics on the core switches for the 3rd party VPNs and redistributing into EIGRP and then having static routes on the ASA for the internal networks may be good enough and no need for EIGRP between the switches and the firewalls.  The ASA would then only need the default route for VPN traffic.

The other consideration is from your original diagram remote sites may be coming in via either core switch so the interconnect may be used a lot anyway in which case the EIGRP solution using both core switches may not be such a concern.

Apologies for the rather long explanation but i just wanted to cover how much it depends on your addressing.

If anything is not clear please come back.

Edit - i forgot about Reverse Route Injection (RRI), probably because i have never used it. As i understand it if you configure this it automatically adds routes to the remote VPN networks into the routing table ie. the VPNs do not need to be up. You could then redistribute these into EIGRP so it would save some extra configuration on the firewall.

All you would then need was summary routes for your internal networks and these could actually overlap with the more specific routes for the 3rd party VPNs and it wouldn't matter as long as obviously the same network was not in use both internally and via a VPN. Or if you decide to run full EIGRP both ways between the core switches and the firewalls then no need for any static routes anywhere.

One last point. If you do decide to run full routing between your core switches and the firewalls you may want to keep the routing tables down on the ASA if there are a lot of internal routes by using the "ip summary-address eigrp ..."  command on the core switches to send a summary route to the ASAs.

Jon

[Nick Cutting]

Great Post Jon thank you.  Nothing is too long - I love talking design!

This is probably the simplest approach, and would work.  Thanks !

THis:

1) configure statics on the core for the 3rd party VPNs or use three summary addresses for each RFC private range and redistribute into EIGRP. The firewall is not running EIGRP. Assuming all your branch sites and main sites have more specific routes (even if they are summary addresses) for all internal subnets internal routing will work fine and also getting VPN traffic to the core switches.

Using summary ranges rather than specific subnets here is just a matter of personal preference ie. the size of the routing tables.

You would then run HSRP between the firewalls and the core switches. On the firewalls you would have static summary addresses for all the internal networks and they could not overlap with any 3rd party VPN or you would need to then add specific routes for the 3rd party VPNs via the outside interface.

There shouldnt be any overlap between internal networks and remote 3rd party VPN subnets. And I really do not like large routing tables.

Dont worry about the RRI, I was just using that as an example of the use of routing protocols on the FW, as mostly I prefer static routes on firewalls.  The Reverse routes drop out of the routing table when the VPN is down to the home users.  Then if they had a secondary ip address in the crypto map for another firewall, possbily at another "main" office, the routing is taken care of between the two main sites, and updated along all the partipating eigrp devices.

The actual design for the static route injection, uses both Vti tunnels, 3rd party L2L vpns on ASA's and stacks, but not HSRP. So I was really asking two different questions sorry.  here is the specific topology. No HSRP on any switches - and No dynamic routing between the ASA pair (active standby) and the core at head office.