starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

support for asdot notation for 4 Byte ASN #5910

New Issue
Closed
opened 2025-12-29 19:34:06 +01:00 by adam · 12 comments
adam commented 2025-12-29 19:34:06 +01:00
Owner
Copy Link

Originally created by @empusas on GitHub (Jan 9, 2022).

Originally assigned to: @jasonyates on GitHub.

NetBox version

v3.1.5

Feature type

Change to existing functionality

Proposed functionality

In the netbox url/ipam/asns/ and netbox ur>/ipam/asns/#/ view the AS Number should be displayed in asplain and asdot notation.
The db model does not have to be changed as we can still only store the asplain value in the db.

The actual conversion can be done in the web browser with some simple javascript like this:

 function conv_asplain2asdot() {
        asplain = document.AScalc.asplain.value;
        var asdot1 = (Math.floor(asplain/65536));
        var asdot2 = asplain%65536;
        document.AScalc.asdot1.value = asdot1;
        document.AScalc.asdot2.value = asdot2;
};

function conv_asdot2asplain() {
        var asdot1 = document.AScalc.asdot1.value;
        var asdot2 = document.AScalc.asdot2.value;
        asplain = ((parseInt(asdot1) * 65536) + parseInt(asdot2));
        document.AScalc.asplain.value = asplain;
};

Use case

4 Byte AS number get more popular these day and the asdot notation seems to be much easier to work with.

Database changes

not required, conversion can be done in javascript at runtime as mentioned above.

External dependencies

none

Originally created by @empusas on GitHub (Jan 9, 2022). Originally assigned to: @jasonyates on GitHub. ### NetBox version v3.1.5 ### Feature type Change to existing functionality ### Proposed functionality In the netbox url/ipam/asns/ and netbox ur>/ipam/asns/#/ view the AS Number should be displayed in asplain and asdot notation. The db model does not have to be changed as we can still only store the asplain value in the db. The actual conversion can be done in the web browser with some simple javascript like this: ``` function conv_asplain2asdot() { asplain = document.AScalc.asplain.value; var asdot1 = (Math.floor(asplain/65536)); var asdot2 = asplain%65536; document.AScalc.asdot1.value = asdot1; document.AScalc.asdot2.value = asdot2; }; function conv_asdot2asplain() { var asdot1 = document.AScalc.asdot1.value; var asdot2 = document.AScalc.asdot2.value; asplain = ((parseInt(asdot1) * 65536) + parseInt(asdot2)); document.AScalc.asplain.value = asplain; }; ``` ### Use case 4 Byte AS number get more popular these day and the asdot notation seems to be much easier to work with. ### Database changes not required, conversion can be done in javascript at runtime as mentioned above. ### External dependencies none
adam added the status: acceptedtype: feature labels 2025-12-29 19:34:06 +01:00
adam closed this issue 2025-12-29 19:34:06 +01:00
adam commented 2025-12-29 19:34:07 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 9, 2022):

I understand this was done in JS, but should this also be targetted for the API or do you think it is not needed as API consumers should be capable of handling it?

@DanSheps commented on GitHub (Jan 9, 2022): I understand this was done in JS, but should this also be targetted for the API or do you think it is not needed as API consumers should be capable of handling it?
adam commented 2025-12-29 19:34:07 +01:00
Author
Owner
Copy Link

@empusas commented on GitHub (Jan 9, 2022):

I think is is just more convenient for humans. As the conversion can be done really simple API users should be able to convert themself.
But you are right, it could be done on the server side as well, while keeping only the asplain value in the DB.

@empusas commented on GitHub (Jan 9, 2022): I think is is just more convenient for humans. As the conversion can be done really simple API users should be able to convert themself. But you are right, it could be done on the server side as well, while keeping only the asplain value in the DB.
adam commented 2025-12-29 19:34:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2022):

In the UI, we can just display both formats in the UI for AS number larger than 65535. We should also come up with a custom form field to handle input in either format. IMO though the REST API should only return the plain integer format.

@jeremystretch commented on GitHub (Jan 10, 2022): In the UI, we can just display both formats in the UI for AS number larger than 65535. We should also come up with a custom form field to handle input in either format. IMO though the REST API should only return the plain integer format.
adam commented 2025-12-29 19:34:07 +01:00
Author
Owner
Copy Link

@empusas commented on GitHub (Jan 10, 2022):

How do you want to add it in? Extend the ASN base class with the conversion functions or just add it into the table creation?

@empusas commented on GitHub (Jan 10, 2022): How do you want to add it in? Extend the ASN base class with the conversion functions or just add it into the table creation?
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@jasonyates commented on GitHub (Jan 11, 2022):

What would be the best way to display this?

With an additional row:
Screenshot 2022-01-11 at 22 56 11

Appending the asdot version alongside the asplain. E.g.:
Screenshot 2022-01-11 at 22 56 42

Same would apply to the table view. An extra column or appending it after the existing value.

@jasonyates commented on GitHub (Jan 11, 2022): What would be the best way to display this? **With an additional row:** <img width="713" alt="Screenshot 2022-01-11 at 22 56 11" src="https://user-images.githubusercontent.com/242483/149034600-251e5c74-8229-4ead-bec4-ea850d3849df.png"> **Appending the asdot version alongside the asplain. E.g.:** <img width="692" alt="Screenshot 2022-01-11 at 22 56 42" src="https://user-images.githubusercontent.com/242483/149034610-c6384324-30ea-4441-bc6f-63d195612cc1.png"> Same would apply to the table view. An extra column or appending it after the existing value.
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 12, 2022):

I would just put it in parentheses immediately following the first value.

@jeremystretch commented on GitHub (Jan 12, 2022): I would just put it in parentheses immediately following the first value.
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Jan 18, 2022):

In 3.1.6 now the /ipam/asns/ list shows ASN as AS-dot only....... was that really the purpose?

I would expect most people want to see proper ASN4 in most of the places and AS-dot should be optional additional info only.
image

Note also the column header says Asn while it should probably say ASN.

@bluikko commented on GitHub (Jan 18, 2022): In 3.1.6 now the `/ipam/asns/` list shows ASN as AS-dot only....... was that really the purpose? I would expect most people want to see proper ASN4 in most of the places and AS-dot should be optional additional info only. ![image](https://user-images.githubusercontent.com/14869000/149872712-371a425d-2bec-461d-8d16-9cae0ac216fa.png) Note also the column header says `Asn` while it should probably say `ASN`.
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@eimann commented on GitHub (Jan 18, 2022):

Interesting so see asdot appearing again, I though we threw this away many years ago.

asplain is the recommeded and preferred way to represent AS numbers, as all devices and tools on non-ancient versions do:
https://datatracker.ietf.org/doc/html/rfc5396#section-3

@eimann commented on GitHub (Jan 18, 2022): Interesting so see asdot appearing again, I though we threw this away many years ago. asplain is the recommeded and preferred way to represent AS numbers, as all devices and tools on non-ancient versions do: https://datatracker.ietf.org/doc/html/rfc5396#section-3
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@nickhilliard commented on GitHub (Jan 18, 2022):

It would be really great to see this commit fully reverted. asdot is a dysfunctional representation format which offers no real benefit, but consistently adds confusion. Some points to consider:

  • the rest of the world stopped using asdot years ago
  • what happens when we're talking about ASx.xxxxx? There are no fewer digits to remember in the majority of ASNs likely to be assigned by RIRs in the coming years.
  • how do you usefully represent private AS numbers (4000000000 - 4294967294)? For example, the first ASN in this range is AS4000000000, or AS61035.10240 in asdot format. Which is easier to remember?
  • supporting asdot as a representation format perpetuates problems with toolchain complexity

As @eimann mentioned, the IETF published RFC5396 in 2008 as a Standards Track document, which requests that asplain be used. This is the IETF equivalent of saying: "formal standards request: please use only asplain for text representation of ASNs".

@nickhilliard commented on GitHub (Jan 18, 2022): It would be really great to see this commit fully reverted. asdot is a dysfunctional representation format which offers no real benefit, but consistently adds confusion. Some points to consider: - the rest of the world stopped using asdot years ago - what happens when we're talking about ASx.xxxxx? There are no fewer digits to remember in the majority of ASNs likely to be assigned by RIRs in the coming years. - how do you usefully represent private AS numbers (4000000000 - 4294967294)? For example, the first ASN in this range is AS4000000000, or AS61035.10240 in asdot format. Which is easier to remember? - supporting asdot as a representation format perpetuates problems with toolchain complexity As @eimann mentioned, the IETF published RFC5396 in 2008 as a Standards Track document, which requests that asplain be used. This is the IETF equivalent of saying: "formal standards request: please use only asplain for text representation of ASNs".
adam commented 2025-12-29 19:34:08 +01:00
Author
Owner
Copy Link

@empusas commented on GitHub (Jan 18, 2022):

I am working for one of the biggest providers in the world and have to deal with 4 Byte ASN every day.
In a single tenant environment you may have the luxury to randomly assign simple to remember private ASN, but the reality in a big provider looks very different.
Most bigger companies come up with a proper concept to assign private IPs.
I have a customer that uses the first 2 byte to identify the service, the 2nd 2 byte to identify the site.
if you got ASN 63000.50000 vs ASN4128818000, which is easier to work with now? So to me that is no argument at all.

I was meant as an aid for those who use asdot for whatever reason.

I agree that it was not executed as intended. Now it shows only the asdot in the overview list and asplain everywhere else.
The proposal was to display both where possible. I see no harm in displaying both when feasible and maybe come up with a auto convert function if someone enters asdot instead of asplain.

@empusas commented on GitHub (Jan 18, 2022): I am working for one of the biggest providers in the world and have to deal with 4 Byte ASN every day. In a single tenant environment you may have the luxury to randomly assign simple to remember private ASN, but the reality in a big provider looks very different. Most bigger companies come up with a proper concept to assign private IPs. I have a customer that uses the first 2 byte to identify the service, the 2nd 2 byte to identify the site. if you got ASN 63000.50000 vs ASN4128818000, which is easier to work with now? So to me that is no argument at all. I was meant as an aid for those who use asdot for whatever reason. I agree that it was not executed as intended. Now it shows only the asdot in the overview list and asplain everywhere else. The proposal was to display both where possible. I see no harm in displaying both when feasible and maybe come up with a auto convert function if someone enters asdot instead of asplain.
adam commented 2025-12-29 19:34:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 18, 2022):

