Interface configuration #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for this A decision needs to be made :
Should a maximum length need to be set for |
|
@frederic-loui Yeah that's a known limitation. The CLI is pretty primitive at this point, it doesn't support string values containing spaces. I think it would be a good idea to file an issue in the holo-cli repo to keep track of that problem. |
|
Second comment: (using containerlab environment compiled with
--> First thing we notice is that the default MTU is set to
--> Shouldn't interface MTU default set to |
I think option #1 would be the way to go, that's how the "description" command works on most vendors.
Indeed, it would be good to define a maximum length. That can be done either using a YANG deviation or northbound validation callback. I'll think about that.
Currently, if an explicit MTU isn't specified, the one learned from the kernel will be used. I think this behavior is good to accommodate users using holod solely for routing, and handling interface configuration separately. |
This was referenced Apr 14, 2024
Open
|
Steps to reproduce: (example)
|
Example configuration (CLI):
```
interfaces interface eth-rt2
type iana-if-type:ethernetCsmacd
!
ipv4 address 10.0.1.1
prefix-length 24
!
```
Example configuration (JSON):
```
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth-rt2",
"type": "iana-if-type:ethernetCsmacd",
"ietf-ip:ipv4": {
"address": [
{
"ip": "10.0.1.1",
"prefix-length": 24
}
]
}
}
}
}
}
```
This commit also includes a refactoring to allow configuring interfaces
before they exist at the OS-level. Then, once the interface becomes
available, its pre-existing configuration is applied.
Signed-off-by: Renato Westphal <[email protected]>
Signed-off-by: Renato Westphal <[email protected]>
Of particular note, the ietf-interfaces module has different leafs to configure MTU for IPv4 and IPv6, but Linux supports a single MTU for all L3 protocols. As such, a validation callback was added to ensure the IPv4 and IPv6 MTUs are the same when both are configured. Signed-off-by: Renato Westphal <[email protected]>
Example configuration (CLI):
```
[snip]
interfaces interface eth-rt2.10
type ietf-if-extensions:ethSubInterface
encapsulation dot1q-vlan outer-tag vlan-id 10
parent-interface eth-rt2
!
```
Example configuration (JSON):
```
{
"ietf-interfaces:interfaces": {
"interface": [
[snip]
{
"name": "eth-rt2.10",
"type": "ietf-if-extensions:ethSubInterface",
"ietf-if-extensions:encapsulation": {
"ietf-if-vlan-encapsulation:dot1q-vlan": {
"outer-tag": {
"vlan-id": 10
}
}
},
"ietf-if-extensions:parent-interface": "eth-rt2"
}
]
}
}
```
Signed-off-by: Renato Westphal <[email protected]>
rwestphal
force-pushed
the
interface-properties
branch
from
39dbaa5 to
fb06e35
Compare
-> Test have also been done with |
|
Is this a desirable behavior ? Other vendor tends:
|
|
@frederic-loui Yes, that's the desired behavior. All protocol implementations are prepared to handle interfaces with multiple addresses. In the case of OSPFv2, the first received address will be considered to be the primary address used for protocol operation. |
|
all lgtm ! PS: Please let me know when/if |
Thanks, I had forgotten about that. Bumped to 0.4.1! It shouldn't be necessary to update holo-cli, as it currently depends on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement the following configuration options:
Example configuration (CLI):
Example configuration (JSON):
Verification (kernel):
If the interface isn't available at the OS-level upon configuration, the configuration will be automatically applied once the interface becomes available. Similarly, VLAN subinterfaces are automatically created as soon as their parent interface is available.
Closes #11