Re: IP Device Tracking New CLI - SISF - Denali 16.3.5

Florian P · ‎12-21-2017

Coming along Denali 16.3.5b, the IP Device Tracking has been reworked.

I would like to know if it is still possible to use non RFC compliant ARP request with the following command :

ip device tracking probe use-svi (deprecated CLI)

And if it is still possible to delay 1st ARP request using the following command to avoid having Duplicate IP on Windows endpoints :

ip device tracking probe delay (deprecated CLI)

I tried using this document https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/16-1/configuration_guide/b_161_consolidated_3650_cg/b_161_consolidated_3650_cg_chapter_01001010.html#concept_A4AB227AC35840A1ACE51453EDBACD3E but the commands given are not avalaible (device-tracking policy reachable-lifetime)

Moreover has someone already been using the security features in SISF ?

Best regards.

Kblaursen · ‎01-02-2018

We are using it to great extend, but have a lot of issues with STALE's and BAD_ADDRESS(DHCP).

We have tried tweaking it with "device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0 override", but we are still have problems.

The closest thing to device-tracking policy reachable-lifetime i have found is under the device-tracking policy creation.

Example:

device-tracking policy device_tracking
tracking enable reachable-lifetime 10

Hope this helps or at least starts a discussion as SISF is poorly documented.

Best Regards

Kasper

Florian P · ‎01-03-2018

Hi Kasper,

I will try to use

device-tracking policy device_tracking
tracking enable reachable-lifetime 10

and see if it prevents duplicate IP errors on Windows workstation

But for now I have issues on my catalyst 3850.

I have configured this as a 1st try :

device-tracking policy ACCESS_IPv4_GLEAN
limit address-count 5
security-level glean
no protocol ndp
no protocol dhcp6
no protocol udp
tracking enable

and applied it to interfaces :

interface GigabitEthernet1/0/37
switchport access vlan 1308
switchport mode access
switchport voice vlan 1334
device-tracking attach-policy ACCESS_IPv4_GLEAN
no logging event link-status
no logging event power-inline-status
load-interval 30
authentication periodic
authentication timer reauthenticate server
access-session control-direction in
access-session closed
access-session port-control auto
mab
trust device cisco-phone
no snmp trap link-status
dot1x pae authenticator
dot1x timeout tx-period 5
storm-control broadcast level 1.00
storm-control multicast level 1.00
storm-control action trap
spanning-tree portfast
service-policy type control subscriber MAB_DOT1X
service-policy input Marking-Access-Ports
end

The port is up and there is traffic however I don't anything in the database :

show device-tracking database

Best regards,

Florian

Florian P · ‎01-04-2018

I found the solution for the 1st issue (no entries in the database), I actually had to turn on protocol dhcp6 (!) even though this is only IPv4 traffic, very strange ...

device-tracking policy ACCESS_IPv4_GUARD
trusted-port
limit address-count 5
no protocol ndp
no protocol udp
tracking enable

Kblaursen · ‎01-08-2018

Interesting finding about the IPV6 protocol. I didn't disable that so i never had that issue.

I've read up on the differences on probe delay and reachable-lifetime, and setting reachable-lifetime to 10, might be too aggressive.

Default values for states in SISF

reachable-lifetime : 300 sec
stale-lifetime : 24 hours
down-lifetime: 24 hours

Probe Delay

This command does not allow a switch to send a probe for 10 seconds when it detects a link UP/flap, which minimizes the possibility to have the probe sent while the host on the other side of the link checks for duplicate IP addresses. The RFC specifies a 10-second window for duplicate address detection, so if you delay the device-tracking probe, the issue can be solved in most cases.

If the switch sends out an ARP Probe for the client while the host (for example, a Microsoft Windows PC) is in its Duplicate-Address Detection phase, the host detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network. The PC might not obtain an address, and the user must manually release/renew the address, disconnect and reconnect to the network, or reboot the PC in order to gain network access.

