Route-Map / Adjacent Next Hop Question

I have a route-map that is supposed to direct all traffic entering an interface to route out the particular interface connected to our cable modem using NAT. The IP address on the cable modem (used as the NAT inside global IP) is DHCP assigned from the cable system. I don't really know what IP I will get, or what the default gateway is for that subnet. But the cable modem does have a statically assigned ip address 192.168.100.1. So I have been using that as the next-hop in the route map, as well as the next hop in the default route. I have a route statement for 192.168.100.1 directing it to the physical interface, and the modem does answer arp for that IP. Testing seems to show that the route-map is ignored, and the main routing table used instead of the next-hop, but if I manually add the IP address of the default gateway supplied from the cable system (from the DHCP response), then that next-hop is honored. This is only an issue for traffic that has a more-specific route (to a third interface) and wouldn't normally follow the default route without the action of the route-map (like net 10 below).

How can I get the 192.168.100.1 IPA in the cable modem to be accepted by the router/route-map as a valid adjacent next-hop? I've tried various combinations of static routes and subnet sizes. The arp table has the IP resolved, the sh adj command shows that IP too.

Thanks for any help or insights.

- Eric

! interface FastEthernet0/0.12 description Cablevision (SB5100) lan segment encapsulation dot1Q 10 ip address dhcp client-id FastEthernet0/0 hostname JRCCV ip access-group cvrout1 out no ip redirects no ip unreachables no ip proxy-arp ip accounting access-violations ip nat outside ip nbar protocol-discovery no ip mroute-cache no snmp trap link-status no cdp enable ! ! route-map cvdhcpip permit 10 description policy to force all traffic out CV interface match ip address cvdhcp2 set ip next-hop 192.168.100.1 67.83.40.1

Reply to
Eric
Loading thread data ...

I am not sure, but the recursive version of the "ip next-hop" command might be relevant here.

Could you try modifying your route-map as follows -

route-map cvdhcpip permit 10 description policy to force all traffic out CV interface match ip address cvdhcp2 set ip next-hop recursive 192.168.100.1

and see if that helps.

BTW here is the link to the PBR recursive next-hop feature

formatting link
Cisco da Gama
formatting link

Reply to
ciscodagama

The next hop should not be the cable modem IP address, it should be the IP address of the ISP's upstream router. While the address assigned by DHCP to your router may change, the upstream ISP address will only change if the ISP does a cable segment split.

DHCP will assign your router's an IP address that sits on the same IP subnet as the ISP upsteam address. You must verify this by looking at the DHCP address, its mask and the upsteam address. If it is not obvious that they are there are a number of IP addresss utility that can be used to figure this out

Once you router has an DHCP address assigned, issue a sh ip route command for the upstream IP address to ensure that you router know that fa 0/0.12 is the egress interface - sh ip route 67.83.40.1

Given that the ISP upstream IP address is 67.83.40.1, then

route-map cvdhcpip permit 10 description policy to force all traffic out CV interface match ip address cvdhcp2 set ip next-hop 67.83.40.1

no ip route 0.0.0.0 0.0.0.0 FastEthernet0/0.12 192.168.100.1 90 no ip route 192.168.100.1 255.255.255.255 FastEthernet0/0.12 40 permanent no

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0.12 67.83.40.1

Reply to
Merv

On 13 Feb 2006 14:41:50 -0800, " snipped-for-privacy@gmail.com" wrote for the entire planet to see:

I tried it. Isn't doesn't seem to be supported at my IOS level

12.3(15a):

JRC-C2620-U7(config)#route-map cvdhcpip JRC-C2620-U(config-route-map)#set ip next-hop recursive 192.168.100.1 ^ % Invalid input detected at '^' marker.

The Cisco doc you cited says: The PBR Recursive Next Hop feature enhances route maps to enable configuration of a recursive next-hop IP address that is used by policy-based routing (PBR). The recursive next-hop IP address is installed in the routing table and can be a subnet that is not directly connected. If the recursive next-hop IP address is not available, packets are routed using a default route.

Because Cisco Express Forwarding (CEF) or process switching provides the infrastructure, the benefit of this feature is the CEF load sharing.

Feature History for the PBR Recursive Next Hop Feature Release Modification

12.0(28)S This feature was introduced. 12.3(14)T This feature was integrated into Cisco IOS Release 12.3(14)T.

