Deploy

Explanation of Procedure

In the deploy stage, you cable your network and push 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, then you can get AOS to learn about those connections, import them back to your blueprint, and update the reference design. Recall that AOS 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 AOS has an accurate view of the connectivity.

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

Connect the Devices

1. In your blueprint, select the Staged tab and then 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.
   1. Click the Export cabling map icon (Figure 24). You can save the cabling map as a JSON or CSV file.

      Figure 24: Export Cabling Map

      

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

      Figure 25: 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 26).

      Figure 26: Fetch Discovered LLDP Data

      

   2. If the staged data is different from the LLDP discovery results, then click Update Cabling Map from LLDP to bring up the Cabling Map Editor where you can update the blueprint based on the discovered LLDP data.
      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, and 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! AOS pushes the configuration to all your fabric devices and checks to make sure the fabric is behaving in accordance with the reference design.

1. Select the Uncommitted tab to bring up 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 changes that will be pushed to the devices.
2. Click Commit to deploy the blueprint.

3. Select the Dashboard tab to watch as the configuration is downloaded and committed. The anomalies eventually clear up as the underlay and overlay are set up.

   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.

Example: Cabling Anomaly

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

Figure 27: Deployment Anomalies

1. Click the Cabling anomalies gauge.

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

   Figure 28: 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 is connected to a device identified by the specified 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 is connected to a device identified by the specified 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 that’s the root cause of the BGP and routing anomalies, then those anomalies will disappear when BGP sessions are established and the routing tables are updated.

View the Overlay Routing Configuration on the Switch (Optional)

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

Figure 29: 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 network. 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 (Figure 18, Figure 20, Figure 22).

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 AOS 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.
      content_copy zoom_out_map

      user@l2-1l2s-001-leaf1> show interfaces terse | match irb 
      irb                     up    up
      irb.4                   up    up   inet     192.168.100.1/24
      irb.5                   up    up   inet     192.168.101.1/24
      

   3. Show the loopback addresses.
      content_copy zoom_out_map

      user@l2-1l2s-001-leaf1> show interfaces terse | match lo0    
      lo0                     up    up
      lo0.0                   up    up   inet     10.255.0.2          --> 0/0
      lo0.2                   up    up   inet     10.192.0.0          --> 0/0
      lo0.3                   up    up   inet     10.193.0.0          --> 0/0
      lo0.16385               up    up   inet    
      

   4. Show the routing table for the DC1-Green VRF.
      content_copy zoom_out_map

      user@l2-1l2s-001-leaf1> show route table DC1-Green.inet.0 
      
      DC1-Green.inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
      @ = Routing Use Only, # = Forwarding Use Only
      + = Active Route, - = Last Active, * = Both
      
      10.192.0.0/32      *[Direct/0] 00:39:46
                          >  via lo0.2
      10.192.0.1/32      *[EVPN/170] 00:38:15
                             to 10.10.0.0 via et-0/0/48.0
                          >  to 10.10.0.4 via et-0/0/50.0
      192.168.100.0/24   *[Direct/0] 00:38:22
                          >  via irb.4
                          [EVPN/170] 00:38:15
                             to 10.10.0.0 via et-0/0/48.0
                          >  to 10.10.0.4 via et-0/0/50.0
      192.168.100.1/32   *[Local/0] 00:38:22
                             Local via irb.4
      192.168.101.0/24   *[Direct/0] 00:38:22
                          >  via irb.5
      192.168.101.1/32   *[Local/0] 00:38:22
                             Local via irb.5
      

   5. Show the routing table for the DC1-Red VRF.
      content_copy zoom_out_map

      user@l2-1l2s-001-leaf1> show route table DC1-Red.inet.0      
      
      DC1-Red.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
      @ = Routing Use Only, # = Forwarding Use Only
      + = Active Route, - = Last Active, * = Both
      
      10.193.0.0/32      *[Direct/0] 00:41:55
                          >  via lo0.3
      10.193.0.1/32      *[EVPN/170] 00:40:24
                             to 10.10.0.0 via et-0/0/48.0
                          >  to 10.10.0.4 via et-0/0/50.0
      192.168.200.0/24   *[EVPN/170] 00:40:24
                          >  to 10.10.0.0 via et-0/0/48.0
                             to 10.10.0.4 via et-0/0/50.0

2. See how AOS 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.
      content_copy zoom_out_map

      user@l2-1l2s-002-leaf1> show interfaces terse | match irb 
      irb                     up    up
      irb.4                   up    up   inet     192.168.100.1/24
      irb.5                   up    up   inet     192.168.200.1/24
      

   3. Show the loopback addresses.
      content_copy zoom_out_map

      user@l2-1l2s-002-leaf1> show interfaces terse | match lo0    
      lo0                     up    up
      lo0.0                   up    up   inet     10.255.0.3          --> 0/0
      lo0.2                   up    up   inet     10.192.0.1          --> 0/0
      lo0.3                   up    up   inet     10.193.0.1          --> 0/0
      lo0.16385               up    up   inet    
      

   4. Show the routing table for the DC1-Green VRF.
      content_copy zoom_out_map

      user@l2-1l2s-002-leaf1> show route table DC1-Green.inet.0 
      
      DC1-Green.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
      @ = Routing Use Only, # = Forwarding Use Only
      + = Active Route, - = Last Active, * = Both
      
      10.192.0.0/32      *[EVPN/170] 00:44:58
                             to 10.10.0.2 via et-0/0/48.0
                          >  to 10.10.0.6 via et-0/0/50.0
      10.192.0.1/32      *[Direct/0] 00:46:29
                          >  via lo0.2
      192.168.100.0/24   *[Direct/0] 00:45:04
                          >  via irb.4
                          [EVPN/170] 00:44:58
                             to 10.10.0.2 via et-0/0/48.0
                          >  to 10.10.0.6 via et-0/0/50.0
      192.168.100.1/32   *[Local/0] 00:45:04
                             Local via irb.4
      192.168.101.0/24   *[EVPN/170] 00:44:58
                             to 10.10.0.2 via et-0/0/48.0
                          >  to 10.10.0.6 via et-0/0/50.0
      

   5. Show the routing table for the DC1-Red VRF.
      content_copy zoom_out_map

      user@l2-1l2s-002-leaf1> show route table DC1-Red.inet.0      
      
      DC1-Red.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
      @ = Routing Use Only, # = Forwarding Use Only
      + = Active Route, - = Last Active, * = Both
      
      10.193.0.0/32      *[EVPN/170] 00:46:10
                             to 10.10.0.2 via et-0/0/48.0
                          >  to 10.10.0.6 via et-0/0/50.0
      10.193.0.1/32      *[Direct/0] 00:47:41
                          >  via lo0.3
      192.168.200.0/24   *[Direct/0] 00:47:41
                          >  via irb.5
      192.168.200.1/32   *[Local/0] 00:47:41
                             Local via irb.5
      

Example: Configuration Anomaly

If a fabric device reports a configuration change, AOS compares that change with the reference design and flags any differences as anomalies. In this example, a rogue operator has logged in to the Leaf2 switch CLI directly and made a configuration change.

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

Figure 30: 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 31).

   Figure 31: Anomalies

   

2. Click the l2_1l2s_002_leaf1 node in the table to bring up the Anomalies page for that node.
3. Click the Config tab to display the differences between the intended and the actual running configuration (Figure 32).

   Figure 32: Configuration Differences Between Intended and Actual

   

4. Scroll through this page to look for highlighted discrepancies (Figure 33).

   Figure 33: 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 will be imported into DC1-Green routing tables and vice-versa. This results in unintended connectivity between the DC1-Green and DC1-Red security zones!

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

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

Example: Device Software Upgrade

There are not many tasks that bring more trepidation to the network administrator than upgrading the software on a device. While using AOS to upgrade device software does not guarantee success, you can rest assured that AOS validates the network after the upgrade and on an ongoing basis thereafter.

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

1. Before upgrading, ensure there are no anomalies in the dashboard.
2. In the left-nav bar, select Devices>System Agents>Agents to bring up the Agents page.
3. Click the OFFBOX tab to bring up 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 34).

   Figure 34: 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 to be selected.

   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. This can take 30 minutes or longer.
7. Go back to the dashboard to watch for anomalies to clear as BGP sessions are re-established and routes exchanged.

   This should take a few minutes as AOS validates the network against the reference design. Once the anomalies clear, you’ll know the upgrade was successful.