Equipment Support > Hardware By Brand > Cisco > [HELP] Usage of IP Verify Unicast cmd

[HELP] Usage of IP Verify Unicast cmd

R1811#sh run int fa0
Building configuration...
Current configuration : 402 bytes
!
interface FastEthernet0
 description "WAN - ISP"
 ip address dhcp
 ip access-group INBOUND_ACL in
 ip verify unicast source reachable-via rx allow-default
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip inspect INBOUND_FW in
 ip inspect OUTBOUND_FW out
 ip virtual-reassembly max-fragments 3 max-reassemblies 64 timeout 1
 duplex auto
 speed auto
 no cdp enable
end
 

Several thoughts, first is the simplest: How are you learning the default? Do you have a 0/0 static --> modem or are you not learning default until DHCP is complete? Are the DHCP replies coming from the ISPs DHCP server? Can you slap a sniffer on the interface and wireshark the DHCP exchange to see what the deal is for me?
Hit me up on skype if you have a PCAP file for me to peek at =)

reply to HELLFIRE
I've found uRPF to be rather useless on CPE routers. You've noticed the first problem... preventing dhcp from working. Ultimately, "allow-default" renders the technology moot as it will match anything that isn't local.

That said, to get the RFC1918 blocks filtered without putting them in an ACL, you have to have null routes to those blocks. uRPF would then block them inbound; the route entires themselves would block them outbound (which means you really don't need to filter them inbound.) And, of course, this will prevent DHCP from working with many ISPs since the reply often comes from the range you're blocking. I recall a configuration option to fix that, but I don't have it in any of my configs. (having long ago turned off uRPF)

reply to HELLFIRE
The ip verify unicast command basically verifies the routes according to routing table. As example, the command denies attempts to have router interfaces IP address to be 0.0.0.0 since it is considered invalid. Unfortunately with DHCP, such consideration is breaking DHCP mechanism since DHCP requires the router interface that acts as DHCP client to have 0.0.0.0 IP address before DHCP server approves the DHCP request to provide actual working IP address. In other words, DHCP client router and ip verify unicast command do not mix.

reply to HELLFIRE

isp dhcp debugs.txt 72,842 bytes ISP DHCP Debug log

You forgot 172.16.... (and multicast)

I could'a swore Cisco's docs did say it would interfere with DHCP, but I'm remembering decade old docs. That said, uRPF was designed for the ISP, full-BGP-table-having crowd. It really doesn't do much for a CPE, plus their needs are small enough that an ACL is a quick, simple solution. ('tho, it does mean you have to maintain the acl.)

reply to HELLFIRE

reply to HELLFIRE
@cramer
Guess what IP range I use for my internal LAN...

@aryoba
already did the debug, and yeah, had a reload again last night after I posted the output,
the interface to the ISP came up and grabbed an IP address again, no problems.

Thanks all.

Regards

reply to HELLFIRE
On a sidenote, is it worthwhile to pull a static null to the rest of the 172.16.0.0/12 network,
but have an admin distance of 200+, even when I've only got the following subnets configured?

ie "ip route 172.16.0.0.0 0.0.15.255 200"

R1811#sh ip ro 172.16.0.0
Routing entry for 172.16.0.0/24, 4 known subnets
  Attached (4 connections)
C       172.16.30.0 is directly connected, Vlan30
C       172.16.20.0 is directly connected, Vlan20
C       172.16.10.0 is directly connected, Vlan10
C       172.16.0.0 is directly connected, Vlan1
 

Hey HF, i have a question. If you add a static route toward your modem interface for the /32 address of your ISPs DHCP server, does that resolve the DHCP RFP issue? Ping me on skype or something, i want to see if we can make it work.

reply to HELLFIRE
Yes, because anything not explicitly in the table matches the default route. And the correct syntax:
ip route 172.16.0.0 255.240.0.0 Null0 254 permanent
(metric and permanent are up to you.)

I don't have a 10/8 null route specifically because of uRPF issues, TWC uses them, I use them , and my employer uses them (ipsec).

reply to HELLFIRE
@nosx
I'll see if I have some time this weekend upcoming to give that a shot.

@cramer
Thanks for the input... and the correction. What happens when you add lack of sleep
and not thinking things through

Regards