This section describes a method tor troubleshooting switch connectivity issues in OpenFlow switch environments. This includes two components:
A packet generator to send test packets of supported protocols via the controller from one end node to another across an OpenFlow domain.
A path analyzer providing generated test packet information to help determine which path the test packets take, and helps in identifying the point of failure; that is, the switch that is not forwarding the traffic as expected on the path.
The procedures in this section can be done using a REST-based tool such as RSdoc.
Unable to reach a specific end host for a particular type of service; that is, the end hosts cannot communicate with each other using a particular traffic flow. For example, a user is unable use the FTP services hosted by particular server.
Collect the source and destination end host configuration details.
Register a packet that will be injected into the network for tracing the path.
Set an observation post on the switch where the destined end host is connected.
If the observation post has not received the registered packet, set an observation post on the switch that is next-hop from the source switch.
Repeat steps 3 – 8 to determine the switch data path ID where the packet is being dropped.
Authenticate using the following cURL command:
curl --noproxy controller_ip -X POST --fail -ksSfL --url "https:// controller_ip:8443/sdn/v2.0/auth" -H "Content-Type: application/json --data-binary '{"login":{"domain": "sdn","user": "sdn","password": "skyline"}}
Collect the source and destination end host details using NodeManager REST API via RsDoc/CLI
For example: https://controller-ip-addr:8443/sdn/v2.0/net/nodes
For example: https://controller-ip-addr:8443/sdn/v2.0/net/nodes
"nodes":
[
{
"ip": "10.0.0.6",
"mac": "22:4d:a4:05:22:dc",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:06",
"port": 1
},
{
"ip": "10.0.0.3",
"mac": "ce:9c:38:8f:c5:57",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:03",
"port": 1
},
{
"ip": "10.0.0.5",
"mac": "8e:f4:3c:47:27:09",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:05",
"port": 1
},
{
"ip": "10.0.0.1",
"mac": "76:3d:0c:d3:5e:a5",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:01",
"port": 1
},
{
"ip": "10.0.0.9",
"mac": "fe:f8:54:82:bb:39",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:09",
"port": 1
},
{
"ip": "10.0.0.2",
"mac": "9e:1a:cc:cb:43:7f",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:02",
"port": 1
},
{
"ip": "10.0.0.10",
"mac": "ee:22:95:a5:d5:22",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:0a",
"port": 1
},
{
"ip": "10.0.0.8",
"mac": "e6:12:8e:f9:03:64",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:08",
"port": 1
},
{
"ip": "10.0.0.7",
"mac": "12:94:57:f7:cb:66",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:07",
"port": 1
},
{
"ip": "10.0.0.4",
"mac": "82:a3:85:71:63:bf",
"vid": 0,
"dpid": "00:00:00:00:00:00:00:04",
"port": 1
}
]
} Register a packet which needs to be injected in the network for tracing the path. For example TCP packet with destination port as 21.
POST https://controller_ip:8443/sdn/v2.0/diag/packets
{"packet": {
"type": "TCP",
"eth": {
"eth_dst": "00:00:00:00:00:05",
"eth_src": "00:00:00:00:00:06",
"eth_type": "IPv4"
},
"ip": {
"ipv4_dst": "10.0.0.5",
"ipv4_src": "10.0.0.6",
ip_proto": "TCP",
"ip_dscn": "CS0",
"ip_scn": "NOT_ECT"
},
"tcp": {
"tcp_dst": 21,
"tcp_src": 12345
}
}
}
Response:
output -
{
"packet": {
"uid": "2096432597", // uid to be used all subsequent invocation
"eth": {
"eth_type": "0x0800(IPv4)",
"eth_src": "00:00:00:00:00:06",
"eth_dst": "00:00:00:00:00:05"
},
"ip": {
"ip_proto": "TCP",
"ipv4_src": "10.0.0.6",
"ipv4_dst": "10.0.0.5",
"ip_ident": 0,
"ip_dscp": "CS0",
"ip_ecn": "NOT_ECT"
},
"tcp": {
"tcp_src": 12345,
"tcp_dst": 20
}
}
}Set the observation post on the switch where the destined end host is connected.
NOTE: An alert is generated for an operation such as setting or removing an observation post. These alerts can be viewed by using the Alert Log in the controller UI. | |
Destination end host ( 00:00:00:00:00:05 ) is connected to switch having dpid as 00:00:00:00:00:00:00:01 . Set up an observation post here using below json as request parameter
{"observation": {
"dpid": "00:00:00:00:00:00:00:01", // connected switch from /nodes
"packet_uid": "2096432597" //uid from the create /register packet .
}
}
output -
{
"observation": {
"dpid": "00:00:00:00:00:00:00:01",
"packet_uid": " 2096432597"
}
}Inject the packet onto the network
post /diag/packets/{packet_uid}/action
Use the above URI for generating the packet on to the network.
packet_uid 2096432597 //uid from the create /register packet .
packet_uid 2096432597 //uid from the create /register packet .
{
"observations": [
{85
"dpid": "00:00:00:00:00:00:00:01",
"match":[
{
"in_port":9
},
{
"in_phy_port":9
}
],
"packet_uid": "2096432597",
"status": "OK",
"type": "TCP",
}
}If the packet has reached the destined observation post , it means the connectivity is between the source and the end host is good.
For example, user sees the "status": "OK", // inference packet reached the observation above.
In case the destined observation post has not received the trace packet , it means it is being dropped by one of the intermediate hops.
Get the next hop by providing the source switch datapath id and packet uid and set the observation post on determined next hop. If it is unable to determine next hop , it implies that packet is being dropped at the given switch datapath id.
get /diag/packets/{packet_uid}/nexthops
packet_uid 2096432597 //uid from the create /register packet .
Source switch dpid : 00:00:00:00:00:00:00:02
{
"nexthops": [
{
"dpid": "00:00:00:00:00:00:00:01",
"port": "0x2"
}
]
}Repeat step 7,8,9,10 to determine the switch data path ID where the packet is being dropped.