cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2003
Views
5
Helpful
11
Replies

GRE and HSRP

Hi Community,

Since I don't have real routers with me, I need a working example of GRE tunnel terminating on HSRP Virtual IP on IOS.

Almost all examples I read, show it cannot be done and if I try an emulator it does not work (GRE and IGP works fine if terminating on physical interfaces but not on the virtual IP).

I need the GRE tunnel terminating on the HSRP VIP for HA and and IGP running thorugh.

So, could someone please share a working example or a link showing it works?

Thank you,

Federico. 

5 Accepted Solutions

Accepted Solutions

Here's what I see:

I have 3 routers: A, B, and C:

A:

Real ip: 192.168.12.2

vIP: 192.168.12.1 (priority 105)

tunnel:

     ip: 10.10.10.1

     src: 192.168.12.1

     dst: 192.168.12.50

B:

Real ip: 192.168.12.3

vIP: 192.168.12.1

tunnel:

     ip: 10.10.10.2

     src: 192.168.12.1

     dst: 192.168.12.50

C:

Real ip: 192.168.12.50

tunnel:

     ip: 10.10.10.3

     src: 192.168.12.50

     dst: 192.168.12.1

What I see is that the tunnel comes up between A and C. I can ping A's tunnel address (10.10.10.1), but the tunnel never comes up on Router B unless I failover A by shutting down the fa0/0 interface. The tunnel fails on C, and then comes back up on the other side. So technically it can be done, but I don't think it's any better than just creating a single tunnel from C -> A and C-> B on their real addresses. If you use a routing protocol like eigrp that can hold a backup route, you shouldn't have any significant downtime should one router go down.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

View solution in original post

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

But my question is what about either router member of the HSRP group failing or going down? 

That's going to disconnect the remote site until IGP reconvergence, a problem that could be avoided by a maintaining an always up IP as the VIP (as long as either router is up) correct?

HSRP takes time to switch over, so unsure it will be better than an IGP's convergence.  Of course, HSRP can be tuned for faster failover, and most IGPs can be tuned for faster convergence too.

View solution in original post

Federico,

You can get a neighborship over the tunnel:

Router A:

R1(config)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.3              Tu1               11 00:01:13   69  5000  0  3

Router C:

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.1              Tu1               12 00:00:38   77  5000  0  3

Notice that Router B (R2) doesn't have anything because the tunnel isn't up:

R2(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

R2(config-router)#

R2(config-router)#do sh ip int brie

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            192.168.12.3    YES manual up                    up

FastEthernet0/1            unassigned      YES unset  administratively down down

Tunnel1                    10.10.10.2      YES manual up                    down

If I shut down R1's hsrp interface, R2 will come up and form a neighborship with R2:

Router A (R1)

R1(config-if)#shut

R1(config-if)#

*Mar  1 00:06:47.479: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Init

R1(config-if)#

*Mar  1 00:06:49.487: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down

*Mar  1 00:06:50.487: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

R1(config-if)#

Router B (R2)

Tunnel1                    10.10.10.2      YES manual up                    up

R2(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.3              Tu1               12 00:00:30   69  5000  0  5

And now R3 will show the neighbor with R2 and not R1 any longer (that's also because the interface is down on R1 obviously):

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.10.10.2              Tu1               11 00:01:24   52  5000  0  3

If I bring R1 back up, R3 reconnects to it:

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.1              Tu1               13 00:00:16   80  5000  0  6

It seems as though the tunnel interface will always prefer the active hsrp member for the vIP, but it is possible to terminate the tunnel to the vIP.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

View solution in original post

I would still go with two separate tunnels. The reason is that both can be up at the same time and your convergence would be faster as Joseph stated above. From what I was seeing, your router would completely disconnect and have no tunnel up for at least a second when hsrp converged. The convergence would be faster with two separate tunnels and tuned igp vs hsrp and the vip.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

View solution in original post

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

As John notes, if you only have one tunnel, and HSRP converges, all traffic will be blocked, whereas with two tunnels, and something like ECMP, at least some traffic will continue.

As far as convergence time, it might be a wash if your HSRP version supports subsecond timers and/or BFD.  In fact, if you use mHSRP, you could have two tunnels, one to each device, and each device being a backup for the other's tunnel.  I've done that (w/o the tunnels) for static routing on a shared LAN segment.

Using HSRP just feels wrong when you're using an IGP, but if it works, I cannot think of any other good reasons not to use it (beyond it's an unusual solution which can "surprise" someone else needing to work an issue - and as such, unless there's really a superior reason for using it, it's probably better to use the "expected" solution).

View solution in original post

11 Replies 11

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

That may not be possible.  If you have an IGP, why not have two tunnels, each to physical device interfaces?

HSRP is a FHRP, it's wasn't intended to terminate IGP end points.

Yes agree.

But my question is what about either router member of the HSRP group failing or going down?

That's going to disconnect the remote site until IGP reconvergence, a problem that could be avoided by a maintaining an always up IP as the VIP (as long as either router is up) correct?

Thank you,

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

But my question is what about either router member of the HSRP group failing or going down? 

That's going to disconnect the remote site until IGP reconvergence, a problem that could be avoided by a maintaining an always up IP as the VIP (as long as either router is up) correct?

HSRP takes time to switch over, so unsure it will be better than an IGP's convergence.  Of course, HSRP can be tuned for faster failover, and most IGPs can be tuned for faster convergence too.

John Blakley
VIP Alumni
VIP Alumni

I agree with Joseph. You should create two separate tunnels to each router. You can manipulate the bandwidth, max paths, etc, if you only want one route in your table, but it's the preferred way to do it.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

Yes I know. Thank you both.

I'm not saying that you should configure a single GRE tunnel to the HSRP IP instead of a single tunnel to each router as a best practice. I agree.

The only thing I'm asking is if technically it will work?

And the reason why, is because I don't have my hands on equipment at the moment to test it out myself and I'm looking at a configuration working in that way (single GRE terminating on HSRP Virtual IP).

Federico.

Here's what I see:

I have 3 routers: A, B, and C:

A:

Real ip: 192.168.12.2

vIP: 192.168.12.1 (priority 105)

tunnel:

     ip: 10.10.10.1

     src: 192.168.12.1

     dst: 192.168.12.50

B:

Real ip: 192.168.12.3

vIP: 192.168.12.1

tunnel:

     ip: 10.10.10.2

     src: 192.168.12.1

     dst: 192.168.12.50

C:

Real ip: 192.168.12.50

tunnel:

     ip: 10.10.10.3

     src: 192.168.12.50

     dst: 192.168.12.1

What I see is that the tunnel comes up between A and C. I can ping A's tunnel address (10.10.10.1), but the tunnel never comes up on Router B unless I failover A by shutting down the fa0/0 interface. The tunnel fails on C, and then comes back up on the other side. So technically it can be done, but I don't think it's any better than just creating a single tunnel from C -> A and C-> B on their real addresses. If you use a routing protocol like eigrp that can hold a backup route, you shouldn't have any significant downtime should one router go down.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

John that's what I was looking for. Thank you.

If I may ask you one more thing, could you establish an IGP relationship between Router C and the other two router's virtual IP?

Federico.

Federico,

You can get a neighborship over the tunnel:

Router A:

R1(config)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.3              Tu1               11 00:01:13   69  5000  0  3

Router C:

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.1              Tu1               12 00:00:38   77  5000  0  3

Notice that Router B (R2) doesn't have anything because the tunnel isn't up:

R2(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

R2(config-router)#

R2(config-router)#do sh ip int brie

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            192.168.12.3    YES manual up                    up

FastEthernet0/1            unassigned      YES unset  administratively down down

Tunnel1                    10.10.10.2      YES manual up                    down

If I shut down R1's hsrp interface, R2 will come up and form a neighborship with R2:

Router A (R1)

R1(config-if)#shut

R1(config-if)#

*Mar  1 00:06:47.479: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Init

R1(config-if)#

*Mar  1 00:06:49.487: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down

*Mar  1 00:06:50.487: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

R1(config-if)#

Router B (R2)

Tunnel1                    10.10.10.2      YES manual up                    up

R2(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.3              Tu1               12 00:00:30   69  5000  0  5

And now R3 will show the neighbor with R2 and not R1 any longer (that's also because the interface is down on R1 obviously):

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.10.10.2              Tu1               11 00:01:24   52  5000  0  3

If I bring R1 back up, R3 reconnects to it:

R3(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.10.10.1              Tu1               13 00:00:16   80  5000  0  6

It seems as though the tunnel interface will always prefer the active hsrp member for the vIP, but it is possible to terminate the tunnel to the vIP.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

Now John/Joseph,

Since you verify that the GRE tunnel and the IGP can both terminate on the vIP, then what do you think about recovergence time?

Two GRE tunnels one to each router real IP and tune IGP to reconverge vs. Single GRE tunnel with single IGP neighborship and tune HSRP?

I guess my question is in which scenario will be less interruption if something fails?

Federico.

I would still go with two separate tunnels. The reason is that both can be up at the same time and your convergence would be faster as Joseph stated above. From what I was seeing, your router would completely disconnect and have no tunnel up for at least a second when hsrp converged. The convergence would be faster with two separate tunnels and tuned igp vs hsrp and the vip.

HTH,
John

*** Please rate all useful posts ***

HTH, John *** Please rate all useful posts ***

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

As John notes, if you only have one tunnel, and HSRP converges, all traffic will be blocked, whereas with two tunnels, and something like ECMP, at least some traffic will continue.

As far as convergence time, it might be a wash if your HSRP version supports subsecond timers and/or BFD.  In fact, if you use mHSRP, you could have two tunnels, one to each device, and each device being a backup for the other's tunnel.  I've done that (w/o the tunnels) for static routing on a shared LAN segment.

Using HSRP just feels wrong when you're using an IGP, but if it works, I cannot think of any other good reasons not to use it (beyond it's an unusual solution which can "surprise" someone else needing to work an issue - and as such, unless there's really a superior reason for using it, it's probably better to use the "expected" solution).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: