Virtual Chassis Fabric – Part II – Control and Forwarding Plane
In the Virtual Chassis Fabric – Part I – Overview we saw the high level details of VCF technology proposed by Juniper for small to mid-size datacenter.
In this post we are going to discuss about the control and forwarding planes of VCF.
The strong ties between forwarding plane and its discovery mechanism and the control plane allows VCF technology to provide several enhancements:
- Fabric Multipath – when data needs to be sent between nodes, all shortest paths inside VCF will be used
- Bandwidth Allocation – the source node will take into consideration the end-to-end bandwidth for each path and distribute the flows based on each path weight
- Bidirectional Multicast Distribution Trees – created to choose forwarding paths for BUM traffic between VCF nodes
Control Plane
- Up to 4 Routing Engines(only two active at a time)
- Inband control plane(control plane traffic runs over the VCPs)
- VCCPD(based on ISIS) runs on all VCF nodes
- Separate queues used for VCCP control plane data
- Shortest path calculation for unicast traffic forwarding
- MDT creation for BUM traffic forwarding
Topology Discovery
- VCCP runs on every node for a free loop topology
- LSA messages exchanged between all nodes to create topology maps
- SPF is run to create map tables between all nodes(multiple paths between nodes are available and a weight is assigned to each one of them based on the lowest bandwidth available
- Logical topology is calculated based on the SPF algorithm and how to get from every node to any other node
Smart Trunks
- The capability of allocating link weights based on end-to-end path bandwidth and the capability of differentiating traffic according to its final egress nodes
- Automatic fabric trunks – multiple links between two nodes are placed in a LAG
- Fabric Trunk Types:
- Next Hop Trunk(NHT) – logical link between local node and neighbor node
- Remote Destination Trunk(RD) – logical link between local node and remote destination node
- Multiple paths are available between two nodes
- Each path is weighted based on the bandwidth ratio
This is how automatic LAG and Next Hop Trunks are created:
Considering that the VCP links of LEAF_2 are 10G and 40G, this is how the traffic will be balanced across the two RD trunks. Keep in mind that the minimum bandwidth across all links to reach the specific node is used as baseline. In this case, the lowest bandwidth available is 10G:
Fabric Header and Load Balancing
- Fabric Header
- 16 bytes header added to ingressing VCF packets
- Some of the fields are: source member ID, destination member ID, incoming Port ID, destination Port ID
- Added by the ingres FPC and removed by the egress FPC
- Used to forward traffic in VCF
- Forwarding of the encapsulated frame is done by only fabric header lookup
- 16 bytes header added to ingressing VCF packets
- Load Balancing
- All RD Trunks are used considering the following hash:
- Layer 2: source MAC, destination MAC, Ethertype, Vlan ID, Incoming Port ID, source member ID
- IPv4: source IP, destination IP, source port, destination port, incoming Port ID, source member ID
- IPv6: source IP, destination IP, source port, destination port, incoming Port ID, source member ID, Next Header
- The hash algorithm cannot be modified
- All RD Trunks are used considering the following hash:
Multicast Distribution Trees
- Central mechanism for loop avoidance in forwarding of multicast, broadcast and flooding traffic inside the VCF
- Calculated using the Bread-First Search (BFS) algorithm rooted at any selected PFE node
- Load balancing based on VLAN ID
- Carries traffic bidirectionally between FPCs
- Multiple MDTs are calculated for BUM load balancing
- BUM and flooding traffic are assigned to a particular MDT based on its VLAN-ID, while known multicast traffic are load balanced to MDTs at the granularity of multicast next-hops
- The VCF creates the same number of MDTs as members in the VCF and each MDT has one of the members as its root node( number of FPCs will match the number of MDTs)
MAC Learning
- Ingress FPC receives a frame with unknown source MAC address
- Ingress FPC learns the source MAC address
- If:
- The ingress FPC is the master RE, then it programs the MAC address on all other members
- The ingress FPC is not the master RE, then it notifies the master RE about the new MAC and the master RE programs the new MAC address on all the other members
Traffic Forwarding
- BUM Traffic:
- The ingress FPC forwards the traffic to all FPC using MDT
- The destination FPCs remove the fabric header and forwards the frame on all interfaces part of the VLAN
- Known Unicast:
- Ingress FPC performs MAC lookup to find the destination FPC
- Ingress FPC chooses the NHT based on hash and forward the frame to spine FPC after the fabric header is prepended
- Spine FPC performs a fabric header lookup and forwards the frame to the destination FPC
- The destination FPC removes the fabric header and forwards the original frame out of the egress interface
The diagram should help you understand between how known unicast forwarding is happening inside VCF:
This would be pretty much all how Virtual Chassis Fabric is functioning at control and forwarding planes level and what features is using in order to become one of the preferred technology to be used in medium-size datacenters.
I hope you found this post and this series interesting.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Hi, I found your article here. I have a question. If 2 hosts reside on the same leaf, will they communicate to spine if they communicate with each other?
It stays local, the traffic does not need to go to the leaf and come back.
Thanks,
Paris