We have been working with PNSC 3.0(2e) and VSG 4.2(1)VSG2(1.1) running on top of 1000v switch 4.2(1)SV2(2.1a).
We are using VMWare 5.5.
Note: These are not Cisco Licenses, they are running in a Licensed VMWare Plus platform and we have downloaded these from Cisco Downloads - we are aware that this could be the problem but can't find any documentation specifically stating this.
This is a simple question, in the documentation it mentions that a limit of 10 conditions or attributes can be placed in a rule (this is give as 10 per rule) in Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide, Release 4.2(1)VSG1(1) - Cisco Virtual…
We configured a rule with more than this and it caused the policy not apply to the VSG. The status in PNSC showed the failure and although everything continued to function it wouldn't work. So we modified our rules and split out the destination conditions into multiple rules and re-applied and it started to work. We found that the limit in the destination (ip address) field was 8 and at the time I think there were 2 in the source (port-groups).
Now however, we are finding that on a rule that only has 2 conditions where the source is a port-group and the destination is an IP, the 9th host that inherits that port-group (the port-group has max-ports set to 30), has all sorts of issues, doesn't get/keep dhcp, loses the will to live etc!
The config is as follows:
port-profile type vethernet ten1-abcd-1
switchport mode access
switchport access vlan 424
vservice node tenant1-vsg profile abc-c-abcd-profile
Veth Mod VM-Name vNIC IP-Address
7 6 abc-c-abcd006 1 192.168.10.70
8 4 abc-c-abcd008 1 192.168.10.72
23 5 abc-c-abcd004 1 192.168.10.68
24 3 abc-c-abcd009 1 192.168.10.73
25 6 abc-c-abcd005 1 192.168.10.69
30 4 abc-c-abcd011 1 192.168.10.75
31 3 abc-c-abcd012 1
35 3 abc-c-abcd010 1 192.168.10.74
36 6 abc-c-abcd007 1 192.168.10.71
custom-attribute vnsporg "root/tenant1/c1"
rule ten1-abcd-inbound/abcd-443@root/tenant1/c1 cond-match-criteria: match-all
condition 10 dst.vm.portprofile-name eq ten1-abcd-2
condition 12 dst.vm.portprofile-name eq ten1-abcd-1
condition 13 src.net.ip-address member-of poc-snat-ten1-t2@root/tenant1/c1
condition 11 net.service member-of ssl_port@root/tenant1/c1
rule ten1-abcd-outbound/1025_port@root/tenant1/c1 cond-match-criteria: match-any
condition 12 dst.net.ip-address member-of ababababab.dc.cert@root/tenant1/c1
condition 10 src.vm.portprofile-name eq ten1-abcd-2
condition 13 src.vm.portprofile-name eq ten1-abcd-1
condition 11 net.service member-of 1025_port@root/tenant1/c1
rule ten1-abcd-inbound/abcd-443@root/tenant1/c1 order 1804
rule ten1-abcd-outbound/1025_port@root/tenant1/c1 order 3105
Please note, I have replaced/removed all references to business specific architecture and IP ranges, however the construct remains the same. I have also removed the majority of rules for brevity and the point remains the same, for either inbound or outbound we are faced with the same issues.
I hope someone can give some guidance on these limits - are we actually limited by the attribute/condition barrier when related to port-profiles configured inside source/destination of a rule?