A reasonable attempt will be made to shorten the output of terms, but
due to the nature of the ACL plugin in VPP, all ACLs will be unrolled
into their individual ACEs (called 'terms').
- src/dst-port will only be emitted with UDP/TCP
- icmp-typc/code will only be emitted with ICMP/ICMPv6
- icmp-code/type and source/destination-ports ranges will be collapsed
where appropriate.
- if protocol is 0, only L3 information will be emitted
NOTE: a bug in the VPP plugin will allow for ICMP 'sport' and 'dport'
upper value to be 16 bits. If an ACE is retrieved from the dataplane
regarding an ICMP or ICMPv6 (referring the 16 bit values to icmp type
and code), they will be truncated and a warning issued.
A reasonable attempt will be made to shorten the output of terms, but
due to the nature of the ACL plugin in VPP, all ACLs will be unrolled
into their individual ACEs (called 'terms').
- src/dst-port will only be emitted with UDP/TCP
- icmp-typc/code will only be emitted with ICMP/ICMPv6
- icmp-code/type and source/destination-ports ranges will be collapsed
where appropriate.
- if protocol is 0, only L3 information will be emitted
NOTE: a bug in the VPP plugin will allow for ICMP 'sport' and 'dport'
upper value to be 16 bits. If an ACE is retrieved from the dataplane
regarding an ICMP or ICMPv6 (referring the 16 bit values to icmp type
and code), they will be truncated and a warning issued.
A reasonable attempt will be made to shorten the output of terms, but
due to the nature of the ACL plugin in VPP, all ACLs will be unrolled
into their individual ACEs (called 'terms').
- src/dst-port will only be emitted with UDP/TCP
- icmp-typc/code will only be emitted with ICMP/ICMPv6
- icmp-code/type and source/destination-ports ranges will be collapsed
where appropriate.
- if protocol is 0, only L3 information will be emitted
NOTE: a bug in the VPP plugin will allow for ICMP 'sport' and 'dport'
upper value to be 16 bits. If an ACE is retrieved from the dataplane
regarding an ICMP or ICMPv6 (referring the 16 bit values to icmp type
and code), they will be truncated and a warning issued.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
These functions will take either an IPv4/IPv6 address, or an IPv4/IPv6
prefix, and cast them to their canonical form. Notably for IPv6 addresses,
this means lower case and with the 0-tuples correctly formatted:
2001:DB8::1 becomes 2001:db8::1
2001:db8:0:0::1 becomes 2001:db8::1
This avoids spurious diffs in vppcfg when comparing to the output of the VPP
dataplane.
