Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Deploy

SUMMARY Cable your data center fabric and deploy your blueprint.

Explanation of Procedure

In the deploy stage, you install and cable your devices, and then push an EVPN-VXLAN configuration to the fabric devices.

If you haven’t pre-wired your fabric, then you can generate a cabling map for your installers to follow.

If you have pre-wired your fabric, Apstra discovers the existing connectivity and updates the reference design. Recall that Apstra assigns port connections arbitrarily, so there’s a chance these arbitrary port assignments differ from the pre-existing wiring. By importing the actual connections back to your blueprint, you’re ensuring that Apstra has an accurate view of the connectivity.

Regardless of which approach you take, when you deploy the configuration, Apstra checks the actual cabling and the behavior of the network with the reference design and flags any anomalies.

Connect the Devices

  1. Click the Staged tab in your blueprint and select the Physical tab.
  2. Select the Links tab.
  3. If you haven’t pre-wired your fabric, then export a cabling map and connect your devices according to the map.
    1. Click the Export cabling map icon (Figure 1). You can save the cabling map as a JSON or CSV file.
      Figure 1: Export Cabling Map Export Cabling Map

      Figure 2 shows an example of the cabling map in JSON format.

      Figure 2: Cabling Map Cabling Map
    2. Physically connect your devices based on the information in the cabling map.
  4. If you have pre-wired your fabric and you want that wiring to remain in effect, import the links back to your blueprint.
    1. Click the Fetch discovered LLDP data icon (Figure 3).
      Figure 3: Fetch Discovered LLDP Data Fetch Discovered LLDP Data
    2. If the staged data is different from the LLDP discovery results, then click Update Cabling Map from LLDP to open the Cabling Map Editor where you can update the blueprint to match the connectivity discovered by LLDP. In the example shown above, the discovered LLDP data matches the connectivity in the existing cabling map.
      Note:

      Updating the cabling map from LLDP data is only successful if the existing wiring does not violate the interface map specifications in the blueprint. In this use case, ports et-0/0/48 and et-0/0/50 on the leaf devices must connect to the spine devices. Likewise, ports et-0/0/34 and et-0/0/35 on the spine devices must connect to the leaf devices.

Deploy the Blueprint

You’re now ready to deploy your design! Apstra pushes the configuration to all your fabric devices. Apstra then checks to make sure the fabric is behaving in accordance with the reference design.

  1. Select the Uncommitted tab to open the Uncommitted page. This page shows a summary of the differences between the staged configuration and the actual configuration on the devices. Scroll through this page to see the details of the configuration changes needed on the fabric devices to instantiate your blueprint.

  2. Click Commit to deploy the blueprint. The Commit changes from Staged to Active? confirmation window appears. If desired, enter a comment and click the Commit button to activate the changes.

  3. Select the Dashboard tab to watch as the configuration is downloaded and committed. The anomalies eventually clear as the underlay and overlay protocol sessions establish.

    This step can take several minutes in this use case. If one or more anomalies fail to clear, click the related anomaly gauge to see details on the anomaly.

Case Study: Cabling Anomaly

One of the features of Apstra is its ability to detect mismatches between your blueprint and the actual physical connectivity of the fabric devices. Figure 4 shows an example of BGP, cabling, and routing anomalies. It’s always good practice to address any physical layer anomalies first, which is what you’ll do in this troubleshooting example.

