ISE 2.2 TCP Dump in ESXi - not seeing any ISE originated traffic

[Arne Bier]

Hi

Are there any special tricks when performing an ISE TCP Dump via the GUI in a VMWare vDS environment?  All nodes were deployed from the ISE-2.2.0.470-virtual-200GB-SNS3595.ova

I have a fully distributed ISE environment and my PSN's have Gig0 for management only, and Gig1 used for Radius/TACACS/Webauth.  Did I make a schoolboy error by designating the Gig1 interface only for Radius/TACACS/Webauth?  I only send that traffic to that interface, yet ISE decides to respond with Gig0 ... is this normal?

I ran a TCP Dump on a PSN GigabitEthernet 1 and I can see all the remote stations' traffic to ISE, but the Wireshark doesn't show any traffic originating from GigabitEthernet1.

The authentications are working well - but I was trying to investigate a CoA issue when I noticed that I cannot see what my PSN is sending out.  I tried the CLI verison "tech dumptcp 1" - no joy.

Just for fun I ran a TCP Dump on Gig0 and Gig1 (repeated the same authentication) and lo and behold I can see the entire conversation now.   Although, the ISE IP address is always shown as being from the Gig1 interface!!! How can that be?

It's as if the VM NIC's have been plumbed into the same VLAN.  But they are not - they are in two different Port Groups (different VLAN's).

10.6.83.223 is the Gig1 IP address of the PSN.

10.109.64.243 is the Cisco WLC.

PSN node below - notice the Gig0 has .82 in third octet of IP address.  No Radius traffic should be found there

sco8834ise052/admin# show interface gigabitEthernet 0
GigabitEthernet 0
        flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.6.82.223  netmask 255.255.255.0  broadcast 10.6.82.255
        inet6 fe80::250:56ff:fe90:ab83  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:90:ab:83  txqueuelen 1000  (Ethernet)
        RX packets 2116196  bytes 202309382 (192.9 MiB)
        RX errors 0  dropped 1517724  overruns 0  frame 0
        TX packets 185812  bytes 41085901 (39.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sco8834ise052/admin# show interface gigabitEthernet 1
GigabitEthernet 1
        flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.6.83.223  netmask 255.255.255.0  broadcast 10.6.83.255
        inet6 fe80::250:56ff:fe90:94a3  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:90:94:a3  txqueuelen 1000  (Ethernet)
        RX packets 467895  bytes 34888223 (33.2 MiB)
        RX errors 0  dropped 945  overruns 0  frame 0
        TX packets 5580  bytes 492342 (480.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The Radius client is a Cisco WLC and its AAA server is configured for 10.6.83.223

Starting to reconsider using two interfaces on the PSN - and rather just keeping it simple with one interface.  What is the benefit anyway of separating out the traffic in a VMWare environment?

regards

Arne

[paul · Accepted solution]

I on use one interface on my ISE nodes except when I need a DMZ interface on my PSNs for guest portal applications.  Do you have a default route for each of your interfaces?  It not the traffic will use the routing table to respond out Gig 0 where I am assuming the default gateway you entered during setup is.  The nodes have logic to use the default  route attached to the interface the traffic came in on.

[Arne Bier]

Paul

thanks!  That was the problem.  In my case the web portals are not in a DMZ so in theory I could probably collapse the design into using Gig0 for everything.

I will however keep Gig1 in case we move the portals into a DMZ.

I have also reconfigured my WLC to send Radius to Gig0, but to run the Guest Portals on Gig1.  That ought to be a good design solution?

thanks for the speedy replies (incl 'hslai')!

[hslai]

I agreed with Paul's.

Incidentally, I tried something similar last night:

In a simple setup that sponsor on Gi1, mydevices on Gi0 and my client is able to reach both interfaces.

At first, ISE has only ip default gateway to GW-4-Gi0 so the packet flow to sponsor is like this:

     client => Gi1 => ISE sponsor => Gi0 => client.

After adding ip route 0.0.0.0 0.0.0.0 GW-4-Gi1, the packet flow changes to:

     client => Gi1 => ISE sponsor => Gi1 => client.

Meanwhile, accessing to mydevices keeps [ Client -> Gi0 -> ISE mydevices -> Gi0 -> Client ] before and after.