how to understand 'ip next hop recursive' ?

Unanswered Question
Nov 19th, 2011

Dear Community,

with regards to my recent post 'https://supportforums.cisco.com/thread/2116099?tstart=30' Proxying traffic through VPN/GRE tunnel,

I found the feature to use 'ip next hop recursive'  inside a route-map declaration.

Cisco explains this feature to route traffic to a particular host which is NOT in the same subnet or seems to be more far away then just one hob.

Actually I am not sure whether I don't get that right in reason of an English language gap or if the explanation of the next hob recursive

facility indeed a bit insufficient.

Unfortunately I was not able to figure out, if the order of the next hop declaration matters or not.

my question simply is, if the first command inside a route-map section is

     set ip next-hop 1xx.xxx.xxx.xxx

and the second:

     set ip next-hop recursive 2xx.xxx.xxx.xxx

what happens in case the first ip (starting with 1) is not available?

will the router then mind the first IP and try to reach the first ip involving recursiv from the second?

What should be the recursive IP address? The address of the host I try to reach or the "real" address of

the hop that routes to?

this confuses me a lot.

I try to forward http traffic from one network through a VPN tunnel to a proxy server behind the vpn.

I have the following setup at present:

Host 172.16.16.2 -> | <- 172.16.14.2=VPN Dest. ------  172.16.14.1=VPN Source-> | <-- 172.16.15.2=Proxy -----> Internet

a trace from the Host site router (172.16.16.1) shows me 2 hops:

172.16.14.1

172.16.15.2

the word 'hop' makes me wondering as I do understand it as a kind of routing node, thus a "hand over point" from one network to the next.

In my eyes it would make sense, to define the proxy address with 'set ip next-hop' and if this can't accessed directly it will then tried to

reach over the 'real hop ip' declared with 'set ip next-hop recursive' what in my case would be the source of the VPN tunnel: 172.16.14.1.

I really appreaciate any help & advise in order to light up my minds - as I am struggling to get this running since 5 days.... :-(

thank you in advance & all the best!

David.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Giuseppe Larosa Sun, 11/20/2011 - 07:42

Hello David,

the option recursive is mentioned in the command reference

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/command/iri-cr-s1.html#GUID-72CDBB9D-A107-43DD-B8F9-3540255299C9

but there is no explanation of what is the meaning of recursive in the networking context.

My understanding is the following:

without the recursive keyword you have to point to an IP address that is directly connected

the recursive keyword should tell the router to forward the traffic in the same way as it is forwarded when sent to a destination = the recursive destination

my notes:

I don't think you can use set ip next hop and set ip next-hop recursive in the same route-map block/clause, I'm afraid second command may override the first one.

you can use set interface tunnel xx where tunnel xx is the GRE tunnel it should be the easiest option

you need also to provide the return path from ISP POP  to the multi tenant customer site in that case you can easily match on the two private class B networks you are using if NAT is performed on the squid proxy.

Hope to help

Giuseppe

dese.co.uk Sun, 11/20/2011 - 07:59

Dear Guiseppe,

thank you very much for your invaluable advises.

Indeed the Cisco ip next-hop documentation under PBR outlines, that your can set ip next-hop and the recursive in one

and the same route-map.

I am not shure if I will really need an extra NAT statement on the ISP site as we have anyway the squid on the private network running under port 80.

So far I have conducted many tests in any variation, under no circumstane I will get just a single packet through the tunnel from the route-map to the squid, though I can ping all the nets from both ends through the tunnel.

having very concentrated reviewed the firewall log on my workstation, I see that the browser makes a correct DNS request through the tunnel to the dns server on the other site and then tries to connect directly to the target.

What I want to say is, that even the route-map and as well the access-lists count up, but no pack reaches the other site.

I know that precisely my issue was discussed here earlier but I see, that there was never found a solution to end up

with a proper working route-map.

If you have still an Idea, your advise is more than appreciated.

thanks & all the best.

David.

Giuseppe Larosa Sun, 11/20/2011 - 08:21

Hello David,

set ip next-hop and set ip next-hop recursive should be supported in the same route-map clause as explained in the command reference

see

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/configuration/12-4t/iri-pbr-rec-next-hop-support.html#GUID-9CCE0CBF-2983-4F81-9A8B-78FC621725AE

however, I don't see the need for recursive in your scenario as I have noted you should be able to point to tunnel GRE by interface name (  tunnel xx) in your route-maps used for PBR.

At the other site you should have a default route  pointing to the squid box to complete the upstream path.

the squid box need a static route for the two class B networks to the C3825 interface. You can use a routing protocol over the GRE tunnel to advertise the two class B subnets.

the GRE traffic has to be encrypted by IPSec and you find examples of this in the CCO site.

Hope to help

Giuseppe

dese.co.uk Sun, 11/20/2011 - 08:48

Dear Guiseppe,

thanks for your reply.

On the other end the squid box is directly (physically) connected to the router.

using dyn. routing protocol eigrp or ospf I end up in a strange behavor of the systems

as I then can only ping from one site through the tunnel what is from the customer's site.

so I have made static route entries on every site.

set interface Tunnel 0 does not change anything.

Thanks & Best Regards!

David.

dese.co.uk Sun, 11/20/2011 - 12:03

Dear Guiseppe,

over the day again I have conducted several tests with the route-map and next hop facility.

I had 3 different Cisco routers to hand, each with IOS 12.4 minimum:

C3640, C3660, C3745

I can now confirm that the next-hop facility under NO circumstances work, even if the next hop is in the same network and

EVEN if the proxy is directly connected to the router performing the hop.

something must be seriously wrong - I am not sure having read anywhere that on some IOS this facility is configurable but

the hop-route is never performed.

On some cisco devices the hop-routing demands 'sdm prefer routing' but it is not available on my test-routers.

After all these days spent indeed I am no longer wondering why so many people struggle to get this running.

Maybe Cisco has implemented a facility which never work? I don't know.

Maybe you have now a final advise as I feel now a little bit lost.

Best Regards,

David.

Actions

Login or Register to take actions

This Discussion

Posted November 19, 2011 at 12:31 PM
Stats:
Replies:5 Avg. Rating:5
Views:1216 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,155
3 7,745
4 7,088
5 6,742
Rank Username Points
140
80
78
64
40