Wired Intelligent Edge (Campus Switching and Routing)

Reply
Highlighted
Contributor I

PPTN Tunneled-Node drop clients

We have a problem that needs to be solved. 

We have deployed Tunneled-Node (per port, not user-based) on our network and in most cases everything works fine. 


Our setup is 2920 and 2930 Aruba Switches, authenticating through a Clearpass Cluster, gets a role that is assigned through a Mobility Master to Mobility Devices that is the tunnel host. 

 

Computers authenticate with a computer certificate and this works perfect. 

 

The problem is with devices that we don't have control of, like building automations and more old devices. With these, we have made a static host list (SHL) where we simply permit the devices in a list and assigns a VLAN based of that list. 

 

This works, we can see devices come up and create a tunnel, the devices is pingable and so on, but randomly, these type of devices stops answer to ping and appears to be offline. 

 

They have previously been assigned to VLAN 574 but with PPTN enabled, VLAN 10 has been assigned to all ports across the network. 

If we turn off tunneled-node on the access ports an assign vlan 574 untagged to these ports again, they come online. We can then turn on tunneled-node again and they authenticate to clearpass and comes online again. Why?

 

Our configuration on the switches:

Spoiler
tunneled-node-server
controller-ip 10.208.10.8
backup-controller-ip 10.208.10.9
exit

interface 1/10
name "PPTN"
tunneled-node-server
exit

vlan 10
name "PPTN-DUMMY"
untagged 1/10
no ip address
jumbo
exit

This is a live and working tunnel:

Spoiler
10.10.74.50 00:05:7c:00:5e:24 00057c005e24 ROLE-BMS-574 63:03:51 MAC tunnel 2877 Tunneled 10.208.10.146:15/b8:83:03:e4:4c:80 PPTN-Profile tunnel

When the device stops answering, the device is not responding to ping, not accessible through the management software, no arp, nothing!

 

It appears that only some devices have this behaviour while other devices on the exact same switch is working fine. 

 

Have we implemented this in the correct way or are we missing something?

Highlighted
MVP Expert

Re: PPTN Tunneled-Node drop clients

It is possible that those devices are going to sleep and you may require to enable WoL on those ports:

https://techhub.hpe.com/eginfolib/networking/docs/switches/WB/15-18/5998-8152_wb_2920_asg/content/ch13s05.html

 

The Wake-on-LAN feature is used by network administrators to remotely power on a sleeping workstation (for example, during early morning hours to perform routine maintenance operations, such as patch management and software updates).

Thank you

Victor Fabian
Lead Mobility Architect @WEI
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
Highlighted
Contributor I

Re: PPTN Tunneled-Node drop clients

Problably not. These devices responds as soon as I disable tunneled-node and assign VLAN 574 again, so the devices are awake. The devices that have the most trouble are heat pumps, ventilation systems, locking systems and so on. 

Highlighted
Contributor II

Re: PPTN Tunneled-Node drop clients

Hi

 

I don't know if this is the same problem, but we had experienced a similar  weird problem with old "monitor/sensor" devices doing mac authentication.

They would randomly stops responding on the network and if you list the mac-address on the port, no mac would be found. As if the devices were on a kind of "sleep mode". 

We were able to solve that using some additional options on the port's configuration.

 

interface 4
name "sensor"
aaa port-access mac-based 
aaa port-access mac-based mac-pin 
aaa port-access controlled-direction in

Highlighted
Contributor I

Re: PPTN Tunneled-Node drop clients

I think you misunderstood my question completely. 

We don't run AAA at all, we're using Tunneled-Node configuration. AAA has nothing to do with this. 

We never see MAC-adresses onports authenticated or unuthenticated and we don't want to enable special rules for unauthenticated devices since these devices are authenticated. 

Highlighted

Re: PPTN Tunneled-Node drop clients

How often this happens? Can you see tunnel alive with 'show tunneled-node-server state' after you lose connectivity? 

 

If it happens often you could leave terminal open with debug destination session + debug usertn and see what kind of message you get.

 

We're also starting to implement tunneled stuff so this is very interesting. Though I'm hoping we could use 802.1x/MAB but never know if we have to fall back to just having ports statically configured

 

(For MAB I've used these:

aaa port-access mac-based 1 logoff-period 604800

aaa port-access 1 controlled-direction in

to have a long timeouts + allow WoL/pings from NMS but I'm not sure if they are really needed? I've read that some printers are problematic when they go to sleep mode)

