Cable source-verify dhcp clarification. How it works !!!
Cable-source-verify is a feature where the CMTS will watch the DHCP packets going by and only allow IP packets to flow to clients for which it has seen an IP address be assigned by DHCP. It keeps an internal table (internal to the CMTS) of which clients are allowed to use which IP addresses.
This basic code works independently of leasequery. Let me say that again -- this basic code does *not*, repeat *not* require leasequery to work. It is implemented entirely within the CMTS. Leasequery comes into play *after* the CMTS has been rebooted and has cable-source-verify enabled. At that point, it doesn't know which clients go with which IP addresses, and will prevent *anything* from happening (except DHCP transactions). So,
nothing works at that point -- except that the CMTS will use leasequery requests to the DHCP server to see if the DHCP server knows something about a client that the CMTS does not. And so, over time, the CMTS will rebuild its internal table by using leasequery requests, and everything will operate correctly. So, it is perfectly reasonable that you can have a CMTS which will prevent a device which has not done a DHCP transaction from
using an IP address even if you are using a DHCP server which is not CNR (or, more accurately, which does not support leasequery). The best way to configure CMTS is using “no cable arp” and “cable source-verify dhcp”. When you configure both, you are basically telling the CMTS that the only means of resolving the IP address is via DHCP. “Arp timeout” should be set to reasonable value. After arp timeout CMTS will delete CPE from the database. Now if there is a packet for or from cpe on cmts, the CMTS will send leasequery to dhcp server for revalidation and once the dhcp reply is received from the dhcp server,c pe will back in the database. The CMTS can send out DHCP LQ under several scenarios.
1. CMTS receives a packet from a CPE in the US with an IP address that is not in the CMTS database.
2. CMTS receives a packets to be sent to an IP address that is not available in the database. Now if "no cable arp" is configured, the CMTS sends out DHCP LQ in order to resolve this IP address.
3. When leasetimer feature is enabled and when LQ timer is expired. However these are not filtered via the leasequery-filter. The CMTS knows about the leasetime since it snoops the DHCP packets for the CPEs.
When you have just "cable source-verify" configured, the CMTS just relies on what it learns from DHCP to determine whether the source is authentic or not (And ARP if ARP is not disabled). It does not pro-actively send DHCP LQ to learn about hosts.
Note that some servers *other* than CNR support the Cisco legacy version of leasequery.
There are two forms of Leasequery, the Cisco legacy version and the RFC4388 version. The Cisco legacy version has been in the
product for at least 5 years, and will continue to be supported for as long as CNR is a product. The RFC4388 version has been supported since CNR 7.0 was released, 12/27/2007. It too will be supported essentially forever. To the best of my knowledge, Cisco IOS devices today use the
Cisco legacy version of leasequery, and I have no idea when (or if) they plan to change. It doesn't matter, because either are supported.
FAQ:
Q1: When both "cable source verify dhcp" and "cable arp" are configured. In this scenario when a packet needs to be sent to or is received from an unknown IP which takes precedence, the lease query or the arp?
A-For a packet coming from an unauthorized source, in the US direction, we always use DHCP LQ when "dhcp" option is used. ARP has no say here.
It is only in the DS direction that ARP makes difference. If "cable arp" is enabled and CMTS sees a packet destined to unknown destination address, then the CMTS uses ARP to resolve the address. So, to answer your question, ARP takes precedence.
Q2: I am seeing following in my CMTS,
CMTS#show cable leasequery-filter
Lease Query Filter statistics for Unknown Sid
Requests Sent : 0 total. 0 unfiltered, 0 filtered
Is that normal?
A2: I know that you claim that "cable source-verify dhcp" is enabled. But please verify it on this CMTS. I doubt if it is enabled.
Anyway, what you are seeing here is the number of DHCP LQs that were sent as a result of a DS packet to an un-authorized IP address. This should count up when "cable source-verify dhcp" is configured. If you want at the SID level, try "show cable leasequery-filter <interface> requests-filtered"
Q3 : How to prove that cmts have send out lease query packet? Does the command " show cable leasequery-filter " can check it while customer do not config lease query filter? I have suggest customer to config downstream filter and upstream filter, but they still can not find "requests send" counter increase at this command.
A3 : What release are you using? I don’t know if the lease query filter is enabled by default with some values. I can check when you tell me the release information.
Q4: If dhcp server do not send lease query ack packet to cmts, what will cmts do next?
A4: If the CMTS does not hear from the server, it will keep sending the DHCP LQ. This is where the leasequery-filter comes into play and drop excessive requests.
Q5 : Customer use some cnr and some other dhcp server, how to make sure that customer's dhcp server support lease query reply? I means maybe some other brand dhcp server may only support RFC4388 and do not support Cisco legacy version.
A5: You may need to consult the technical documentation of the 3rd party DHCP server to see what form of DHCP LQ does that support.
Q6 : As far as we understand, this is a way to prevent unauthorized IP addresses (including the ones statically set by the subscribers) from accessing the network. It is accomplished by the CMTS sending DHCP Lease-Query to CNR and with appropriate response, the traffic from the subscriber is allowed to be forwarded. In any case this mechanism and/or message format does not follow the standard. What RFCs or standards do we follow in our Lease-Query messages?
A6 : The behavior is defined by RFC 4388. But we don t support that yet. We support the behavior that was specified in an earlier draft.
Q7.1: Even without the DHCP server responding to the Lease-Query, the subscriber can be allowed to access the network?
Q7.2: If the customer is using a non-CNR DHCP server which do not support Lease-Query responses... and the subscriber can access the network? Cable source-verify dhcp is enabled in this scenario.
A7 : No. If dhcp server do not respond to LQ, cmts will keep on sending it and the subscriber will not get access to the network.
