How should NetBox model a VPWS service with multiple EVPL attachment circuits?

[makeshift3432]

Hi,

I am trying to model a service in NetBox and I haven't found a clean fit in the current L2VPN data model.

I have a VPWS service present on two aggregation routers. Under that parent service, there are multiple EVPL instances, each bound to a different L2 subinterface on a trunk. Operationally, this is one customer service, but it has several attachment circuits, each with its own EVPL instance, service-ID pair, and VLAN handoff. In some cases there is also VLAN translation.

A simplified example looks like this:

Device A:
evpn vpn-instance SVC-EXAMPLE-1001 vpws
 route-distinguisher 65000:1001
 vpn-target 65000:1001 export-extcommunity
 vpn-target 65000:1001 import-extcommunity

evpl instance 11
 evpn binding vpn-instance SVC-EXAMPLE-1001
 local-service-id 501 remote-service-id 502

evpl instance 12
 evpn binding vpn-instance SVC-EXAMPLE-1001
 local-service-id 503 remote-service-id 504

...

interface Eth-Trunk10.1 mode l2
 encapsulation dot1q vid 3101
 rewrite map 1-to-1 vid 101
 evpl instance 11

interface Eth-Trunk10.2 mode l2
 encapsulation dot1q vid 3102
 rewrite map 1-to-1 vid 102
 evpl instance 12

...

Device B:
evpn vpn-instance SVC-EXAMPLE-1001 vpws
 route-distinguisher 65000:1001
 vpn-target 65000:1001 export-extcommunity
 vpn-target 65000:1001 import-extcommunity

evpl instance 21
 evpn binding vpn-instance SVC-EXAMPLE-1001
 local-service-id 502 remote-service-id 501

evpl instance 22
 evpn binding vpn-instance SVC-EXAMPLE-1001
 local-service-id 504 remote-service-id 503

...

interface Eth-Trunk20.1 mode l2
 encapsulation dot1q vid 101
 evpl instance 21

interface Eth-Trunk20.2 mode l2
 encapsulation dot1q vid 102
 evpl instance 22

...

So for each circuit I need to represent at least:

1. The parent VPWS service, in this example SVC-EXAMPLE-1001
2. The fact that it exists on both PEs
3. The individual attachment circuits or subinterfaces on each side
4. The per-AC EVPL/service-ID relationship
5. The VLAN mapping per circuit, including cases where one side presents VLAN 3101 and the far side presents VLAN 101

The modeling options I have considered are:

1. One L2VPN object for the parent service, with all involved subinterfaces attached as terminations
2. One L2VPN per EVPL pair or subservice, and then somehow link those back to the parent service (how?)
3. One L2VPN for the parent service, and store EVPL instance numbers, local-service-id, remote-service-id, in custom fields on interfaces or terminations.
4. One VLAN translation policy/rule on each subinterface with translation.

None of these feels completely clean.

My main question is: what is the recommended NetBox way to model this kind of service?

More specifically:

1. Should the parent VPWS service be the L2VPN, with all subinterfaces attached as terminations?
2. Or is NetBox better suited to treating each EVPL pair as its own L2VPN?
3. Has anyone modeled a similar EVPN/EVPL service in NetBox in a way that still works well for documentation and automation?

I feel like the ideal approach would involve some mechanism to terminate a VPWS L2VPN to multiple EVPL L2VPN objects or something.

I am not trying to force vendor-specific semantics directly into NetBox. I am mainly interested in the most idiomatic NetBox representation for a service that is logically one VPWS but operationally consists of several EVPL attachment circuits with distinct VLAN mappings.

Thanks.

[mg1986jp]

The L2VPN model in NetBox is a bit flat for this kind of setup. A VPWS with multiple EVPLs underneath doesn't map cleanly to a single L2VPN object because each EVPL is essentially its own point-to-point circuit but they're all part of one customer service.

What I've seen people do is:

Create one L2VPN object for the parent VPWS service (type: VPWS), then create individual L2VPN Terminations for each EVPL, associating them with the specific subinterfaces on each aggregation router. The terminations give you the per-EVPL granularity while the parent L2VPN ties them all together under one service.

If you need to track the EVPL identifiers separately, you could use custom fields on the terminations to store the EVPL ID / service instance. It's not perfect but it gets you a queryable model.

The alternative is modeling each EVPL as its own L2VPN (type: EVPL) and using tags or a custom field to group them under the parent service name. Less elegant but more explicit.