850b982f2a
The handling of BVI is awkward, with the autoderived interface name "bviXX" based on the bridgedomain bd_id. Lots of special casing happens on account of this decision, and to make matters worse there is poor interaction (leading to VPP crashes) when BVIs and Loopbacks are used at the same time: https://lists.fd.io/g/vpp-dev/message/21116 This is step one of a refactor of the logic. In this commit, I'm removing all of the BVI logic from the codebase, rendering bridgedomains unable to have IP interfaces. In the next commit, I will introduce new behavior in the schema, allowing for 'bvi' to be a loopback interfacename which will be used as BVI for a bridgedomain, restoring the ability to use bridgedomains with IP interfaces (using a loop).
27 lines
568 B
YAML
27 lines
568 B
YAML
test:
|
|
description: "Loopback and BridgeDomain and Interfaces can't have the same LCP"
|
|
errors:
|
|
expected:
|
|
- "interface .* does not have a unique LCP name"
|
|
- "loopback .* does not have a unique LCP name"
|
|
- "bridgedomain bd0 is reserved"
|
|
count: 3
|
|
---
|
|
interfaces:
|
|
GigabitEthernet1/0/0:
|
|
lcp: "e1"
|
|
|
|
GigabitEthernet2/0/0:
|
|
mtu: 1500
|
|
GigabitEthernet2/0/1:
|
|
mtu: 1500
|
|
|
|
loopbacks:
|
|
loop0:
|
|
lcp: "e1"
|
|
|
|
bridgedomains:
|
|
bd0:
|
|
description: "bd_id 0 in VPP is reserved"
|
|
interfaces: [ GigabitEthernet2/0/0, GigabitEthernet2/0/1 ]
|