Figure 4: Deployment Anomalies Deployment Anomalies

  1. Click the Cabling anomalies gauge.

    This brings up the Anomalies page filtered for the anomaly type of cabling (Figure 5).

    Figure 5: Cabling Anomalies Cabling Anomalies
  2. Interpret the findings on this page.

    • The first row indicates that the Spine2 device is expecting to connect to the et-0/0/50 interface on the Leaf2 device in your design, but instead connects to a device with the displayed MAC address.

    • The second row indicates that the Spine1 device is expecting to connect to the et-0/0/48 interface on the Leaf2 device in your design, but instead connects to a device with the displayed MAC address.

    • The third row indicates that the Leaf2 device is expecting to connect to the et-0/0/35 interface on the spine2 device in your design, but instead is unconnected.

    • The fourth row indicates that the Leaf2 device is expecting to connect to the et-0/0/35 interface on the spine1 device in your design, but instead is unconnected.

    These anomalies all indicate that the problem is with the connections between the spine devices and the Leaf2 device.

    Once you fix the cabling, the cabling anomalies will disappear. If the cabling fault is the root cause of the BGP and the route anomalies, then these anomalies also clear when BGP sessions establish and the routing tables converge.

View the Overlay Routing on the Switch (Optional)

You might be curious on how Apstra configures the switches for the overlay networks. Figure 6 shows a simplified view of the routing tables in the leaf switches. You can see more details as you follow this procedure.

Figure 6: Overlay Routing (Simplified) Overlay Routing (Simplified)

Both leaf switches contain VRFs for the DC1-Green and DC1-Red overlay networks. Each VRF contains routes to the BMS endpoints, loopback addresses, and local IRB interfaces that are part of that VRF’s networks. Leaf1 has IRB interfaces for the DC1-Green-VN1 and DC1-Green-VN2 virtual networks while Leaf2 has IRB interfaces for the DC1-Green-VN1 and DC1-Red-VN1 virtual networks.

These correspond to how you attached the virtual networks to each leaf switch earlier. Refer to (Figure 8, Figure 11, and Figure 13 ) for details on the virtual networks used in this example.

The spine switches do not perform any overlay routing in this Edge-routed bridging (ERB) architecture. The spine switches merely provide underlay routing to support the VXLAN tunnels between the leaf switches.

  1. See how Apstra has configured the overlay IP addresses and routing tables on the Leaf1 switch.
    1. Log in to the Leaf1 switch.
    2. Show the IRB interface IP addresses.
    3. Show the loopback addresses.
    4. Show the routing table for the DC1-Green VRF.
    5. Show the routing table for the DC1-Red VRF.
  2. See how Apstra has configured the overlay IP addresses and routing tables on the Leaf2 switch.
    1. Log in to the Leaf2 switch.
    2. Show the IRB interface IP addresses.
    3. Show the loopback addresses.
    4. Show the routing table for the DC1-Green VRF.
    5. Show the routing table for the DC1-Red VRF.

Test BMS Connectivity (Optional)

In this section you test the connectivity between the servers in the DC1-Green virtual networks. Figure 7 summarizes the DC1-Green and DC1-Red virtual networks including the IP address assignments for the server endpoints.

Figure 7: DC1-Green and DC1-Red Overlay Virtual Networks DC1-Green and DC1-Red Overlay Virtual Networks

Refer to Figure 8 for details on how the four BMS devices attach to the leaf devices in the underlay. In summary, Leaf1 supports both the DC1-Green-VN1 and the DC1-Green-VN2 virtual networks, while Leaf2 supports the DC1-Green-VN1 and the DC1-Red-VN1 virtual networks.