In addition to probe-delay, the delay also resets itself when the switch detects a probe from the PC/host. For example, if the probe timer has counted down to five seconds and detects an ARP Probe from the PC/host, the timer resets back to 10 seconds.

Reachable-lifetime

Defines the maximum amount of time a reachable entry is considered to be directly or indirectly reachable without proof of reachability.

Additionally.

REACHABLE: A feature can created an entry by providing L3 and L2 addresses. In this case the entry goes into REACHABLE state. At the same time, a timer T2 is provided to verify the binding (if tracking is enabled). Upon T2 expiration, the entry moves into VERIFY state. If tracking is not enable, the entry remains T6 at most in that state without any reachability hint (obtain with NDP inspection or other features, before moving to STALE.

All in all I'm not confident that reachable-lifetime is a direct translation for probe delay, and as such we might have to tweak multiple timers to get a similar setup.

Best Regards

Kasper

parag_waghmare · ‎05-06-2018

Hi Kblaursen,

Thank you for posting this useful information.

I am struggling with this new SISF based config at the moment. I am testing 9300 Mgig switch platform before mass deployment. Do you know any further now, what is the perfect replacement for "device-tracking probe delay 10" config which will work for the duplicate IP issue not to happen on windows machines connected to the 9300 Mgig switches.

Is it just the one command ?

1) #device-tracking policy reachable-lifetime

When we enable dhcp snooping, by default it enables a policy DT-PROGRAMMATIC. Do you know what this does ?

Thanking you in advance.

Kblaursen · ‎05-06-2018

Hi Parag_Waghmare

I've had a lengthy discussion with a TAC engineer regarding probe delay and reachable-lifetime, and he confirmed that reachable-lifetime is the replacement for probe delay.

In regards to DT-PROGRAMMATIC. I have tried to enable ip dhcp snooping without a device-tracking policy, but I don't get the default policy (DT-PROGRAMMATIC). Which IOS-XE release are you on? I tried it on 16.3.5b.

Best regards

Kasper

parag_waghmare · ‎05-06-2018

Hi Kasper,

Thanks heaps for your response.

I had 16.6.3 Everest code on my 9300 Mgig switch when it was shipped. Then that code had a dhcp snooping bug. TAC gave me an Engineering Image which had that bug resolved.

the default tracking policy gets applied once dhcp snooping is enabled on the vlans.

This document has info about the policy. page 273.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-6/configuration_guide/sec/b_166_sec_3850_cg.pdf

Kblaursen · ‎05-25-2018

No problem at all.

I do however have an update to the subject of reachability-lifetime.

I tried running this configuration in my test setup and when the reachability timer reaches 0, devices lose connection. Some temporary and some permanently.

device-tracking policy device_tracking
no protocol udp
tracking enable
tracking enable reachable-lifetime 120

vlan configuration 1-4094
device-tracking attach-policy device_tracking

device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0 override

device-tracking policy device_tracking_uplink
trusted-port
device-role switch

interface range [uplink range]
device-tracking attach-policy device_tracking_uplink

I have 2 laptops, 1 AP running flexconnect and a Polycom phone connected to my switch running the following verison.

Model SW Version
------ ----- ----- ---------- ---------- ----
WS-C3650-48FQM 16.3.5b

I tested it by pinging the devices from a seperate segment connected to another test switch.

The laptops lost a few pings(2-3)
The access-point also lost a few pings(5-10)
The Polycom phone completely lost connection

Have you guys seen similar behavior ?

Best regards

Kasper

O_o · ‎03-02-2020

Remove IP dhcp snooping
no ip device tracking probe delay 10

no ip dhcp snooping

Add the new command

device-tracking tracking
Add dhcp snooping on all vlan except management vlan
ip dhcp snooping vlan 100,103,104,200

Add the trust command to each trunk ports and port channels if any
interface TenGigabitEthernet1/1/1
ip dhcp snooping trust

