EIGRP neighbour with HRSP virtual ip address

[eric.guo]

hi all, 

Could someone confirm that we couldn't setup  EIGRP neighbourship with virtual IP address of one HRSP/VRRP group? 

If it is the case, could we have some workaround to accomplish partial routes( hundreds+)  preferred on one advertised router and other routes  preferred on other router at same LAN segment to central core router via EIGRP routing domain? 

thanks, please let me know if possible.

Eric 

[Richard Burts]

Eric

It is true that you can not use the virtual IP address of HSRP for establishing EIGRP neighbor relationship. This is because the multicast packet used to establish neighbor relationship uses the IP address of the physical interface and not the virtual IP address.

I do not understand how that question about using the virtual address relates to the second part of your question which seems to be about how to prefer certain routes for one router and other routes for the other router. But I believe that the answer to the second part of your question would be to use off set lists in the EIGRP configuration. The off set list can add some more delay for the calculation of metric for specified routes and I believe that is what you are asking for.

HTH

Rick 

[eric.guo]

hi Rick, 

thanks for your input.  Yes. using offset is an option. But we have thousands  routes need to be split into different preferred path via two different routers, do we have other way to manipulate the route metric?

 My initial thought was thinking about : create two HSRP group between two WAN aggregation routers, and leverage different adverting source IP address to  accomplish this, but please ignore this un-mature thought, as I maybe  worked on BGP too much before:-)

My topology in the attachment 

My tension is trying to load-balancing some site A and site B traffic  from DC router coming back via WAN1, other site C and Site D traffic returning back via WAN2. 

could you please share with your thoughts ? 

thanks again. 

Eric 

[Richard Burts]

Eric

Thank you for the additional explanation. Could you tell me a bit more about how the remote sites are connected to the WAN aggregation routers?

I had a project for a customer which seems to be pretty similar to what you are trying to do. In this project there were hundreds of remote sites connecting to a pair of routers at HQ and they wanted to do some load sharing/load balancing such that some sites used one head end router and other sites used the other head end router. Trying to control it from HQ would have been extremely complex. But we found that controlling it from the remote site was pretty easy. In this case the remote site used a pair of GRE tunnels (with IPsec encryption) to connect to HQ. We configured an offset list applied to inbound traffic and an offset list applied to outbound traffic on one of the tunnels which added some delay to the routes being advertised on that tunnel. So the remote site learned routes from HQ (actually we advertised just a default route from HQ)  with a better metric on one tunnel. And the remote site advertised its routes to HQ with a better metric on one tunnel. We alternated from office to office whether the offset list was applied to tunnel 1 or to tunnel 2. This worked quite effectively for them and might work for you.

HTH

Rick

[eric.guo]

hi Rick, 

Thanks for sharing this information! 

could I please know why you are using GRE tunne/IPsec between remote and HQ? as we are using lease line between Remote and HQ, I didn't see the benefit if we chose GRE tunnel on my case. 

also could I please know if there is physical link connection between two HQ end routers, or setup a EIGRP neighourship between them? 

and could you mind share some configuration example for remote site as well HQ site?

thanks in advance !

Eric 

[Richard Burts · Accepted solution]

Eric

The reason we chose to use IPsec on the tunnels is that these were connections from remote to HQ over public Internet and we needed to protect the information being sent from remote to HQ. The reason we chose GRE rather than just IPsec is that we wanted to run a dynamic routing protocol between the remote and HQ. Also using GRE tunnels allowed the remote site which has a single interface to outside to establish connection to both WAN routers.

If you have leased lines from remote to WAN router then there would be no benefit in using GRE. Does each remote have two leased lines, one for each WAN router? In that case just run EIGRP on the leased lines and no need for GRE or for IPsec. 

The WAN routers were not EIGRP neighbors with each other as there were multiple hops between them. Each WAN router was neighbor to all remotes using the GRE tunnels to carry EIGRP. Here are parts of the config from a remote router

interface Tunnel1

ip address 10.2.3.162 255.255.255.252

tunnel source 1.1.1.1

 tunnel mode ipsec ipv4

tunnel destination 2.2.2.2

tunnel protection ipsec profile tun_profile

interface Tunnel2

ip address 10.2.3.166 255.255.255.252

tunnel source 1.1.1.1

 tunnel mode ipsec ipv4

tunnel destination 3.3.3.3

tunnel protection ipsec profile tun_profile

router eigrp 100

network 10.0.0.0

offset-list 0 in 1000 Tunnel1

offset-list 0 out 1000 Tunnel1

[eric.guo]

thanks Rick !

[Richard Burts]

Eric

I am glad that my suggestions were helpful. Thank you for using the rating system to mark this question as answered. This will help other readers of the forum to identify discussions with helpful information.

There are two aspects of my solution that may not be very obvious but are important. First was the realization that trying to control the routes at the head end would be very complex because there are lots of routes and trying to construct lists to control preference would be very complicated. But controlling the routes at the remote is much more simple. Second is the realization that using offset-list 0 does not need an access list but applies the offset to all routes learned.

HTH

Rick

[eric.guo]

good to know. 

yes, we realized that is more sense to manipulate the traffic from remote sites. for offsite-list, we will test it in the lab.

may ask you more question along with this task.

thanks again !

Eric