[openflowplugin-dev] OF 1.3 testing
|
Ed Warnicke (eaw) <eaw@...>
Luis,
toggle quoted message
Show quoted text
Just glancing at your screen caps, I notice “Packet size limited during capture” in the one on the bottom.
Was the capture done in Wireshark or using tcpdump? If tcpdump, did you use the -s 0 flag to cause it to
capture the whole frame? By default tcpdump only captures the first 116 bytes of the packet.
Ed
On Dec 17, 2013, at 3:51 PM, Luis Gomez <luis.gomez@...> wrote:
|
|
|
|
Madhusudhan Kandadai <madhusudhan.opendaylight@...>
Hi Ed, Yes, Luis and I worked with a couple of commands and we did try using -s 0 flag that you mentioned i.e., tcpdump -s 0 -w test1.pcap Regards, Madhusudhan On Wednesday, December 18, 2013 7:30 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Luis,
Just glancing at your screen caps, I notice “Packet size limited during capture” in the one on the bottom.
Was the capture done in Wireshark or using tcpdump? If tcpdump, did you use the -s 0 flag to cause it to
capture the whole frame? By default tcpdump only captures the first 116 bytes of the packet.
Ed
On Dec 17, 2013, at 3:51 PM, Luis Gomez <luis.gomez@...> wrote:
_______________________________________________ integration-dev mailing list integration-dev@... https://lists.opendaylight.org/mailman/listinfo/integration-dev |
|
|
|
Zoltán Lajos Kis <zoltan.lajos.kis@...>
Hi,
I don’t think this is caused by a truncated capture. If you look at the Frame field it clearly shows that 110 out of 110 bytes were captured. I think that text is actually generated by the OpenFlow dissector, as it never receives the complete OF message from the TCP stream. As you can see the flow_mod message is supposed to be 64 bytes long, but only the first 44 bytes arrives in the TCP segment, and then the TCP stream ends (at least in the capture file).
If you look at the pcap file sent by Luis earlier [1], something similar happens. A flow_mod of 64 bytes is supposed to be sent. In frame 5 44 bytes of this arrives. This is followed by frame 7, which carries an echo reply message (and of course confuses the dissector). Then this TCP stream is ends, and five seconds later the hello restarts using another client port.
Another weird thing to look into is that the flow_mod described in the restconf request [2] should be longer than 64 bytes. If my math is right, the generated message should take 88 bytes: - 8 bytes – openflow header - 40 bytes - ofp_flow_mod body (w/o match and instructions) - 24 bytes - ofp_match (4b) with an eth_type exact match (6b), and an ipv4 masked match (12b) and padding (2b) - 8 bytes – ofp_instruction_actions (w/o actions) - 8 bytes – ofp_action_header (for dec_nw_ttl)
Best Regards, Zoltan
[1] https://lists.opendaylight.org/pipermail/openflowplugin-dev/2013-December/000400.html, controller_flow_push.pcap [2] https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:End_to_End_Flows#Push_your_flow
From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...]
On Behalf Of Ed Warnicke (eaw)
Sent: Thursday, December 19, 2013 4:30 AM To: Luis Gomez Cc: integration-dev@...; openflowplugin-dev@... Subject: Re: [openflowplugin-dev] OF 1.3 testing
Luis, Just glancing at your screen caps, I notice “Packet size limited during capture” in the one on the bottom. Was the capture done in Wireshark or using tcpdump? If tcpdump, did you use the -s 0 flag to cause it to capture the whole frame? By default tcpdump only captures the first 116 bytes of the packet.
Ed
On Dec 17, 2013, at 3:51 PM, Luis Gomez <luis.gomez@...> wrote:
Hi Michal,
I am using latest OF plugin + controller build from Jenkins:
I am generating REST PUT request using POSTMAN and instructions in (see attached POSTMAN image):
After executing the PUT, I get answer 200 OK and I can see the flow with GET http://10.125.136.52:8080/restconfig/config/opendaylight-inventory:nodes/node/openflow:1/table/0/
However no flow is available in the switch. When I sniff the packets with Wireshark (using 1.11.3 developer version) I can see in the controller trace a truncated (or malformed) FLOW-MOD packet (see attached FLOW_MOD_RESTCONF image) that does reach the mininet VM because the packet is missing in the mininet trace.
Finally if I try to push the flow from OSGI console: “addMDFlow openflow:1 f2”, it works, see new capture attached FLOW_MOD_mdAddFlow.
BR/Luis
From: Michal
Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) [mailto:mirehak@...]
Hi Luis, From: openflowplugin-dev-bounces@... [openflowplugin-dev-bounces@...]
on behalf of Luis Gomez [luis.gomez@...] Hi OF plugin experts,
I have started testing the E2E flow push at https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:End_to_End_Flows
And I found an issue when pushing the flow from NB API (RESTCONF). As you can see in the attached traces from controller and mininet, the FLOW_MOD message from controller is a truncated packet and as such it never reaches the mininet VM so flow gets never created in the switch. Do you also see this behavior in your setup?
BR/Luis
<Capture_POSTMAN.JPG><Capture_FLOW_MOD_mdAddFlow.JPG><Capture_FLOW_MOD_RESTCONF.JPG>_______________________________________________
|
|
|
|
Luis Gomez <luis.gomez@...>
OK gentlemen, something has definitely changed since I tried last week, now it works with no issues:
mininet@mininet-vm:~\> sudo ovs-ofctl -O OpenFlow13 dump-flows s1 OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=22.197s, table=1, n_packets=0, n_bytes=0, idle_timeout=300, hard_timeout=600, send_flow_rem priority=2,ip,nw_dst=10.0.10.0/24 actions=dec_ttl
Just one more question, is there a way to remove the flow once it gets created?
Thanks/Luis
From: Zoltán Lajos Kis
Sent: Thursday, December 19, 2013 2:49 AM To: Ed Warnicke (eaw); Luis Gomez Cc: integration-dev@...; openflowplugin-dev@... Subject: RE: [openflowplugin-dev] OF 1.3 testing
Hi,
I don’t think this is caused by a truncated capture. If you look at the Frame field it clearly shows that 110 out of 110 bytes were captured. I think that text is actually generated by the OpenFlow dissector, as it never receives the complete OF message from the TCP stream. As you can see the flow_mod message is supposed to be 64 bytes long, but only the first 44 bytes arrives in the TCP segment, and then the TCP stream ends (at least in the capture file).
If you look at the pcap file sent by Luis earlier [1], something similar happens. A flow_mod of 64 bytes is supposed to be sent. In frame 5 44 bytes of this arrives. This is followed by frame 7, which carries an echo reply message (and of course confuses the dissector). Then this TCP stream is ends, and five seconds later the hello restarts using another client port.
Another weird thing to look into is that the flow_mod described in the restconf request [2] should be longer than 64 bytes. If my math is right, the generated message should take 88 bytes: - 8 bytes – openflow header - 40 bytes - ofp_flow_mod body (w/o match and instructions) - 24 bytes - ofp_match (4b) with an eth_type exact match (6b), and an ipv4 masked match (12b) and padding (2b) - 8 bytes – ofp_instruction_actions (w/o actions) - 8 bytes – ofp_action_header (for dec_nw_ttl)
Best Regards, Zoltan
[1] https://lists.opendaylight.org/pipermail/openflowplugin-dev/2013-December/000400.html, controller_flow_push.pcap [2] https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:End_to_End_Flows#Push_your_flow
From:
openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...]
On Behalf Of Ed Warnicke (eaw)
Luis, Just glancing at your screen caps, I notice “Packet size limited during capture” in the one on the bottom. Was the capture done in Wireshark or using tcpdump? If tcpdump, did you use the -s 0 flag to cause it to capture the whole frame? By default tcpdump only captures the first 116 bytes of the packet.
Ed
On Dec 17, 2013, at 3:51 PM, Luis Gomez <luis.gomez@...> wrote:
Hi Michal,
I am using latest OF plugin + controller build from Jenkins:
I am generating REST PUT request using POSTMAN and instructions in (see attached POSTMAN image):
After executing the PUT, I get answer 200 OK and I can see the flow with GET http://10.125.136.52:8080/restconfig/config/opendaylight-inventory:nodes/node/openflow:1/table/0/
However no flow is available in the switch. When I sniff the packets with Wireshark (using 1.11.3 developer version) I can see in the controller trace a truncated (or malformed) FLOW-MOD packet (see attached FLOW_MOD_RESTCONF image) that does reach the mininet VM because the packet is missing in the mininet trace.
Finally if I try to push the flow from OSGI console: “addMDFlow openflow:1 f2”, it works, see new capture attached FLOW_MOD_mdAddFlow.
BR/Luis
From: Michal
Rehak -X (mirehak - Pantheon Technologies SRO at Cisco) [mailto:mirehak@...]
Hi Luis, From: openflowplugin-dev-bounces@... [openflowplugin-dev-bounces@...]
on behalf of Luis Gomez [luis.gomez@...] Hi OF plugin experts,
I have started testing the E2E flow push at https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:End_to_End_Flows
And I found an issue when pushing the flow from NB API (RESTCONF). As you can see in the attached traces from controller and mininet, the FLOW_MOD message from controller is a truncated packet and as such it never reaches the mininet VM so flow gets never created in the switch. Do you also see this behavior in your setup?
BR/Luis
<Capture_POSTMAN.JPG><Capture_FLOW_MOD_mdAddFlow.JPG><Capture_FLOW_MOD_RESTCONF.JPG>_______________________________________________
|
|
|