interface TenGigabitEthernet1/1/4
ip dhcp snooping trust

interface TenGigabitEthernet6/1/1
ip dhcp snooping trust

interface TenGigabitEthernet6/1/4
ip dhcp snooping trust

interface Port-channel1
ip dhcp snooping trust
no shut

do wri me

end

exit

fitzie · ‎06-22-2018

Along the same lines, I'd like to find out the SFIF equivalent to:

ip device tracking probe auto-source

ip device tracking probe delay 10

which was needed for ISE to do it's magic with 802.1x and CWA.

We seem to get

device-tracking tracking auto-source

as the replacement after the upgrade-cli, but we're having issues getting all switches that we upgrade to work with CWA and 802.1x. Last night we converted two 3850s, one of them worked fine, and one had to be reverted back to 03.07.04E. The stacks were pretty much identical. Oh, and we've had this issue with both Denali 16.3.6 and Fuji 16.8.1a.

kbjja · ‎06-28-2018

Were you able to find the equivalent of

ip device tracking probe delay 10
ip device tracking

I'm upgrading old switches and cannot find an equivalent.

Kblaursen · ‎10-15-2018

Hi

First of all, sorry in advance for the long reply. I have been compiling information from TAC engineers and developers. :)

I recently got this, straight from the developers at Cisco. It does however contradict some information i have gotten from TAC ealier.

"

In earlier releases, customers usually configures “ ip device tracking probe delay 10” to combat “Duplicate IP Address 0.0.0.0” issue. In 16.3 releases before 16.3.6, this cli was wrongly converted to “device-tracking tracking binding reachable-lifetime 10”. I guess that is why customers configures “tracking enable reachable-lifetime 10/15/30” in the “device-tracking” policy. The “probe delay” and “reachable-lifetime” has different meaning and purpose, the latter means how often the switch would probe the device before it moves it to STALE state, while “Probe delay” cli is used to delay the probe when detecting a link goes down and up again.

In 16.X, the probe delay is set to 10 seconds by default. There is no cli to configure probe delay. The default reachable-lifetime is 5 minutes. You don’t need to configure it explicitly.

"

For IPDT itself i've seen TAC Engineers recommend two different methods.

1. Method one

Global command

device-tracking policy device_tracking

tracking enable

Apply to applicable VLANs

vlan configuration 1-4094

device-tracking attach-policy device_tracking

For access switches with layer2 uplink(trunk) you need additional configuration on uplink interface.

Global commands

device-tracking policy device_tracking_uplink

trusted-port

device-role switch

no protocol udp

Uplink interface

interface x/y/z

device-tracking attach-policy device_tracking_uplink

2. Method Two

Note that configuring “ip dhcp snooping vlan <>” doesn’t mean that feature “ ip dhcp snooping” is enabled, because it needs a global cli “ip dhcp snooping” to be configured

Global commands

ip dhcp snooping vlan <vlan list or vlan range>

Its still recommended to have device-tracking configuration on the uplink interface.

Global commands

device-tracking policy device_tracking_uplink

trusted-port

device-role switch

no protocol udp

Uplink interface

interface x/y/z

device-tracking attach-policy device_tracking_uplink

Hope it helps

Regards

Kasper

O_o · ‎03-02-2020

Remove IP dhcp snooping
no ip device tracking probe delay 10

no ip dhcp snooping

Add the new command

device-tracking tracking
Add dhcp snooping on all vlan except management vlan
ip dhcp snooping vlan 100,103,104,200

Add the trust command to each trunk ports and port channels if any
interface TenGigabitEthernet1/1/1
ip dhcp snooping trust

interface TenGigabitEthernet1/1/4
ip dhcp snooping trust

interface TenGigabitEthernet6/1/1
ip dhcp snooping trust

interface TenGigabitEthernet6/1/4
ip dhcp snooping trust

interface Port-channel1
ip dhcp snooping trust
no shut

do wri me

end

exit