This FR was for a trivial change regarding how a numeric value is displayed, so in hindsight I should have expected steadfast opposition from network engineers. 😛

For some context, this change was implemented simply because:

  1. Someone proposed a well-reasoned change
  2. No one opposed it
  3. A second person volunteered to do the work

It's fine to disagree with the change and do argue against it, but let's remember not to make blanket assumptions about NetBox's user base. Obviously the change had value for the person who proposed it; otherwise it would not have been proposed. The mere fact that the ASDOT format exists in the first place is evidence enough that some people prefer it.

#8375 has been opened to revert the change. I don't think it's necessary to fully revert it, but clearly we should have given users greater control over the format used to display AS numbers. I'm going to continue the discussion under that FR as this issue has been closed, and will ask folks to refrain from commenting here any further as the opposition has been sufficient registered.

@jeremystretch commented on GitHub (Jan 18, 2022): This FR was for a trivial change regarding how a numeric value is displayed, so in hindsight I should have expected steadfast opposition from network engineers. :stuck_out_tongue: For some context, this change was implemented simply because: 1. Someone proposed a well-reasoned change 2. No one opposed it 3. A second person volunteered to do the work It's fine to disagree with the change and do argue against it, but let's remember not to make blanket assumptions about NetBox's user base. Obviously the change had value for the person who proposed it; otherwise it would not have been proposed. The mere fact that the ASDOT format exists in the first place is evidence enough that _some_ people prefer it. #8375 has been opened to revert the change. I don't think it's necessary to fully revert it, but clearly we should have given users greater control over the format used to display AS numbers. I'm going to continue the discussion under that FR as this issue has been closed, and will ask folks to refrain from commenting here any further as the opposition has been sufficient registered.
adam commented 2025-12-29 19:34:09 +01:00
Author
Owner
Copy Link

@lamoni commented on GitHub (Feb 2, 2022):

+1 for there being a choice.

While I respect the references to ~14 year old RFCs, times have changed as well and the way we use these things have changed.

For my own anecdotal experience, Clos data centers running BGP-only seem (emphasis on "seem". Anecdotal, remember?!) to always be configured and diagrammed using ASDOT, where the first 16 bits are used to denote something like a site code and the second 16 bits are used to differentiate the spines and leafs, etc..

It's very similar to IP addresses in my mind, and these arguments to forego ASDOT these days makes me wonder why we don't just use the decimal format for IP addresses then too if there is no benefit to using non-base10 representations of the numbers we work with every day to make them easier on the eyes and quicker to parse visually ;)

E.g.

Your spines might be configured with:

65201.10100

And then your leafs have their own:

Leaf1 - 65201.10101
Leaf2 - 65201.10102
Leaf3 - 65201.10103

Compare that to their ASPLAIN versions:

4273022836

Leaf1 - 4273022837
Leaf2- 4273022838
Leaf3 - 4273022839

@lamoni commented on GitHub (Feb 2, 2022): +1 for there being a choice. While I respect the references to ~14 year old RFCs, times have changed as well and the way we use these things have changed. For my own anecdotal experience, Clos data centers running BGP-only seem (emphasis on "seem". Anecdotal, remember?!) to always be configured and diagrammed using ASDOT, where the first 16 bits are used to denote something like a site code and the second 16 bits are used to differentiate the spines and leafs, etc.. It's very similar to IP addresses in my mind, and these arguments to forego ASDOT these days makes me wonder why we don't just use the decimal format for IP addresses then too if there is no benefit to using non-base10 representations of the numbers we work with every day to make them easier on the eyes and quicker to parse visually ;) E.g. Your spines might be configured with: 65201.10100 And then your leafs have their own: Leaf1 - 65201.10101 Leaf2 - 65201.10102 Leaf3 - 65201.10103 Compare that to their ASPLAIN versions: 4273022836 Leaf1 - 4273022837 Leaf2- 4273022838 Leaf3 - 4273022839
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5910
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?