[swss]: Listen for undeliverable IPinIP packets#9348
[swss]: Listen for undeliverable IPinIP packets#9348theasianpianist merged 10 commits intosonic-net:masterfrom
Conversation
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
| logger.log_notice('Starting IPinIP listener for IPs {} and {}' | ||
| .format(self_ip, peer_ip)) | ||
| while True: | ||
| sniff( |
There was a problem hiding this comment.
could you check the cpu utilization of this? especially, if have a lots of packet trapped to Lpbk0 IP?
There was a problem hiding this comment.
The maximum rate that scapy can send packets from the PTF is about 170 KB/s. Sending IPinIP packets at this rate causes utilization to hover around ~2%, never exceeding ~2.6%
admin@str2-7050cx3-acs-08:~$ ps ax | grep ipinip_ping | grep -v grep
91073 pts/0 S 0:03 python3 /usr/bin/ipinip_ping.py
admin@str2-7050cx3-acs-08:~$ top | grep 91073
91073 root 20 0 38704 28308 9376 S 2.3 0.2 0:03.65 python3
91073 root 20 0 38960 28364 9376 S 2.0 0.2 0:03.71 python3
91073 root 20 0 38960 28432 9376 S 1.7 0.2 0:03.76 python3
91073 root 20 0 38960 28508 9376 S 2.6 0.2 0:03.84 python3
91073 root 20 0 38960 28568 9376 S 1.7 0.2 0:03.89 python3
91073 root 20 0 38960 28628 9376 S 2.0 0.2 0:03.95 python3
91073 root 20 0 39216 28692 9376 S 2.0 0.2 0:04.01 python3
91073 root 20 0 39216 28772 9376 S 2.0 0.2 0:04.07 python3
91073 root 20 0 39216 28840 9376 S 2.0 0.2 0:04.13 python3
91073 root 20 0 39348 28904 9376 S 2.3 0.2 0:04.20 python3
- Use STATE_DB INTERFACE_TABLE to check portchannel status - Cache portchannel members from config DB - Wrap `ping` command with `timeout` for graceful exit - Verify that the tunnel type in config DB is IPinIP Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
| """ | ||
| start = datetime.now() | ||
|
|
||
| while (datetime.now() - start).seconds < 60: |
There was a problem hiding this comment.
this should be timeout, correct?
|
|
||
| self_ip, peer_ip = self.get_ipinip_tunnel_addrs() | ||
| if self_ip is None or peer_ip is None: | ||
| logger.log_error('Could not get IPinIP tunnel addresses from ' |
There was a problem hiding this comment.
this need not be error in single tor. Lets have it as notice
| @@ -0,0 +1,233 @@ | |||
| #! /usr/bin/env python3 | |||
| """ | |||
| Adds neighbor to kernel for undeliverable IPinIP packets | |||
There was a problem hiding this comment.
Suggest renaming this to tunnel_packet_handler.py so we can extend this to Vxlan in future
- Use argument instead of hardcoded value for timeout - Reduce some logging severity Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
|
/Azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
|
/Azp run all |
|
No pipelines are associated with this pull request. |
| pc_index_map = self.get_portchannel_index_mapping() | ||
| for msg in messages: | ||
| if msg['index'] in pc_index_map: | ||
| if msg['state'] == 'up': |
There was a problem hiding this comment.
Lets check for interface flap cases as a future enhancement.
|
/Azp run |
|
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
|
/Azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
- Create a script in the orchagent docker container which listens for these encapsulated packets which are trapped to CPU (indicating that they cannot be routed/no neighbor info exists for the inner packet). When such a packet is received, the script will issue a ping command to the packet's inner destination IP to start the neighbor learning process. - This script is also resilient to portchannel status changes (i.e. interface going up or down). An interface going down does not affect traffic sniffing on interfaces which are still up. When an interface comes back up, we restart the sniffer to start capturing traffic on that interface again.
- Create a script in the orchagent docker container which listens for these encapsulated packets which are trapped to CPU (indicating that they cannot be routed/no neighbor info exists for the inner packet). When such a packet is received, the script will issue a ping command to the packet's inner destination IP to start the neighbor learning process. - This script is also resilient to portchannel status changes (i.e. interface going up or down). An interface going down does not affect traffic sniffing on interfaces which are still up. When an interface comes back up, we restart the sniffer to start capturing traffic on that interface again.
Why I did it
In dual ToR setups, it is possible for the standby to encap a server-bound packet to the active ToR when the active ToR does not have neighbor information for the packet's destination IP. In this case, the packet will be trapped to the CPU and dropped with no further action taken. This can result in blackholed traffic.
How I did it
Create a script in the orchagent docker container which listens for these trapped encapsulated packets. When such a packet is received, the script will issue a
pingcommand to the packet's inner destination IP to start the neighbor learning process.This script is also resilient to portchannel status changes (i.e. interface going up or down). An interface going down does not affect traffic sniffing on interfaces which are still up. When an interface comes back up, we restart the sniffer to start capturing traffic on that interface again.
How to verify it
Send an IPinIP packet to the active ToR:
This packet must meet the following requirements:
PEER_SWITCHtable in config DBVerify that the inner destination IP is added to the kernel neighbor table:
Verify via packet capture that neighbor solicitation messages are sent by the kernel on the VLAN interface:
Verify that the
pingcommand was recorded in the syslog:Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)