Operations¶
Intra-node ping¶
Ping green2
from green1
:
green1-75667cbd6f-8kn74> cmd ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.91 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.668 ms
^C
--- 192.168.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.668/1.289/1.910/0.621 ms
In this case, the traffic is simply bridged by hna1
, without reaching
a leaf router.
Inter-node ping¶
Ping green3
from green1
:
green1-75667cbd6f-8kn74> cmd ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=3.48 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=64 time=1.66 ms
^C
--- 192.168.0.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.660/2.570/3.481/0.910 ms
In this case, the ping request is simply bridged by hna1
, encapsulated
into a VXLAN tunnel, sent to a leaf router, received and bridged by
hna2
, and finally sent to green3
.
Delete an HNA pod¶
It is possible to delete (or update) an HNA pod, and check the pings again.
root@node1:~# kubectl delete pod hna-hzj7l
pod "hna-hzj7l" deleted
When the pod is back, the pings are successful again.
Delete a CNF¶
Delete green1
and red1
:
root@node1:~# kubectl delete pod green1-75667cbd6f-8kn74
pod "green1-75667cbd6f-8kn74" deleted
root@node1:~# kubectl delete pod red1-d75dc6b4f-dvp8d
pod "red1-d75dc6b4f-dvp8d" deleted
When the pods are back, the pings are successful again.
Delete HNA operator¶
Delete green1
and red1
:
root@node1:~# kubectl delete pod -n hna-operator hna-operator-cwjp8
pod "hna-operator-cwjp8" deleted
The ping traffic is never interrupted.