-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #120 - Add inband management to Day 2 Ops #124
base: main
Are you sure you want to change the base?
Issue #120 - Add inband management to Day 2 Ops #124
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. Small suggestion in my comments.
leaf: | ||
defaults: | ||
platform: cEOS | ||
< insert inband management keys here > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest adding the needed keys here and eliminate the the 2 lines above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has it been tested in the ATD Lab environment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Data Model works in the ATD Lab. One note: The SVI it creates on the spines has an interesting attached-host route statement.
This is something we'll need to make a note of, as it will likely drive questions from students. |
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering altering this or removing. It sounds a bit negative :)
|
||
### 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets get to work creating our inband management network. | |
Let's get to work on creating our inband management network. |
git switch -c inband-mgmt | ||
``` | ||
|
||
Now that we are on our new working branch, lets add our data model and render our configs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
Updated avd-lab-guide.md to include content for Inband Management.