openconfig
Add support for vni-peer-group container
Change Scope
The changes introduce operational state properties only.
- Deprecate two properties
control-plane-vnisandrouter-mac- This means the properties will be supported but deprecated and removed in a future OC model release
- Add the new container structure
vni-peer-groupwhich allows the association betweencp-vni-id,egress-vniandrouter-mac - Keying on both
cp-vniandegress-vniallows flexibility for both symmetric and asymmetric use cases. For symmetric VNIs both keys would be set to the same value. - The change is backwards compatible
Tree Structure
| +--rw vxlan
| +--rw config
| | +--rw description? string
| | +--rw enabled? boolean
| | +--rw source-interface? string
| +--ro state
| | +--ro description? string
| | +--ro enabled? boolean
| | +--ro source-interface? string
| +--ro endpoint-peers
| | +--ro endpoint-peer* [peer-address]
| | +--ro peer-address -> ../state/peer-address
| | +--ro state
| | | +--ro peer-address? oc-inet:ip-address
| | | +--ro peer-state? enumeration
| | | +--ro uptime? oc-types:timeticks64
| | | x--ro control-plane-vnis* oc-evpn-types:vni-id
| | | x--ro router-mac? oc-yang:mac-address
| | +--ro vni-peer-group
| | +--ro vni-peer-group* [cp-vni egress-vni]
| | +--ro cp-vni -> ../state/cp-vni
| | +--ro egress-vni -> ../state/egress-vni
| | +--ro state
| | +--ro cp-vni? oc-evpn-types:vni-id
| | +--ro egress-vni? oc-evpn-types:vni-id
| | +--ro router-mac? oc-yang:mac-address
| +--ro endpoint-vnis
Platform Implementations
- Cisco NXOS: link to documentation
switch# show nve peers control-plane-vni peer-ip 203.1.1.1
Peer VNI Learn-Source Gateway-MAC Peer-type Egress-VNI SW-BD State
--------- ----- ------------ --------------- ---------- ---------- ----- ----------------------
203.1.1.1 2000003 BGP f40f.1b6f.f8db FAB 3000003 3005 peer-vni-add-complete
- Nokia: link to documentation
- From the document: VNIs configured in static VXLAN instances are ‟symmetric”, that is, the same ingress and egress VNIs are used for VXLAN packets using that instance. Note that asymmetric VNIs are actually possible in EVPN VXLAN instances.
No major YANG version changes in commit 897de89fe4240a2a580936f4fe0769814770405c
@dplore I did a rebase and updated the name of the container as requested. There was a failure in the pyangbind step that does not seem related to my chanages.
The error states the following: Validator script failed -- infra bug?
@dplore I did a rebase but there was a failure in the pyangbind step that does not seem related to my chanages.
The error states the following: Validator script failed -- infra bug?
@dplore I did a rebase but there was a failure in the
pyangbindstep that does not seem related to my chanages.The error states the following:
Validator script failed -- infra bug?
@wenovus apologies, I pinged you for the wrong PR. This is the one where pyangbind check is failing.
@dplore I did a rebase but there was a failure in the
pyangbindstep that does not seem related to my chanages. The error states the following:Validator script failed -- infra bug?@wenovus apologies, I pinged you for the wrong PR. This is the one where pyangbind check is failing.
Hi @mikewiebe this seems like it might be a one-off error (maybe the cloud VM got killed) especially since the main branch is passing for this check. Can you push an empty commit to re-trigger the CI:
git commit --allow-empty -m "Retrigger CI" && git push
@dplore I did a rebase but there was a failure in the
pyangbindstep that does not seem related to my chanages. The error states the following:Validator script failed -- infra bug?@wenovus apologies, I pinged you for the wrong PR. This is the one where pyangbind check is failing.
Hi @mikewiebe this seems like it might be a one-off error (maybe the cloud VM got killed) especially since the main branch is passing for this check. Can you push an empty commit to re-trigger the CI:
git commit --allow-empty -m "Retrigger CI" && git push
@wenovus, sorry, I was traveling last couple of weeks so just seeing this. I will try this. Thanks!
@wenovus tried a rebase and git commit --allow-empty -m "Retrigger CI" && git push but now it's failing on a different step. public-pr (disco-idea-817). There are no details about the failure except a message Needs /gcbrun from a collaborator so unsure how to proceed. Thanks!
@wenovus tried a rebase and
git commit --allow-empty -m "Retrigger CI" && git pushbut now it's failing on a different step.public-pr (disco-idea-817). There are no details about the failure except a messageNeeds /gcbrun from a collaboratorso unsure how to proceed. Thanks!
Are you able to see the "Needs /gcbrun from a collaborator" comment in the failure summary?
We recently changed the CI to only be runnable by a maintainer, so it's little cumbersome. I'll investigate whether this can be changed.
@wenovus tried a rebase and
git commit --allow-empty -m "Retrigger CI" && git pushbut now it's failing on a different step.public-pr (disco-idea-817). There are no details about the failure except a messageNeeds /gcbrun from a collaboratorso unsure how to proceed. Thanks!Are you able to see the "Needs /gcbrun from a collaborator" comment in the failure summary?
We recently changed the CI to only be runnable by a maintainer, so it's little cumbersome. I'll investigate whether this can be changed.
Ah, ok. Yes I do see the Needs /gcbrun from a collaborator comment.