Highlighted
Contributor I

Re: PPTN Tunneled-Node drop clients

I know have some more information and a unit that behaves like this. 

Device IP: 10.205.74.151

Connected to switch 10.208.0.128 port 10. 

 

As you can see the device stops authenticating about 1 day ago. 

Client stops authenticatingClient stops authenticating

 

If I run #show tunneled-node-state on the switch the port says "Complete"

10.208.0.128# show tunneled-node-server state

 Tunneled Node Port State

 Active Controller IP Address  : 10.208.0.9                              

 Port   State                    
 ------ -------------------------
 10     Complete                 

 

If I run the #show user-table command on our Mobility Device (tunnel-server) I can see that port 10 doesn't have a tunnel, but port 9 does and is working as it should. 

(MD02) *#show user-table | include 10.208.0.128:10
(MD02) *#show user-table | include 10.208.0.128:9
10.205.74.147  bc:6a:29:9a:5b:3e  bc6a299a5b3e                Kumla-BMS-574  00:22:35    MAC                     tunnel 3809         Tunneled  10.208.0.128:9/94:f1:28:08:e8:80            PPTN-Profile        tunnel                              WIRED

 And as I said earlier, it doesn't matter if I have a functioning tunnel port or not, no MAC-address is available to view directly on the switch:

10.208.0.128# show mac-address 10

 Status and Counters - Port Address Table - 10

  MAC Address   VLANs       
  ------------- ------------
 

 

Now to the interesting part. 

The OLD VLAN for this equipment was VLAN 574. The New VLAN with tunneled-node is VLAN 10. 

If I simply change the VLAN to 574 for accessport 10 the device starts to authenticate with clearpass and get's online again, but not when I change it back to VLAN 10. Sometimes, it's still online and sometimes not. 

 

As soon as I change the VLAN the device comes online and as you can see, the device starts to authenticate again. 

Working client after VLAN changeWorking client after VLAN change

Why in the world does a VLAN matter when using a tunnel? Have I completely misunderstood this technology?

Highlighted

Re: PPTN Tunneled-Node drop clients

When port-based tunneling was implemented in AOS-Switch, the VLAN basically acts as a tunnel "endpoint", as AOS-Switch is VLAN-centric, so the VLAN ID must match between switch and controller.

 

This was changed with user-based tunneling early last year, where the VLAN did not matter as all traffic was tunneled over a reserved VLAN, and the controller role would assign the VLAN, that is not the case with port-based tunneling.

 

Justin

 

 

Highlighted
Contributor I

Re: PPTN Tunneled-Node drop clients

This is very interesting Justin. 
But why do this work for us 99% of the time and simply stop to work after a while? Do you have any documentation on this?

Thanks

Highlighted
Contributor I

Re: PPTN Tunneled-Node drop clients

The thing is that we have a lot of working clients that is using Per Port Tunneled Node using dummy-vlan 10 as a carrier and change VLAN depending on what role is assigned to the tunnel via CPPM. 

 

This is information about the client that doesn't work. 

I start by verifying that a tunnel is indeed created:

1Tunnel-ID.png

 

 

 

 

 

 

 

 

 

 

As you can see a tunnel with "Tunnel-ID 3938" is created on port 10 on switch 10.208.0.128. 

 

If I then check if a user-tunnel is created I can see that there isn't any: 

1No User-table Info.png

 

 

 

The next step is to see if any traffic flows. And this is the interesting part. If I check the datapath tunnel information for tunnel 3938 I can see that a tunnel is created using protocol 47 (GRE). Why is there no decapsulation of the packets?1client_tunnel_no_decaps.png 

The same information can be viewed from the switch itself using the "show tunneled-node-server statistics command". 

1client_tunnel_statistics_on_switch_no_TX_Packets.png

Now lets look at a working client on the same switch. 

The working client has a tunnelid of 3807. 

Here we have output for both decaps and encaps as you can see in the pictures below. 

Working Client tunnel database.pngWorking client tunnel statistics on switch.pngThe device is also viewable as a user in the user-table. 
Working Client user-table.png

 

All Windows laptops, Windows workstation, Macbooks, Linux computers Servers, Point-of-sale work as they should so why not this and why is this working if there isn't something Aruba supports?

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: