SDN HP3800 switch broadcast fault

[ShaunWackerly]

Hi Dave,

One more follow-up: I think the condition you're hitting is that you're issuing a group update (PUT) with the same port values as already exist on the switch. If any of the port values are different, the group update should be accepted. Could you please confirm that this is the only case where you're seeing this behavior? We'll hopefully get a duplicate group update accepted in a future revision of firmware. For now, if the group update (PUT) is rejected, please verify that the group is already set as expected (using GET) and that will confirm that you've hit this situation. If you hit this situation, you'd only need to ignore the rejection.

Shaun

[Dave-B]

Shaun,

Thanks for the reply.  I'm only getting the error when either port 11 or port 13 is already in group 3. In my S/W, groups 1 aqnd 2 are used for IGMP messages. Ports 11 and 13 are also in group 1. If I modify group3 for completely different ports (49 and 50), there is no error.

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups
{"version":"1.3.0","groups":[{"id":1,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":13}]}]},{"id":2,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":5}]}]},{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]}]}]}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups/3" -d "{\"version\": \"1.3.0\",\"group\": {\"id\": 3,\"type\": \"all\",\"command\": \"modify\",\"buckets\": [{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 11}]},{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 13}]}]}}" --request PUT
{"error":"java.lang.IllegalArgumentException","message":"{ofm:[V_1_3,ERROR,76,1052612],GROUP_MOD_FAILED/EPERM,#dataBytes=64,OFM-cause:[V_1_3,GROUP_MOD,80,1052612]}"}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups"
{"version":"1.3.0","groups":[{"id":1,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":13}]}]},{"id":2,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":5}]}]},{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]}]}]}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups/3" -d "{\"version\": \"1.3.0\",\"group\": {\"id\": 3,\"type\": \"all\",\"command\": \"modify\",\"buckets\": [{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 49}]},{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 50}]}]}}" --request PUT
{"version":"1.3.0","group":{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":49}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":50}]}]}}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups"
{"version":"1.3.0","groups":[{"id":1,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":13}]}]},{"id":2,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":5}]}]},{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":49}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":50}]}]}]}

The problem could be due to pre-exisitng groups or groups which are processing data. Groups 1 and 2 are for IGMP and have almost no bit rate. Group 3 is processing packets at approx 50Mb/s. If I create the group3 and its flows befoe groups 1 and 2 and there is no stream of data, then there is no error. e.g.

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups" -d "{\"version\": \"1.3.0\",\"group\": {\"id\": 3,\"type\": \"all\",\"command\": \"add\",\"buckets\": [{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 11}]}]}}" --request POST

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/flows" -d "{\"flow\": {\"priority\": 20001,\"table_id\":100,\"idle_timeout\": 60000,\"match\": [{\"ipv4_src\":\"10.0.0.100\"},{\"ipv4_dst\":\"232.1.3.1\"},{\"eth_type\": \"ipv4\"}],\"instructions\": [{\"apply_actions\": [{\"group\": 3}]}]}}" --request POST

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups"
{"version":"1.3.0","groups":[{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]}]}]}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups/3" -d "{\"version\": \"1.3.0\",\"group\": {\"id\": 3,\"type\": \"all\",\"command\": \"modify\",\"buckets\": [{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 11}]},{\"weight\": 0,\"watch_group\": 4294967295,\"watch_port\": \"ANY\",\"actions\": [{\"output\": 13}]}]}}" --request PUT
{"version":"1.3.0","group":{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":13}]}]}}

curl --header "X-Auth-Token:$AUTH_TOKEN" -H "Content-Type:application/json" -ksS --url "https://192.168.40.180:8443/sdn/v2.0/of/datapaths/00:02:34:64:a9:59:8a:00/groups"
{"version":"1.3.0","groups":[{"id":3,"type":"all","buckets":[{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":11}]},{"weight":0,"watch_group":4294967295,"watch_port":"ANY","actions":[{"output":13}]}]}]}

Dave.

[ShaunWackerly]

Hi Dave,

If I could summarize the actions in your last response, it would be this:

GET: Group1 {11,13} Group2 {5}, Group3 {11}

PUT: Group3 {11,13} -- Fails because this exactly matches the ports in Group1

GET: Group1 {11,13} Group2 {5}, Group3 {11}

PUT: Group3 {49,50} -- Succeeds because no other group is exactly {49,50}

GET: Group1 {11,13} Group2 {5}, Group3 {49,50}

The workaround you'd need to use would be one of the following:

1. Keep track of which groups contain which ports, to know when updating group3 will make it identical to group1. If they'd be identical, then update flows to refer to group1 rather than group3. If you have a small number of flows, this may be feasible, however updating a flow may potentially drop packets while the entry is updated in the switch.
2. Add an unused port to group3, to ensure that it is never identical to any other group. Since your groups have type 'all', this should not have any other affects.

Would either of these be acceptable workarounds?

[Dave-B]

Shaun,

Thanks for the reply. Groups 1 and 2 have different flow rules assocaited with them. The flow rules are for the IGMP query and response multicast addresses, so the match fields are different. e.g.

Group1 matches ipv4_dst: 224.0.0.1 for IGMP

Group 2 matches 224.0.0.22 for IGMP

Group 3 matches ipv4_src: 232.1.3.1 and ipv4-dst: 10.0.0.100 for a SSM video.

For my destinations to receive video or another SSM stream, ideally I need groups that can have the same ports. I can use flow rules without groups for my IGMP flows, but each destantion should be able to receive mulitple SSM streams.

Dave.

[Dave-B]

It is also not possible to modify a group where the ports are already used in a normal match flow, e.g.

add match 224.0.0.11, action: outpt port 11, output port 13 - works.

add group 1: output port 11 - works.

add match 232.1.31., action group 1 - works.

modify group 1: output port 11, output port 13 - fails.

However if ports 11 and 13 are not used in any other groups or any other flows, then the group can be modified to add a port to the list of ports.

[ShaunWackerly]

Hi Dave,

Just to be clear: the behavior you should see is that a group add/modify will fail if that EXACT set of ports matches another group. In your case above, group3 failed because the ports in it (11,13) exactly matched the ports in group1 (11,13). If you add another port to either group1 or group3, both will be accepted.

For example, the following sequence should work and give the desired behavior if port 20 is disconnected:

• add group 1: output port 11, 13
• add match 224.0.0.11, action: group 1
• add group 3: output port 11, 13, 20
• add match 232.1.3.1, action group 3

After the above sequence, both 224.0.0.11 and 232.1.3.1 will forward to ports 11 and 13, but will be using different groups.

Please let us know if this does not work for you, or if you're seeing other behavior. Thanks!

Shaun

[Dave-B]

Shaun,

It also fails if the ports in the group match ports used in a non-group match action (i.e. actions: output 11, output 13, then modifiy group 1 : 11, 13).

I will try adding a disconected port to my port group.

Ideally I need multiple groups that can contain both the same and different ports. The ports in each group will change as destiantions join and leave different multicast streams.

Thanks,

Dave.

[Dave-B]

Shaun,

Adding an unused port to the group, so there are no identical groups, works.

Thanks,

Dave.

[ShaunWackerly]

Hi Dave,

Will this workaround be sufficient for you to use long-term in your application? If so, please mark the thread as having an accepted solution. If not, could you give more details as to why this workaround (including an unused port) would not be acceptable and which timeframe it would be acceptable for?

Shaun

[Dave-B · Accepted solution]

Shaun,

This solution (dummy NC ports) and the other solution (only unqiue groups per switch) are OK for the proof of concept I'm doing. The group action works much better than adding multiple ouptu ports in the flow action.

I can see why only allowing unique groups is a good idea, it reduces the number of group ids needed in each switch. However, it does mean that an application has to keep track of more flow data and potentially increases the number of REST get/put/post for each event.

Is only allowing unique groups somehting required by the OF1.3 spec, or a design decsison by the HP enginners? Are there anny issues with number of groups / group id?

This is an R&D project, I don't have a time scale for going from PoC to real service.

It would be nice if there was the flexibility of non-unique groups. It does make it easier to see what the app is doing by looking at the Controller OF monitor and it makes the app simpler to implement. Either way it is possible to work agroud the issue.

Thansk for the help, Dave.