What I don't get is, I think the 192.168.100.1 *is* on a directly connected segment. The problem is that I can't assign that subnet to the interface, even as a "secondary", because then the interface IP DHCP statement goes away. So second best is a static route associating it with the interface, but maybe that doesn't satisfy route-map. So then recursive would be just what I want, except that it seems to need 12.3(14)T to be supported, and I think my 2620 isn't supported at 12.3T or 12.4. So I can't get that feature without a new router.

Thanks for the pointers in the right direction.

- Eric

Reply to
Eric

The cable modem IP address should not be used.

The cable modem should be "transparent" with respect to IP routing to your ISP

Reply to
Merv

On 14 Feb 2006 03:26:20 -0800, "Merv" wrote for the entire planet to see:

Thanks for the good advice. I was trying to get a config that didn't require any manual changes even if the DHCP response changed significantly, but this will have to do.

Oddly enough, last night they did perform some type of cable split on our segment at about 12:10am. We lost connectivity beyond the cable modem and the Cisco IOS 12.3(15a) DHCP service was unable to renew/replace its lease. I had to manually toggle the interface to get a working dhcp lease this AM.

I have a sniffer log of the period when connectivity was lost and then recovered, and my first take is that the IOS DHCP process was trying to reach the dhcp server where the original lease came from, but after the cable system maintenance that wasn't a dhcp server anymore, or not reachable, or not responding to my new subnet, and IOS never went back to a simple DHCP broadcast to find a new server and get a new address in the new subnet. That is a bit annoying.

The "sh dhcp lease" command showed it in state 5 (renewing) all night long, IIRC, and immediately after the interface reset it went to State

3 (Bound). The IP address is now different, and the dhcp server address is different, and the default gateway returned is different too.

JRC-C2620-U7#sh dhcp lease Temp IP addr: 67.81.xxx.xx for peer on Interface: FastEthernet0/0.12 Temp sub net mask: 255.255.240.0 DHCP Lease server: 167.206.245.17, state: 3 Bound DHCP transaction id: 136Axxxx Lease: 302400 secs, Renewal: 151200 secs, Rebind: 264600 secs Next timer fires after: 1d16h Retry count: 0 Client-ID: 0009.ecec.aca1 Hostname: JRCCV JRC-C2620-U7#

The DHCP process seems to put this entry in the routing table:

167.206.0.0/32 is subnetted, 1 subnets S 167.206.245.17 [254/0] via 67.81.224.1, FastEthernet0/0.12

Which is basically telling my router how to reach the dhcp server; through the default gateway for the new segment.

So now my route-map reads:

JRC-C2620-U7#sh route-map route-map cvdhcpip, permit, sequence 10 Match clauses: ip address (access-lists): cvdhcp2 Set clauses: ip next-hop 67.81.224.1 Policy routing matches: 97 packets, 11874 bytes JRC-C2620-U7#

This will be OK until another reconfig of the cable system, at least a few months I hope.

Reply to
Eric

I am not aware of any feature that Cisco provides that would allow you to dynamically configure the policy-based routing next-hop via a DHCP-assigned gateway address which is what would be required.

It is interesting that the DHCP server inserted a static route to the DHCP server. I have not seen this before.

Reply to
Merv

On 14 Feb 2006 07:51:46 -0800, "Merv" wrote for the entire planet to see:

I agree with you, but then what is the correct way to target a route-map if you want the traffic to go out the interface with the DHCP-assigned address and not have any dependencies on their topology (which may change)?

The IP address in the modem was the only thing I had to hold on to, but I do see it's shortcomings, and I can't get it to work properly anyway. Thanks for the tips.

- Eric

Reply to
Eric

I have a couple of suggestions for you. I have almost the same configuration even down to the cable split. One very simple fix that you can try that may or may not fix your problem (depending on ISP) is to specify your ISP's DHCP server in the config. From my experience, most of the time when you do this, you won't suffer those disconnects when your ISP issues you a new IP in a different subnet. Because you've specified the DHCP server in the config, the router will only receive DHCP replies from that server. When I made this change, I essentially had a static IP address from that point on as I kept renewing the same IP address from the DHCP server I had specified. The only time my address ever changed was after an extended power outage when the DHCP server had already issued "my" ip address to another client. As for routing, you can actually specify DHCP as a gateway address in your route statement if you have a fairly recent IOS version (not sure what ver they implemented this). For example, on my router I use the following default route statement but you can adjust it to meet your needs:

ip route 0.0.0.0 0.0.0.0 dhcp 10

What this does is automatically sends traffic out the gateway address provided by your ISP as seen in the "sh dhcp lease" output. The key to this config is that IOS automatically manages the routing table and will update it as needed. You don't need to know anything about the upstream router or the transparent IP on the cable modem.

I'd be happy to post my config (just need to anonymize it) if you'd like to see specifics. In this same config I also use PBR to blackhole unwanted traffic to a Null interface. The concept is close in principle to what you're trying to do here....

Reply to
Cisco

This is very interesting info !

Yes, please post your config.

With the info you provided I decided to some additional surfing on CCO regarding new DHCP-related features

And I think the OP will be interest to look at the following 12.3T feature !!!

I had earlier indicated that I did not think there was an IOS feature to do this.

set ip next-hop dynamic dhcp

To set the next hop to the gateway that was most recently learned by the Dynamic Host Configuration Protocol (DHCP) client, use the set ip next-hop dynamic dhcp command in route-map configuration mode. To restore the default setting, use the no form of this command.

set ip next-hop dynamic dhcp

no set ip next-hop dynamic dhcp Syntax Description

This command has no arguments or keywords. Defaults

This command is disabled by default. Command Modes

Route-map configuration Command History Release

Modification

12.3(2)XE

This command was introduced.

12.3(8)T

This command was integrated into Cisco IOS Release 12.3(8)T.

Usage Guidelines

The set ip next-hop dynamic dhcp command currently supports only a single DHCP interface. If multiple interfaces have DHCP configured, the gateway that was most recently learned among all interfaces running DHCP will be used by the route map. Examples

The following example configures a local routing policy that sets the next hop to the gateway that was most recently learned by the DHCP client:

access list 101 permit icmp any host 172.16.23.7 echo

route map MY_LOCAL_POLICY permit 10

match ip address 101

set ip next-hop dynamic dhcp

!

ip local policy route-map MY_LOCAL_POLICY

Related Commands

Reply to
Merv

Hi Cody -

I'd like to see your config, just for ideas.

I tried the "dhcp" option on my static route. It was accepted, but it doesn't seem to take effect. My static route with AD of 90 is still in the routing table, and the ones I created with DHCP are at AD 40 and 50, but not in the routing table.

#sh run ip route 0.0.0.0 0.0.0.0 FastEthernet0/0.12 192.168.100.1 90 ip route 0.0.0.0 0.0.0.0 FastEthernet0/0.12 dhcp 40 ip route 0.0.0.0 0.0.0.0 dhcp 50

#sh ip route ... 167.206.0.0/32 is subnetted, 1 subnets S 167.206.245.17 [254/0] via 67.81.224.1, FastEthernet0/0.12 192.168.100.0/29 is subnetted, 1 subnets S 192.168.100.0 is directly connected, FastEthernet0/0.12 S* 0.0.0.0/0 [90/0] via 192.168.100.1, FastEthernet0/0.12

Even when I get that working, that really wasn't the main problem. Somehow my default route pointing to 192.168.100.1 works, but in a route-map as a next-hop it does not. It's really the route-map case I want to perfect. Merv's suggestion of using the upstream gateway, configured manually, is still my only working solution.

Thanks for the help and ideas.

- Eric

Reply to
Eric

On 14 Feb 2006 10:47:23 -0800, "Merv" wrote for the entire planet to see:

Now all I have to do is get 12.3T onto my 2620. :)

Alternatively, I guess a still-supported 3640 with 12.3T or 12.4 would suffice.

- Eric

Reply to
Eric

Now there is a challenge ...

Reply to
Merv

I'm glad I stumbled onto this thread because this is almost exactly what I'm trying to implement. I have DSL and cable at home. I'm trying to use a route-map to match tcp port numbers to dump traffic onto the cable line. I too have a low-end 2600 (a 2621 to be exact). I'm not sure if I can get a 12.3T running on it either. I have a 2621 and a 2620 to play with at the moment. If anyone has any ideas on this I'd love to hear them. I'm pulling DHCP on the cable sub-int but not on the DSL int. I had to stick a Linksys (soon to be my Pix 520) on the DSL line to handle the PPPoE (because I can't run Advanced Enterprise to get pppoe-client support).

J
Reply to
J
12.3T will definitely not fit onto a 2621
Reply to
Merv

I'm going to see if I can pick up a 2821 at our partner NFR price. I'm tired of trying to work around the shortcomings of my 2600s. First PPPoE and now this... :-)

Thanks J

Reply to
J

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.