cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
23216
Views
55
Helpful
13
Replies

IP Device Tracking New CLI - SISF - Denali 16.3.5

Florian P
Level 1
Level 1

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.

13 Replies 13

Kblaursen
Level 1
Level 1

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

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

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

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

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.

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

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

 

 

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

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
Level 1
Level 1

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.

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. 

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
Level 1
Level 1

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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco