Issue #120 - Add inband management to Day 2 Ops #124

RestlessWanderer · 2024-01-15T20:52:50Z

Updated avd-lab-guide.md to include content for Inband Management.

mthiel117

Nice work. Small suggestion in my comments.

mthiel117 · 2024-01-15T21:14:48Z

workshops/avd-lab-guide.md

+leaf:
+ defaults:
+ platform: cEOS
+ < insert inband management keys here >


I would suggest adding the needed keys here and eliminate the the 2 lines above.

Have you tested this data models work in the ATD lab? How are you showing them how to connect to the new in-band mgmt address or you just showing that it gets created?

Have you tested this data models work in the ATD lab? How are you showing them how to connect to the new in-band mgmt address or you just showing that it gets created?

Just how it gets created. I guess you could connect to it from the linux host but not sure its worth it.

Has it been tested in the ATD Lab environment?

Has it been tested in the ATD Lab environment?

No but I have that exact data model running in a production environment, and its not new. Dont see why it wouldnt work.

The ATD Labs have been updated to AVD 4.5 and ansible-core 2.15.5, so it would be worth testing your data model before we merge this.

mthiel117 · 2024-01-16T15:02:34Z

Data Model works in the ATD Lab.

One note:

The SVI it creates on the spines has an interesting attached-host route statement.

interface Vlan3000
   description Inband Management
   no shutdown
   mtu 1500
   ip address 10.255.255.2/24
   ip attached-host route export 19
   ip virtual-router address 10.255.255.1
!

This is something we'll need to make a note of, as it will likely drive questions from students.

JulioPDX · 2024-02-21T18:47:08Z

workshops/avd-lab-guide.md

@@ -823,4 +823,201 @@ git branch -D add-leafs

 Finally, we can go out to our forked copy of the repository and delete the **add-leafs** branch.

-All set!
+Now that the work we did for nothing has been fully wiped out, we can move on to our last change.


Considering altering this or removing. It sounds a bit negative :)

JulioPDX · 2024-02-21T18:53:05Z

workshops/avd-lab-guide.md

+
+### Inband Management
+
+In the lab environment we are using for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, in production environments, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and access to the devices. However, what happens if you don't have a dedicated management fabric? What if even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable. Enter the widely used, inband management functionality. 


Suggested change

In the lab environment we are using for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, in production environments, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and access to the devices. However, what happens if you don't have a dedicated management fabric? What if even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable. Enter the widely used, inband management functionality.

In the lab environment, we use for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and device access in production environments. However, what happens if you need a dedicated management fabric? What if, even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable? Enter the widely used inband management functionality.

JulioPDX · 2024-02-21T18:54:28Z

workshops/avd-lab-guide.md

+
+In the lab environment we are using for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, in production environments, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and access to the devices. However, what happens if you don't have a dedicated management fabric? What if even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable. Enter the widely used, inband management functionality. 
+
+As we have learned from working through the AVD labs, when building a Layer 2 Leaf/Spine fabric, all the VLAN SVIs are created and live solely on the spines switches. This presents a slight hurdle to us, because inband management uses a VLAN SVI, in the specified management network, on every switch, spines and leafs. The spines still need to host the gateway for this inband management network, and a static route needs to be created on every leaf. Trying to manipulate the data model in the network services vars file to accomplish inband management would not be as clean or efficient, and it still would not get the management SVIs created on each leaf switch.


Suggested change

As we have learned from working through the AVD labs, when building a Layer 2 Leaf/Spine fabric, all the VLAN SVIs are created and live solely on the spines switches. This presents a slight hurdle to us, because inband management uses a VLAN SVI, in the specified management network, on every switch, spines and leafs. The spines still need to host the gateway for this inband management network, and a static route needs to be created on every leaf. Trying to manipulate the data model in the network services vars file to accomplish inband management would not be as clean or efficient, and it still would not get the management SVIs created on each leaf switch.

As we have learned from working through the AVD labs, when building a Layer 2 Leaf/Spine fabric, all the VLAN SVIs are created and live solely on the spines switches. This presents a slight hurdle to us because inband management uses a VLAN SVI in the specified management network on every switch, spine, and leaf. The spines still need to host the gateway for this inband management network, and a static route needs to be created on every leaf. Trying to manipulate the data model in the network services vars file to accomplish inband management would not be as clean or efficient, and it still would not get the management SVIs created on each leaf switch.

JulioPDX · 2024-02-21T18:56:19Z

workshops/avd-lab-guide.md

+ inband_mgmt_subnet: <str>
+```
+
+With just these two key value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leafs, and the static route.


Suggested change

With just these two key value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leafs, and the static route.

With these two key-value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leaves, and the static route.

JulioPDX · 2024-02-21T18:56:34Z

workshops/avd-lab-guide.md

+
+With just these two key value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leafs, and the static route.
+
+Lets get to work creating our inband management network.


Suggested change

Lets get to work creating our inband management network.

Let's get to work on creating our inband management network.

JulioPDX · 2024-02-21T18:57:21Z

workshops/avd-lab-guide.md

+git switch -c inband-mgmt
+```
+
+Now that we are on our new working branch, lets add our data model and render our configs.