Display the IP addressing and routing configured on BMS1. You configure the BMS network settings outside of Apstra using standard CentOS commands. Using CentOS to configure network parameters is outside the scope of this document. The information provided in this section is for completeness.
  1. Log in to the BMS1 server.
  2. Confirm the IP addresses assigned to the eth1 interface. Also confirm the static route needed to reach the DC1-Green-VN2 virtual network.
  3. Verify that BMS1 can ping its default gateway. This address belongs to the IRB interface associated with the DC1-Green-VN1 VRF.
  4. Verify that BMS1 can ping BMS3. Recall that these two servers attach to different leaf devices, but both servers reside in the DC1-Green-VN1 virtual network. As a result, these machines require only Layer 2 connectivity to communicate. You confirm Layer 2 connectivity by tracing the path between the servers. The result shows a single-hop that is the destination endpoint.
  5. Verify that BMS1 can ping BMS2. Recall that these two servers attach to the same leaf device, but the servers reside in different DC1-Green virtual networks. As a result, these machines communicate using Layer 3 connectivity. You confirm Layer 3 connectivity by tracing the path between the servers and noting that the IRB interface address, and the resulting extra hop, appear in the path.

    The ping results confirm the expected connectivity for the servers in the DC1-Green virtual networks. You can follow similar steps for BMS4 in the DC1-Red-VN1 virtual network. Because only one BMS is in this virtual network, you must limit ping testing at BMS4 to the IRB gateway address (192.168.200.1) associated with the DC1-Red virtual network.

    Pings between servers in a green virtual network to a device in the red virtual network are expected to fail. This is because the green and red virtual networks are housed in different VRFs (routing zones).

Case Study: Configuration Anomaly

If a fabric device reports a configuration change, Apstra compares that change with the reference design and flags any differences as anomalies. In this case study, a rogue operator has logged in to the Leaf2 switch CLI and manually changed the configuration on the device.

Apstra detects a configuration difference between the reference design and the configuration on the device and flags the anomaly in the dashboard (Figure 8).

Figure 8: Dashboard with Configuration Anomaly Dashboard with Configuration Anomaly
  1. Click the Config Dev anomaly gauge to bring up the Anomalies page with a filter automatically applied to show only configuration-related anomalies (Figure 9).
    Figure 9: Anomalies Anomalies
  2. Click the l2_1l2s_002_leaf1 node in the table to open the Anomalies page for that node.
  3. Click the Config tab to display the differences between the intended and the actual running configuration (Figure 10).
    Figure 10: Configuration Differences Between Intended and Actual Configuration Differences Between Intended and Actual
  4. Scroll through this page to look for highlighted discrepancies (Figure 11).
    Figure 11: Highlighted Differences Highlighted Differences

    In this example, you see that someone has changed the route target for the DC1-Red VRF on Leaf2 to a value that coincidentally matches the route target for the DC1-Green VRF. This means that DC1-Red routes get imported into DC1-Green routing tables and vice versa. The result is unintended connectivity between the DC1-Green and DC1-Red routing zones!

  5. Assuming you don’t want to this connectivity, click Apply Full Config to reapply the intended configuration.

    The anomalies in the dashboard should disappear when the applied configuration takes effect.

Case Study: Device Software Upgrade

Few tasks bring more trepidation to the network administrator than upgrading the software on a device. While using Apstra to upgrade device software does not guarantee upgrade success, you can rest assured that Apstra validates device operation after the upgrade to alert you to any anomalies.

This case study shows you how to upgrade software on the Leaf1 switch. Before you can upgrade the device software, you must register (upload) the software image to Apstra. Registering the software in Apstra is easy to do but is outside the scope of this document.

  1. Before upgrading, ensure no anomalies are active in the dashboard.
  2. In the left-nav bar, select Devices>System Agents>Agents to open the Agents page.
  3. Click the OFFBOX tab to open the OFFBOX Agents page.
  4. Find the row for the Leaf1 switch and click the OS Upgrade icon at the far right of the row (Figure 12).
    Figure 12: Device OS Upgrade Device OS Upgrade

    The Upgrade OS Image window appears.

  5. Use the drop-down list to select the desired OS Image and click Upgrade OS Image. Only registered images for the platform are available for selection.

    The upgrade starts and the Job State shows IN PROGRESS.

  6. Watch for the Job State and Connection State to both show SUCCESS, and for the Platform Version to reflect the upgraded software release. An upgrade can take over 30 minutes to complete.
  7. Go back to the dashboard to confirm anomalies clear as BGP sessions establish and routing table converge.

    Anomalies clear after a few minutes as Apstra validates the network against the reference design. Once the anomalies clear, you’ll know the upgrade was successful.