[racktables-users] Re: Add new port attribute

  • From: Lucas Aimaretto <laimaretto@xxxxxxxxx>
  • To: Marijn van Gool <marijn.vangool@xxxxxxxxxxx>
  • Date: Thu, 5 Mar 2020 12:19:44 -0300

On Thu, Mar 5, 2020 at 7:05 AM Marijn van Gool <marijn.vangool@xxxxxxxxxxx>
wrote:

You have a point there: really do not know what would happen after an
upgrade …


Yes, definitely staying away from this.

What I'm doing on my own (until this feature is available) is to generate
a code on the cable-id, where each field is separated by a ":".

I've defined a syntax such as "field1 : field2 : field3" where each field
represents something you might need ...

Not the best idea, but so far is working for us …


I’m trying something like this as well.
With inter datacenter backbone cables there’s usually:
- circuit ID location A;
- circuit ID location B;
- reference number of the actual backbone circuit, defined by the carrier.

Some options I can think of:
- [option A] cable ID —> circuit_ID_A : circuit_ID_B :
reference_number_carrier
- [option B] visible label —> interface description + circuit_ID_A / B *and
*cable ID —> reference_number_carrier

Both not optimal, but both sort of do the job.
What do you think?


Well, we kind of do somethin in between. We also use transport from
external providers (such as a DWDM link). In such case, what we do is the
following:

[image: image.png]

In the example, we are using a DWDM transportation whose circuit-id
(defined by the provider) is 10265. So we just connect our devices in
RackTables end-to-end, but we document the transmission type (DWDM) and
circuit-id (10265) on the cable-id. We also append this information on the
visible-label.

So far we are using this method and it's working :-) ...

-- 
"Antes teníamos hambre y mirábamos el reloj para saber qué hora era. Ahora
miramos el reloj para saber si tenemos hambre." -- Ernesto Sábato

PNG image

Other related posts:

  1. Home
  2. racktables-users
  3. Archive
  4. 03-2020