Replies: 4 comments 2 replies
-
I feel like I'm not understanding this - what exactly do you mean when you say you don't see how to associate interfaces with circuit terminations? All of the circuits we model have terminations with a cable connected between it and a device interface, very similar to how this circuit is configured in the demo instance.
I think it comes down to what your priorities are when using NetBox. If you regularly use the cable trace feature and feel like it's a big help/need to have a full end-to-end trace, then what you're proposing makes sense. The con, of course, is that it doesn't model the device accurately and makes configuration management more difficult because you lose the helpful properties that interfaces have when you use front/rear ports instead (if you happen to manage those devices that the circuits are terminating on). |
Beta Was this translation helpful? Give feedback.
-
The difference is that in the demo instance, the circuit termination connects directly to the device interface (the router "dmi01-yonkers-rtr01" there), so it's a "floating" cable with only one real end. With these Openreach circuits, we have to model the presentation of the circuit, as it takes up 1U in our rack. That is: the router has a cable going into the ADVA device, and then behind that the circuit comes out of the ADVA into Openreach's network.
That's not an issue here, since the ADVA is owned and managed by Openreach as part of the service. The only other issue I can see is distinguishing the 1G ports (1-20) from the 1G/10G ports (21-26). When they are frontports then they're all just "LC". But I can use the port description to do this. In any case, the ports are assigned by Openreach too, and obviously if we provision a 10G circuit they'll present it on one of the 10G-capable ports. |
Beta Was this translation helpful? Give feedback.
-
The circuits model is meant to be a representation of two physical points. In most cases there will only ever be one "real" end, or at least one that you see and care about. Provider Network terminations are specifically designed to represent the other, generally less relevant end.
I'd argue the most accurate representation includes the ghost cable configuration, in your case something like: Router This setup would still have a "floating" cable, but essentially so does your rack since you don't see both ends of the ADVA uplink. All that said, I'm all for as close to real life as possible, but that's obviously not necessary. As long as you're able to understand everything and have notes so that others can too, it shouldn't be a big deal. |
Beta Was this translation helpful? Give feedback.
-
(Actually these are site-to-site circuits, so there's an ADVA at each end, A and Z) But that's the point. To do Router The ADVA in the Netbox DTL has only interfaces 1-26. To do what you suggest, then I could add a second set of interfaces: but then there's no association between the outside interface which connects to the router, and the inside interface which connects to the circuit termination. (Well, I could create a bunch of VLANs and make inside and outside access ports on the same VLAN, but circuit tracing doesn't work through that). Alternatively I could do what I suggested originally, which was to model them as connected frontports and rearports. In the absence of any good reason not to do that, then I think that's what I'll do. (There's another kind of EAD circuit where multiple circuits are presented as VLANs on the same port (an NNI). That has already been raised as #10558, and is not what I'm discussing here). A circuit is a weird entity in Netbox: it's both kind-of physical and kind-of virtual. A circuit termination is kind-of physical in that you can plug one end of a cable into it, but it it has no physical port type, and it has no physical position, except that it's "somewhere within a site". And a circuit is kind-of virtual, except that you can't carry multiple circuits on the same circuit termination. |
Beta Was this translation helpful? Give feedback.
-
Fair enough. I apologize as well, as I didn't realize that multiple circuits were coming in on the ADVA's outside interface. I was thinking more along the lines of the WAN/circuit equipment my organization has, which has just one internal and external port for a singular network. On the topic of circuits, I don't think they're all that strange physically, if only because the physical nature becomes much more defined when you have the context of the cable and the interface it's plugged into. But yeah, multiple circuits on the same termination is probably a missed opportunity so far. |
Beta Was this translation helpful? Give feedback.
-
|
Just to complete this discussion, it turns out that these multi-port EADs are deployed with the ports in pairs: the odd-numbered ports are the customer (access) ports, and the even-numbered ports are the network ports which go into the Openreach network. Therefore, I've end up with front ports 1,3,5...25, linked to "rear ports" 2,4,6...26 - even though they are actually on the front! The Circuit Terminations connect to the "rear ports". |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In the UK, Openreach delivers circuits on a multiport "Ethernet Access Direct" device like the Adva FSP 150-XG120Pro (SH). I was pleased to find this is already available in the Netbox device type library.
This creates all the ports as "interfaces". Whilst this is technically correct - these are active ports - I can't see a way of associating these interfaces with circuit terminations.
Instead, I was planning to model the EAD with linked "frontports" and "rearports", so each circuit termination can be connected via a virtual cable to the "rearport", and then I'll be able to trace all the way through each circuit.
I was just wondering if there's a good reason why I shouldn't do that, apart from it not being technically correct (in the sense that the EAD ports are active not passive?)
Beta Was this translation helpful? Give feedback.
All reactions