Web UI also rejects 0.0.0.0/8 with the same message. If /0 is the sole member of source_groups or destination_groups, it is easy to deal with: we can just use ANY. However, if we have 0.0.0.0/8 as a, for example, part of set subtraction, then this is not the right way out. I'd say it's a bug in NSX-T to not support these use cases: it will happily accept 0.0.0.1 as a valid IP, but not as a part of the subnet spec.
Additionally, if we have port range consisting of one port (e.g. 1234-1234) this will get rejected, and 1234 should be submitted. Otherwise we get this HTTP 400 error (it was guesswork which of the rules caused it, but it looks like 1234-1234 was the culprit).
Invalid port provided while creating/updating Service / ServiceEntry.
Internal code change created which should resolve the immediate pain of these two issues. Once submitted internally, it should be published externally too.
0.0.0.0/[anything]
is rejected with HTTP 400:Web UI also rejects 0.0.0.0/8 with the same message. If
/0
is the sole member ofsource_groups
ordestination_groups
, it is easy to deal with: we can just useANY
. However, if we have0.0.0.0/8
as a, for example, part of set subtraction, then this is not the right way out. I'd say it's a bug in NSX-T to not support these use cases: it will happily accept0.0.0.1
as a valid IP, but not as a part of the subnet spec.Additionally, if we have port range consisting of one port (e.g.
1234-1234
) this will get rejected, and1234
should be submitted. Otherwise we get this HTTP 400 error (it was guesswork which of the rules caused it, but it looks like1234-1234
was the culprit).