Configuring Network Resources

When configuring some network resources, you must be aware of certain restrictions.

Limits on Tags and Labels

Tags have the following limits:

The tag scope has a limit of 128 characters.
The tag value has a limit of 256 characters.
Each object can have a maximum of 30 tags.

These limits might cause issues when Kubernetes or OpenShift annotations are copied to NSX scopes and tags and the limits are exceeded. For example, if a tag is for a switch port and the tag is used in a firewall rule, the rule might not be applied as expected because the annotation key or value was truncated when copied to a scope or tag.

Labels have the following limits:

A pod can have no more than 25 labels.
A namespace can have no more than 27 labels.
An Ingress controller pod can have no more than 24 labels.

Network Policies

A NetworkPolicy resource has the following limitations:

A podSelector or namespaceSelector cannot have more than 4 matchLabels.
In an ingress from section or egress to section, if you have a single element that specifies both namespaceSelector and podSelector, the namespaceSelector must not select more than 5 namespaces. Otherwise, you will get an error. An example of such a specification (notice that there is no hyphen before podSelector):
```
- namespaceSelector:
    matchLabels:
      project: myproject
  podSelector:
    matchLabels:
      role: db
```

For any ingress or egress rule, the total number of namespaceSelectors plus podSelectors cannot be more than 5. For example, the following is not allowed because the rule has a total of 6 selectors:

ingress:
    - namespaceSelector:
        matchLabels:
          project: myproject1
    - namespaceSelector:
        matchLabels:
          project: myproject2
    - namespaceSelector:
        matchLabels:
          project: myproject3
    - podSelector:
        matchLabels:
          role: db
    - podSelector:
        matchLabels:
          role: app
    - podSelector:
        matchLabels:
          role: infra

Allow-all-egress network policy with namedPorts in the to.ports section is not supported.
In Policy mode, when specifying matchExpressions in podSelector or namespaceSelector, at most one In operator is allowed. If you specify both namespaceSelector and podSelector, you can have at most one In operator for one of them. You cannot have an In operator for both of them. For example, the following specification is not allowed:
```
    - namespaceSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
      podSelector:
        matchExpressions:
        - {key: key1, operator: In, values: [value1]}
```
In Manager mode, when specifying matchExpressions in podSelector, namespaceSelector, or both namespaceSelector and podSelector, there is no restriction on the number of In operators.
Network policy with SCTP in the protocol field is not supported.

To work around the limitations, you can create a network policy with matchLabels that are more specific, or replace one network policy with several network policies that do not require more than 5 selectors.

If a network policy is not supported by NCP, NCP will annotate it with an error. You can update the network policy to fix the error and NCP will process it again.

If a network policy has only egress specified but not ingress, no firewall rule is created for ingress traffic. Similarly, if a network policy has only ingress specified but not egress, no firewall rule is created for egress traffic.

When NSX App ID firewall rules are applied to resources created by NCP, only the "Segment" and "Segment Port" group membership criteria are supported. Note that the App ID firewall rule feature is supported only if NCP is configured to use NSX policy API.