New Alta user here, moving off Ubiquiti to move away from having to pay and manage for a hosted controller. Starting off with S8-POE and AP6.
Tooka little bit of testing to get the Alta management VLANs moved off VLAN1 to my own management VLAN. I’m using a Cisco 2960S as a core switch, EdgeRouter 6P as router. A trunk port is configured on the 2960 to trunk the VLANs on the EdgeRouter through to the S8.
Anyway, quick one - I’ve noticed that ICMP reponses on the S8 are very erratic as below. This only seems to be the case when pinging the S8 from a different VLAN than the one its in. Same result from multiple Windows devices.
From PC different VLAN:
Pinging 192.168.20.50 with 32 bytes of data:
Reply from 192.168.20.50: bytes=32 time=498ms TTL=63
Reply from 192.168.20.50: bytes=32 time=569ms TTL=63
Reply from 192.168.20.50: bytes=32 time=664ms TTL=63
Reply from 192.168.20.50: bytes=32 time=555ms TTL=63
Reply from 192.168.20.50: bytes=32 time=220ms TTL=63
Reply from 192.168.20.50: bytes=32 time=534ms TTL=63
Reply from 192.168.20.50: bytes=32 time=697ms TTL=63
Reply from 192.168.20.50: bytes=32 time=104ms TTL=63
Reply from 192.168.20.50: bytes=32 time=518ms TTL=63
Reply from 192.168.20.50: bytes=32 time=218ms TTL=63
Reply from 192.168.20.50: bytes=32 time=151ms TTL=63
Reply from 192.168.20.50: bytes=32 time=2ms TTL=63
Reply from 192.168.20.50: bytes=32 time=858ms TTL=63
Reply from 192.168.20.50: bytes=32 time=88ms TTL=63
Reply from 192.168.20.50: bytes=32 time<1ms TTL=63
Reply from 192.168.20.50: bytes=32 time<1ms TTL=63
From the EdgeRouter CLI:
rismith@rdrs-edge:~$ ping 192.168.20.50
PING 192.168.20.50 (192.168.20.50) 56(84) bytes of data.
64 bytes from 192.168.20.50: icmp_seq=1 ttl=64 time=0.600 ms
64 bytes from 192.168.20.50: icmp_seq=2 ttl=64 time=0.535 ms
64 bytes from 192.168.20.50: icmp_seq=3 ttl=64 time=0.545 ms
64 bytes from 192.168.20.50: icmp_seq=4 ttl=64 time=0.539 ms
64 bytes from 192.168.20.50: icmp_seq=5 ttl=64 time=0.529 ms
64 bytes from 192.168.20.50: icmp_seq=6 ttl=64 time=0.576 ms
64 bytes from 192.168.20.50: icmp_seq=7 ttl=64 time=0.566 ms
64 bytes from 192.168.20.50: icmp_seq=8 ttl=64 time=0.536 ms
=========================
This behviour is not observed when pinging the AP6 management interface from any source. Throughput is seemingly otherwise fine, with no connectivity issues/packetloss occurring.
Just wanted to check if this was common in this line of switches, before I device deeper into my configuration.
Howdy! Not common that I’m aware of anyway. I did a quick test to my S8 and unfortunately (or fortunately), the pings seemed pretty normal to me. Similar case of a computer on a seperate VLAN pinging to the IP on the management VLAN of the switch. Although the setup is just a Route10 and S8, so very simple.
PING 192.168.50.10 (192.168.50.10) 56(84) bytes of data.
64 bytes from 192.168.50.10: icmp_seq=1 ttl=63 time=1.14 ms
64 bytes from 192.168.50.10: icmp_seq=2 ttl=63 time=1.08 ms
64 bytes from 192.168.50.10: icmp_seq=3 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=4 ttl=63 time=1.14 ms
64 bytes from 192.168.50.10: icmp_seq=5 ttl=63 time=1.30 ms
64 bytes from 192.168.50.10: icmp_seq=6 ttl=63 time=1.16 ms
64 bytes from 192.168.50.10: icmp_seq=7 ttl=63 time=1.04 ms
64 bytes from 192.168.50.10: icmp_seq=8 ttl=63 time=1.16 ms
64 bytes from 192.168.50.10: icmp_seq=9 ttl=63 time=1.12 ms
64 bytes from 192.168.50.10: icmp_seq=10 ttl=63 time=1.08 ms
64 bytes from 192.168.50.10: icmp_seq=11 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=12 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=13 ttl=63 time=1.13 ms
64 bytes from 192.168.50.10: icmp_seq=14 ttl=63 time=1.11 ms
64 bytes from 192.168.50.10: icmp_seq=15 ttl=63 time=1.16 ms
64 bytes from 192.168.50.10: icmp_seq=16 ttl=63 time=1.11 ms
64 bytes from 192.168.50.10: icmp_seq=17 ttl=63 time=1.11 ms
64 bytes from 192.168.50.10: icmp_seq=18 ttl=63 time=1.24 ms
64 bytes from 192.168.50.10: icmp_seq=19 ttl=63 time=1.18 ms
64 bytes from 192.168.50.10: icmp_seq=20 ttl=63 time=1.17 ms
64 bytes from 192.168.50.10: icmp_seq=21 ttl=63 time=1.19 ms
64 bytes from 192.168.50.10: icmp_seq=22 ttl=63 time=1.08 ms
64 bytes from 192.168.50.10: icmp_seq=23 ttl=63 time=1.32 ms
64 bytes from 192.168.50.10: icmp_seq=24 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=25 ttl=63 time=1.08 ms
64 bytes from 192.168.50.10: icmp_seq=26 ttl=63 time=1.25 ms
64 bytes from 192.168.50.10: icmp_seq=27 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=28 ttl=63 time=1.15 ms
64 bytes from 192.168.50.10: icmp_seq=29 ttl=63 time=1.06 ms
64 bytes from 192.168.50.10: icmp_seq=30 ttl=63 time=1.12 ms
64 bytes from 192.168.50.10: icmp_seq=31 ttl=63 time=1.11 ms
64 bytes from 192.168.50.10: icmp_seq=32 ttl=63 time=1.12 ms
64 bytes from 192.168.50.10: icmp_seq=33 ttl=63 time=1.16 ms
64 bytes from 192.168.50.10: icmp_seq=34 ttl=63 time=1.10 ms
64 bytes from 192.168.50.10: icmp_seq=35 ttl=63 time=1.10 ms
64 bytes from 192.168.50.10: icmp_seq=36 ttl=63 time=1.15 ms
64 bytes from 192.168.50.10: icmp_seq=37 ttl=63 time=1.12 ms
64 bytes from 192.168.50.10: icmp_seq=38 ttl=63 time=1.10 ms
64 bytes from 192.168.50.10: icmp_seq=39 ttl=63 time=1.13 ms
64 bytes from 192.168.50.10: icmp_seq=40 ttl=63 time=1.14 ms
64 bytes from 192.168.50.10: icmp_seq=41 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=42 ttl=63 time=1.10 ms
64 bytes from 192.168.50.10: icmp_seq=43 ttl=63 time=1.18 ms
64 bytes from 192.168.50.10: icmp_seq=44 ttl=63 time=1.10 ms
64 bytes from 192.168.50.10: icmp_seq=45 ttl=63 time=1.33 ms
64 bytes from 192.168.50.10: icmp_seq=46 ttl=63 time=1.14 ms
64 bytes from 192.168.50.10: icmp_seq=47 ttl=63 time=1.09 ms
64 bytes from 192.168.50.10: icmp_seq=48 ttl=63 time=1.13 ms
64 bytes from 192.168.50.10: icmp_seq=49 ttl=63 time=1.11 ms
64 bytes from 192.168.50.10: icmp_seq=50 ttl=63 time=1.12 ms
64 bytes from 192.168.50.10: icmp_seq=51 ttl=63 time=1.13 ms
64 bytes from 192.168.50.10: icmp_seq=52 ttl=63 time=1.15 ms
64 bytes from 192.168.50.10: icmp_seq=53 ttl=63 time=1.14 ms
64 bytes from 192.168.50.10: icmp_seq=54 ttl=63 time=1.19 ms
64 bytes from 192.168.50.10: icmp_seq=55 ttl=63 time=1.15 ms
64 bytes from 192.168.50.10: icmp_seq=56 ttl=63 time=1.19 ms
64 bytes from 192.168.50.10: icmp_seq=57 ttl=63 time=1.22 ms
64 bytes from 192.168.50.10: icmp_seq=58 ttl=63 time=1.27 ms
64 bytes from 192.168.50.10: icmp_seq=59 ttl=63 time=1.18 ms
Something to check would be the system load on the switch while running the ping. I could imagine seeing that behavior if the CPU on the switch was busy for some reason, and the switching should continue to run normally since that’s a seperate ASIC chip handling that.
No problem! I can at least say that load sounds pretty normal, at least in my experience. CPU usually seems to hover around 20-30% when looking at it in the controller.
When a device is directly connected to the S8 and pinging its management interface on a different VLAN, the ICMP ‘issue’, is present.
As soon as I move the device off the S8, and plug into another, different switch (the Cisco core, for example), the issue entirely dissappears, even when pinging it from the same source VLAN.
Had a chance to test this and I can at least say that I do see similar behavior to what @Packetz was seeing when pinging the management IP from a computer connected directly to the switch.
Pinging 192.168.50.10 with 32 bytes of data:
Reply from 192.168.50.10: bytes=32 time=111ms TTL=63
Reply from 192.168.50.10: bytes=32 time=120ms TTL=63
Reply from 192.168.50.10: bytes=32 time=114ms TTL=63
Reply from 192.168.50.10: bytes=32 time=103ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=41ms TTL=63
Reply from 192.168.50.10: bytes=32 time=38ms TTL=63
Reply from 192.168.50.10: bytes=32 time=262ms TTL=63
Reply from 192.168.50.10: bytes=32 time=7ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=36ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=2ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=119ms TTL=63
Reply from 192.168.50.10: bytes=32 time=34ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=5ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=96ms TTL=63
Reply from 192.168.50.10: bytes=32 time=474ms TTL=63
Reply from 192.168.50.10: bytes=32 time=10ms TTL=63
Reply from 192.168.50.10: bytes=32 time=1ms TTL=63
Reply from 192.168.50.10: bytes=32 time=30ms TTL=63
Cheers for testing and confirming the behaviour can be replicated!
I’m not entirely sure why this occurs, but something to be aware of in case others transcend into a troubleshooting rabbit hole. I’ll put the query to our network engineering team if they can understand why this may happen, but I suspect it something specific to Alta Labs firmware/code which runs on these devices.
I’m not able to reproduce anything similar from a Control directly connected to an S8-POE here. If you can provide access to a system where this is easily reproducible, we can take a look.
root@Control:~# ping -c 100 172.9.0.45
PING 172.9.0.45 (172.9.0.45) 56(84) bytes of data.
64 bytes from 172.9.0.45: icmp_seq=1 ttl=64 time=0.593 ms
64 bytes from 172.9.0.45: icmp_seq=2 ttl=64 time=0.584 ms
64 bytes from 172.9.0.45: icmp_seq=3 ttl=64 time=0.539 ms…
64 bytes from 172.9.0.45: icmp_seq=97 ttl=64 time=0.500 ms
64 bytes from 172.9.0.45: icmp_seq=98 ttl=64 time=0.513 ms
64 bytes from 172.9.0.45: icmp_seq=99 ttl=64 time=0.663 ms
64 bytes from 172.9.0.45: icmp_seq=100 ttl=64 time=0.551 ms
— 172.9.0.45 ping statistics —
100 packets transmitted, 100 received, 0% packet loss, time 101364ms
rtt min/avg/max/mdev = 0.490/0.532/0.663/0.028 ms
Hi Jeff! Would it be possible for you to test what myself and @Packetz were seeing when pinging the management IP from a PC? Just curious to see if that behavior can continue to be replicated from a PC specifically. I’ll say that this isn’t really causing a problem for me per se, just the behavior is a little unexpected so I’m curious about it
Also, I’m kinda able to replicate it when pinging the management IP from an AP6 directly connected to a S8. Although the spikes aren’t as frequent or dramatic:
~ # ping 192.168.50.10
PING 192.168.50.10 (192.168.50.10): 56 data bytes
64 bytes from 192.168.50.10: seq=0 ttl=63 time=1.591 ms
64 bytes from 192.168.50.10: seq=1 ttl=63 time=1.376 ms
64 bytes from 192.168.50.10: seq=2 ttl=63 time=1.359 ms
64 bytes from 192.168.50.10: seq=3 ttl=63 time=1.415 ms
64 bytes from 192.168.50.10: seq=4 ttl=63 time=1.399 ms
64 bytes from 192.168.50.10: seq=5 ttl=63 time=1.383 ms
64 bytes from 192.168.50.10: seq=6 ttl=63 time=1.455 ms
64 bytes from 192.168.50.10: seq=7 ttl=63 time=1.466 ms
64 bytes from 192.168.50.10: seq=8 ttl=63 time=1.313 ms
64 bytes from 192.168.50.10: seq=9 ttl=63 time=1.299 ms
64 bytes from 192.168.50.10: seq=10 ttl=63 time=1.543 ms
64 bytes from 192.168.50.10: seq=11 ttl=63 time=1.361 ms
64 bytes from 192.168.50.10: seq=12 ttl=63 time=1.320 ms
64 bytes from 192.168.50.10: seq=13 ttl=63 time=1.302 ms
64 bytes from 192.168.50.10: seq=14 ttl=63 time=1.301 ms
64 bytes from 192.168.50.10: seq=15 ttl=63 time=1.395 ms
64 bytes from 192.168.50.10: seq=16 ttl=63 time=1.370 ms
64 bytes from 192.168.50.10: seq=17 ttl=63 time=1.347 ms
64 bytes from 192.168.50.10: seq=18 ttl=63 time=1.292 ms
64 bytes from 192.168.50.10: seq=19 ttl=63 time=1.410 ms
64 bytes from 192.168.50.10: seq=20 ttl=63 time=1.575 ms
64 bytes from 192.168.50.10: seq=21 ttl=63 time=1.300 ms
64 bytes from 192.168.50.10: seq=22 ttl=63 time=1.341 ms
64 bytes from 192.168.50.10: seq=23 ttl=63 time=1.386 ms
64 bytes from 192.168.50.10: seq=24 ttl=63 time=35.144 ms
64 bytes from 192.168.50.10: seq=25 ttl=63 time=1.328 ms
64 bytes from 192.168.50.10: seq=26 ttl=63 time=1.438 ms
64 bytes from 192.168.50.10: seq=27 ttl=63 time=1.431 ms
64 bytes from 192.168.50.10: seq=28 ttl=63 time=1.365 ms
64 bytes from 192.168.50.10: seq=29 ttl=63 time=1.258 ms
64 bytes from 192.168.50.10: seq=30 ttl=63 time=1.368 ms
64 bytes from 192.168.50.10: seq=31 ttl=63 time=1.359 ms
64 bytes from 192.168.50.10: seq=32 ttl=63 time=1.335 ms
64 bytes from 192.168.50.10: seq=33 ttl=63 time=1.323 ms
64 bytes from 192.168.50.10: seq=34 ttl=63 time=1.325 ms
64 bytes from 192.168.50.10: seq=35 ttl=63 time=1.430 ms
64 bytes from 192.168.50.10: seq=36 ttl=63 time=1.608 ms
64 bytes from 192.168.50.10: seq=37 ttl=63 time=1.369 ms
64 bytes from 192.168.50.10: seq=38 ttl=63 time=1.348 ms
64 bytes from 192.168.50.10: seq=39 ttl=63 time=1.337 ms
64 bytes from 192.168.50.10: seq=40 ttl=63 time=1.423 ms
64 bytes from 192.168.50.10: seq=41 ttl=63 time=1.388 ms
64 bytes from 192.168.50.10: seq=42 ttl=63 time=1.351 ms
64 bytes from 192.168.50.10: seq=43 ttl=63 time=1.358 ms
64 bytes from 192.168.50.10: seq=44 ttl=63 time=1.631 ms
64 bytes from 192.168.50.10: seq=45 ttl=63 time=1.336 ms
64 bytes from 192.168.50.10: seq=46 ttl=63 time=1.552 ms
64 bytes from 192.168.50.10: seq=47 ttl=63 time=1.380 ms
64 bytes from 192.168.50.10: seq=48 ttl=63 time=1.344 ms
64 bytes from 192.168.50.10: seq=49 ttl=63 time=247.743 ms
64 bytes from 192.168.50.10: seq=50 ttl=63 time=94.178 ms
64 bytes from 192.168.50.10: seq=51 ttl=63 time=1.402 ms
64 bytes from 192.168.50.10: seq=52 ttl=63 time=1.332 ms
64 bytes from 192.168.50.10: seq=53 ttl=63 time=1.289 ms
64 bytes from 192.168.50.10: seq=54 ttl=63 time=1.533 ms
64 bytes from 192.168.50.10: seq=55 ttl=63 time=1.363 ms
64 bytes from 192.168.50.10: seq=56 ttl=63 time=1.426 ms
64 bytes from 192.168.50.10: seq=57 ttl=63 time=1.422 ms
64 bytes from 192.168.50.10: seq=58 ttl=63 time=1.272 ms
^C
--- 192.168.50.10 ping statistics ---
59 packets transmitted, 59 packets received, 0% packet loss
round-trip min/avg/max = 1.258/7.708/247.743 ms
Honestly I don’t have a PC here to test with, but I do see very intermittent <100ms+ ping every now and then when directly attached with a Mac. We’ve actually looked into this several times and improved it dramatically since the first switch release (if you look at release notes for improved CPU consumption), but I don’t believe it will ever go away completely.
That’s because those minor blips are when the switch is handling statistics and communicating with the controller. If you ping the Linux host system directly, there is a chance that it may not respond immediately due to other tasks running. It does not impact traffic that passes through the switch fabric, though, i.e. traffic from one port and out another port. Of course we’ve seen the one report of a user having increased latency when passing through the switch fabric, but we’ve never been able to confirm this internally and have never been invited to a site where the problem is occurring. The switch fabric runs completely independent of the host processor that you’re seeing the intermittent ping spikes from.
@Packetz Are you on the latest switch firmware? I’ve seen high ping times like your report on very old firmwares, but not on anything recent. Are you open to inviting me to your site?
