SD-WAN

Hello,

I'm working with HP controller. We have our own Linux deployed OpenFlow switch which connects to the controller.

The Topology is simple:

             [c]

               |

[h1]--[s]--[h2]

The TCP\OF connection is established. I have 1 default rule on the switch to send all packets to Controller.

1. I'm pinging from h1 to h2. 

2. Ping Packet goes to controller as Packet-in.

3. I'm expecting the controller to let a Packet-out for that, fill up an appropriate action in PO header, i.e. NORMAL, FLOOD etc.

4. But the Controller does not forwards and Packet-out. IS THIS EXPECTED?

My expectation is that Controller forwards the Ping Packet everytime. Am I wrong here?
Can the Controller not send the Packet-out in a certain scenario? If so, what is it?

I hope I'm clear. Please let me know if you need more info.

With Regards,

Vishal

Hi Vishal,

Yes, this would be the expected behavior of the HP VAN SDN controller if no application with a listener for the specific Packet-in traffic has been deployed on it, which assumedly is the case in your situation:

Traffic forwarded to the controller channel is handled by the SequencedPacketListener (SPL) API of the HP VAN SDN Controller (see chapter 11.2.5 Packet sequencer and packet listeners of the HP VAN SDN Controller 2.5 Programmers Guide ) . This API allows multiple packet listeners from a single or multiple applications to be deployed and active simultaneously on the HP VAN SDN Controller as can be seen in the following diagram:

The above mentioned section in the manual has detailed information on the mechanism, but in short a received Packet-In is presented as part of a MessageContext object by the API sequentially to all Sequential Packet Listeners (SPL) that have subscribed to that type of traffic. A SPL that has the Director role can instruct the PacketSequencer to send out a Packet-Out that has been constructed in the MessageContext object based on the Packet-In by it (or by SPLs earlier in the chain). SPLs later in the chain can see a Packet-Out has already been sent because the IsHandled() method of the MessageContext object returns true from that point onwards. After the MessageContext object has been presented to the last SPL it is discarded (Ground symbol in the diagram), even if no director SPL has send a Packet-Out at this point (the default situation on a controller without any applications deployed).

Let me know if this is of any help!

Best regards,

Wouter

HP SDN CoE Team

Hi Wouter,

Thanks a lot for the response.

There are a few points I would like to mention:

1. The Traffic type for Packet-IN is ping(ICMP). We were quite sure that HP Controller would handle ICMP traffic and would let out a Packet-OUT without the need of an application. Just wanted to re-confirm are you sure Controller does NOT handles ICMP traffic by default and discards all traffic as you mentioned?

2. Our Switch is in developmental phase and we're getting some Flow-mod failure errors in logs.log file generated in Controller logs. I'm attaching the same file.

To be specific, "FlowMod Adjust Failed" error is returned for 4 default flows sent by Controller:

{FMA} Device driver framework:- FlowMod Adjust Failed: dpid=02:03:04:05:00:00:00:01, dtn=Default OpenFlow Switch: {ofm:[V_1_3,FLOW_MOD,120,113],cmd=ADD,match={Match(V_1_3):[type=OXM,len=27],fields=ETH_TYPE,IP_PRO
{FMA} Device driver framework:- FlowMod Adjust Failed: dpid=02:03:04:05:00:00:00:01, dtn=Default OpenFlow Switch: {ofm:[V_1_3,FLOW_MOD,120,114],cmd=ADD,match={Match(V_1_3):[type=OXM,len=27],fields=ETH_TYPE,IP_PRO
{FMA} Device driver framework:- FlowMod Adjust Failed: dpid=02:03:04:05:00:00:00:01, dtn=Default OpenFlow Switch: {ofm:[V_1_3,FLOW_MOD,88,115],cmd=ADD,match={Match(V_1_3):[type=OXM,len=10],fields=ETH_TYPE},...}
{FMA} Device driver framework:- FlowMod Adjust Failed: dpid=02:03:04:05:00:00:00:01, dtn=Default OpenFlow Switch: {ofm:[V_1_3,FLOW_MOD,104,116],cmd=ADD,match={Match(V_1_3):[type=OXM,len=10],fields=ETH_TYPE},...}

This is specifically because we don't yet support NORMAL output action. I'm doubtful if this is because of the errors generated, the Controller develops an "invalid state" for the switch which results in Controller not forwarding packet-OUT in our case.

3. But then again, I've also tried HP Controller+Mininet Switch which accepts those 4 flows, but still, ping from host1 to host2 results in Packet-IN to controller+NO packet out.

To conclude, we're trying to root out the minor possibility that the issue is with our Switch.
Could you please go through the logs file and let me know if we're missing something here.

Thank you again!

With Regards,
Vishal

Attachment(s)

logs.log.zip   703 B 1 version

Hi Vishal,

The HP VAN SDN controller does not automatically generate Packet-outs for any traffic that is send to it with Packet-ins. For that to happen there always needs to be an application (with a SPL) active on the controller. ICMP traffic is not an exception to this rule. The rationale behind this is that the HP VAN SDN controller can’t “know” what the user’s intention with the traffic is. For example ICMP traffic might be a harmless PING between two hosts, or it might be traffic redirected to the controller to investigate whether it is part of malicious activities. For the first scenario Packet-outs would always have to be generated, for the second one the opposite might be required.

From the log you attached I can see that the controller is in hybrid mode (see the HP VAN SDN Controller 2.5 Administrator Guide section 6 - Hybrid mode for controlling packet forwarding). In hybrid mode the Controller lets the switch decide what to do with traffic that no explicit flows were set for. In other words the default flow when traffic doesn’t match any other flow set on the switch has action forward normal. Since your switch does not yet support forward normal, hybrid mode is not going to work with it and I would suggest to turn it off (above mentioned section has information on how to do that).

Because in hybrid mode by default no traffic is send to the controller, it would not be able to determine the topology of the network. Therefore when using hybrid mode the controller sets flows on the switch that copy/steal certain types of traffic (ARP, DHCP, BDDP) and send it to the controller so that it can build a topology:

All other traffic is left to be handled by the switch (ICMP is indicated as example) unless it is handled by a controller application, the HP Protector (DNS) and Optimizer (QoS for MSFT Lync traffic) are given as examples in the figure.

I suspect that the flowmods you see fail are the flows that the controller tries to set for building a topology in hybrid mode, but the log does not show enough detail on them to determine that. A packet capture would show more detailed information. Let me know if this is of any help!

Best regards,

Wouter

HP SDN CoE Team

Hi Wouter,

Sorry for the late response. And thank you for the help!

As you explained, the Controller was able to forward Packet-Out once I changed the Hybrid mode to False.

So to get the Controller to forward PO in Hybrid mode, we ought to deploiy an application which listens to the specific type of traffic.

Thank you,

Vishal