Suggested change

Now that we are on our new working branch, lets add our data model and render our configs.

Now that we are on our new working branch, let's add our data model and render our configurations.

JulioPDX · 2024-02-21T19:01:50Z

workshops/avd-lab-guide.md

+make build-site-1
+```
+
+Go ahead and review the newly rendered configurations and documentation to see what config was rendered for the spines and leafs.


Suggested change

Go ahead and review the newly rendered configurations and documentation to see what config was rendered for the spines and leafs.

Review the newly rendered configurations and documentation to see what was rendered for the spines and leafs.

JulioPDX · 2024-02-21T19:02:23Z

workshops/avd-lab-guide.md

+
+Login to your switches to verify the current configs (`show run`) match the ones created in `intended/configs` folder.
+
+Also check out that the new inband management VLAN 3000 SVI exists on the spines and leafs with their auto-allocated IPs.


Suggested change

Also check out that the new inband management VLAN 3000 SVI exists on the spines and leafs with their auto-allocated IPs.

Also, check out that the new inband management VLAN 3000 SVI exists on the spines and leaves with their auto-allocated IPs.

RestlessWanderer added 5 commits January 15, 2024 11:56

inband management updates

e21b9d2

inband management updates

a9171bb

inband mgmt updates

d2517de

inband management updates

abd1483

inband management updates

6b467b8

mthiel117 requested changes Jan 15, 2024

View reviewed changes

mthiel117 requested review from MitchV85 and JulioPDX January 16, 2024 15:03

JulioPDX reviewed Feb 21, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue #120 - Add inband management to Day 2 Ops #124

Issue #120 - Add inband management to Day 2 Ops #124

RestlessWanderer commented Jan 15, 2024

mthiel117 left a comment

mthiel117 Jan 15, 2024

mthiel117 Jan 15, 2024

RestlessWanderer Jan 15, 2024

mthiel117 Jan 15, 2024

RestlessWanderer Jan 15, 2024

mthiel117 Jan 16, 2024

mthiel117 commented Jan 16, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024

JulioPDX Feb 21, 2024


		### Inband Management

		In the lab environment we are using for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, in production environments, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and access to the devices. However, what happens if you don't have a dedicated management fabric? What if even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable. Enter the widely used, inband management functionality.


		In the lab environment we are using for this class, all switches are accessible through the dedicated out-of-band management port. Additionally, in production environments, dedicated out-of-band management fabrics are always the recommended way to segregate all management functionality and access to the devices. However, what happens if you don't have a dedicated management fabric? What if even though you do have that fabric, you would like some other type of non-console management access in the event the management fabric is unavailable. Enter the widely used, inband management functionality.

		As we have learned from working through the AVD labs, when building a Layer 2 Leaf/Spine fabric, all the VLAN SVIs are created and live solely on the spines switches. This presents a slight hurdle to us, because inband management uses a VLAN SVI, in the specified management network, on every switch, spines and leafs. The spines still need to host the gateway for this inband management network, and a static route needs to be created on every leaf. Trying to manipulate the data model in the network services vars file to accomplish inband management would not be as clean or efficient, and it still would not get the management SVIs created on each leaf switch.

	With just these two key value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leafs, and the static route.
	With these two key-value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leaves, and the static route.


		With just these two key value pairs, AVD will automatically create the inband management VLAN, its associated SVIs on the spines, the vARP virtual IP for the subnet gateway, the VLAN and its SVIs on the leafs, and the static route.

		Lets get to work creating our inband management network.

	Lets get to work creating our inband management network.
	Let's get to work on creating our inband management network.

	Now that we are on our new working branch, lets add our data model and render our configs.
	Now that we are on our new working branch, let's add our data model and render our configurations.

	Go ahead and review the newly rendered configurations and documentation to see what config was rendered for the spines and leafs.
	Review the newly rendered configurations and documentation to see what was rendered for the spines and leafs.


		Login to your switches to verify the current configs (`show run`) match the ones created in `intended/configs` folder.

		Also check out that the new inband management VLAN 3000 SVI exists on the spines and leafs with their auto-allocated IPs.

	Also check out that the new inband management VLAN 3000 SVI exists on the spines and leafs with their auto-allocated IPs.
	Also, check out that the new inband management VLAN 3000 SVI exists on the spines and leaves with their auto-allocated IPs.

Issue #120 - Add inband management to Day 2 Ops #124

Are you sure you want to change the base?

Issue #120 - Add inband management to Day 2 Ops #124

Conversation

RestlessWanderer commented Jan 15, 2024

mthiel117 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mthiel117 commented Jan 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment