Configuring Protocol Transparency and Bidirectional VPGs for NPB
Netvisor ONE version 6.1.0 introduces protocol transparency for Network Packet Broker (NPB) solution, where you can configure NPB to copy control plane traffic from a desired source to a destination. In the absence of protocol transparency, the control plane traffic that originates from a switch is generally processed or dropped by the next hop switch. With protocol transparency, the traffic belonging to various Layer 2, Layer 3, and Layer 4 protocols can be sent to switches located anywhere but within the fabric. These control plane protocols include:
Layer 2: LLDP, STP, LACP, and VLAN
Layer 3: IPv4 and IPv6
Layer 4: TCP, UDP, and ICMP
Layer 4 ports: HTTP, DNS, and DHCP
Consider the sample topology below:
Figure 11-4: Protocol Transparency for Network Packet Broker
In figure 11-4 above, Host1 is connected to VPG-1 which includes the trunk port 275 of Leaf1. Similarly, Host2 is connected to VPG-2 which includes the trunk port 273 of Leaf2. To create the above configuration, follow the steps below:
Configure source and destination VPGs using the vpg-create command:
CLI (network-admin@Leaf1) > vpg-create name VPG-1 type source ports 275
CLI (network-admin@Leaf2) > vpg-create name VPG-2 type destination ports 273
Use the vpg-show command to view the configuration.
CLI (network-admin@Leaf1) > vpg-show
switch scope name type ports vni vlan
------ ------ ----- ------------- ----- -------- ----
Leaf1 fabric VPG-2 destination 12500001 2751
Leaf2 fabric VPG-2 destination 273 12500001 2751
Leaf3 fabric VPG-2 destination 12500001 2751
Leaf4 fabric VPG-2 destination 12500001 2751
Leaf5 fabric VPG-2 destination 12500001 2751
Leaf6 fabric VPG-2 destination 12500001 2751
Spine1 fabric VPG-2 destination 12500001 2751
Spine2 fabric VPG-2 destination 12500001 2751
Leaf1 fabric VPG-1 source 275 12500000 2750
Leaf2 fabric VPG-1 source 12500000 2750
Leaf3 fabric VPG-1 source 12500000 2750
Leaf4 fabric VPG-1 source 12500000 2750
Leaf5 fabric VPG-1 source 12500000 2750
Leaf6 fabric VPG-1 source 12500000 2750
SPine1 fabric VPG-1 source 12500000 2750
Spine2 fabric VPG-1 source 12500000 2750
To enable protocol transparency while also configuring a vFlow to direct the traffic from VPG-1 to VPG-2, use the vflow-create command:
CLI (network-admin@Leaf1) > vflow-create
|
vflow-create |
Create a vFlow |
|
name |
Specify the name of the vFlow. |
|
scope |
Specify the scope of the vFlow. |
|
src-vpg |
Specify the source VPG. |
|
dst-vpg |
Specify the destination VPG. |
|
bidir-vpg-1 |
Specify the name of the first bidirectional vFlow. |
|
bidir-vpg-2 |
Specify the name of the second bidirectional vFlow. |
|
transparency enable|disable |
Specify if you want to enable or disable protocol transparency. |
CLI (network-admin@Leaf1) > vflow-create name flow1 scope fabric src-vpg VPG-1 dst-vpg VPG-2 transparency
A basic vFlow configuration without protocol transparency does not allow control traffic such as LLDP packets from Host1 to reach Leaf2. Therefore, Leaf1 sees just Host1 as its LLDP neighbor. However, if you enable protocol transparency, Host2 views Host1 as an LLDP neighbor.This is because the protocol transparent vFlow sends all control packets including LLDP packets to Host2.
When you enable protocol transparency, Netvisor ONE automatically configures additional vFlows to ensure that the control traffic reaches the destination VPG. This auto-configuration is necessary as system vFlows generally consume the protocol traffic and therefore, there must be pathways for the control traffic to bypass system vFlows. These additional vFlows and the user-configured vFlow can be viewed by running the vflow-show command at the source and destination switches:
CLI (network-admin@Leaf1) > vflow-show format all layout vertical
name: flow1
id: b0022cd:1a9
scope: fabric
type: vflow
hidden: false
in-port: 275
burst-size: auto
precedence: 3
action-set-svp-value: 0x80000006
log-stats: no
stats-interval: 60
hw-stats: enabled
src-vpg: VPG-1
dst-vpg: VPG-2
transparency: enable
enable: enable
table-name: System-VCAP-table-1-0
name: npb-system-bypass-proto
id: b0022cd:1a8
scope: fabric
type: vflow
precedence: 15
action: none
metadata: 1000
hw-stats: enabled
enable: enable
table-name: System-L1-L4-Tun-1-0
Note that there is an auto-configured vFlow named npb-system-bypass-proto with a high precedence of 15 that bypasses system vFlow treatment for packets at the ingress side.
CLI (network-admin@Leaf2) > vflow-show format all layout vertical
name: npb-tunnel-decap-flow1
id: b0022cf:16e
scope: local
type: vflow
precedence: 15
action: none
vxlan: 12666668
from-tunnel-decap: yes
hw-stats: enabled
enable: enable
table-name: System-L1-L4-Tun-1-0
The auto-configured vFlow on the destination switch bypasses system vFlow treatment for the decapsulated packets at the egress end of tunnels. If you delete the vFlows, the auto-configured NPB tunnels are removed.
A basic vFlow configuration without protocol transparency does not allow control traffic such as LLDP packets from Host1 to reach Leaf2. In this bidirectional VPG configuration with protocol transparency, Host1 and Host2 see each other as LLDP neighbors, as LLDP packets are copied in both directions, that is, from Host1 to Host2 and Host2 to Host1.
Configuring Bidirectional VPGs
Netvisor ONE version 6.1.0 also adds bidirectional capability to VPGs, which implies that a VPG now supports both source and destination functionalities. In other words, the same VPG acts as source port group and forms bridge domains for destination port groups.
Considering Figure 10-4 as the sample topology, you can configure bidirectional VPGs by using the commands:
CLI (network-admin@Leaf1) > vpg-create name VPG-1 type bidirectional ports 275
CLI (network-admin@Leaf2) > vpg-create name VPG-2 type bidirectional ports 273
CLI (network-admin@pavo-dev-leaf2) > vpg-show
switch scope name type ports vni vlan
------ ------ ----- ------------- ----- -------- ----
Leaf1 fabric VPG-2 bidirectional 12500001 2751
Leaf2 fabric VPG-2 bidirectional 273 12500001 2751
Leaf3 fabric VPG-2 bidirectional 12500001 2751
Leaf4 fabric VPG-2 bidirectional 12500001 2751
Leaf5 fabric VPG-2 bidirectional 12500001 2751
Leaf6 fabric VPG-2 bidirectional 12500001 2751
Spine1 fabric VPG-2 bidirectional 12500001 2751
Spine2 fabric VPG-2 bidirectional 12500001 2751
Leaf1 fabric VPG-1 bidirectional 275 12500000 2750
Leaf2 fabric VPG-1 bidirectional 12500000 2750
Leaf3 fabric VPG-1 bidirectional 12500000 2750
Leaf4 fabric VPG-1 bidirectional 12500000 2750
Leaf5 fabric VPG-1 bidirectional 12500000 2750
Leaf6 fabric VPG-1 bidirectional 12500000 2750
Spine1 fabric VPG-1 bidirectional 12500000 2750
Spine2 fabric VPG-1 bidirectional 12500000 2750
You can now configure a vFlow to copy packets between the bidirectional VPGs by supplying the parameters bidir-vpg-1 and bidir-vpg-2 to the vflow-create command.
CLI (network-admin@switch1) > vflow-create name flow2 scope fabric bidir-vpg-1 VPG-1 bidir-vpg-2 VPG-2
To add protocol transparency to the bidirectional VPG configuration, use the command:
CLI (network-admin@switch1) > vflow-modify name flow2 scope fabric transparency enable
Use the vflow-show command to view the auto-configured and user-configured vFlows:
CLI (network-admin@Leaf1) > vflow-show format all layout vertical
name: npb-tunnel-decap-flow2-2
id: b0022cf:18f
scope: fabric
type: vflow
precedence: 15
action: none
vxlan: 12500001
from-tunnel-decap: yes
hw-stats: enabled
enable: enable
table-name: System-L1-L4-Tun-1-0
name: npb-tunnel-decap-flow2-1
id: b0022cf:190
scope: fabric
type: vflow
precedence: 15
action: none
vxlan: 12666667
from-tunnel-decap: yes
hw-stats: enabled
enable: enable
table-name: System-L1-L4-Tun-1-0
name: npb-system-bypass-proto
id: b0022cf:16f
scope: fabric
type: vflow
precedence: 15
action: none
metadata: 1000
hw-stats: enabled
enable: enable
table-name: System-L1-L4-Tun-1-0
name: flow2
id: b0022cd:1e0
scope: fabric
type: vflow
hidden: false
in-port: 275
burst-size: auto
precedence: 4
action-set-svp-value: 0x80000003
log-stats: no
stats-interval: 60
hw-stats: enabled
bidir-vpg-1: VPG-1
bidir-vpg-2: VPG-2
transparency: enable
enable: enable
table-name: System-VCAP-table-1-0
Note that there are two auto-configured vFlows for bypassing system vFlow treatment for the decapsulated packets at the egress end of tunnels. There is also the vFlow named npb-system-bypass-proto that bypasses system vFlows at the ingress side. This vFlow is created when the first transparent vFlow is created and is shared by the subsequent protocol transparent vFlows. The npb-system-bypass-proto vFlow is removed when the last protocol transparent vFlow is removed.
In this bidirectional VPG configuration with protocol transparency, Host1 and Host2 see each other as LLDP neighbors, as LLDP packets are copied in both directions, that is, from Host1 to Host2 and Host2 to Host1.
Guidelines and Limitations
- If you configure a protocol transparent vFlow, you cannot use the set-metadata keyword while modifying the vFlow thereafter. Conversely, if set-metadata is configured for a vFlow, you cannot enable protocol transparency for that vFlow.
- The metadata value of 1000 is reserved for protocol transparency and you cannot use this metadata value while configuring other vFlows.
- All control plane protocols are tunnel transparent if no additional filters are enabled. However, if you specify a vFlow filter, only the control plane packets pertaining to that filter is copied between the VPGs. For example, if you specify a VLAN filter, only the control plane packets belonging to that VLAN are copied. This limitation applies to the global vNET and any user-defined vNET in which vFlows are created with a VLAN filter. As a consequence of this limitation, adjacency over LLDP or LACP fails to be established.