How am I *supposed* to store default gateways?

[grinapo]

I have read through several issues [like #330 #819 #1434 #1610 #2163 #2953 #3109 #3237 ] where people have tried to figure out how to store the gateway(s) for a given subnet, by trying IP roles, tags, and various other ideas. As far as I see most of these issues were closed as various kinds of "bad idea".

However I don't really see how am I supposed to record defgw then?

For IPv4 it is an address, most of the time, so either an address or an interface+address acts as a default gateway; I expect to see the gateway when I open a subnet, an address or the list of interfaces, and these various mutations.
Theoretically I could tag addresses as "defgw" but the tag is not shown in almost any lists: not in prefixes (various forms), child prefixes or addresses, so the usability of it is close to none.

For IPv6 there may be multiple routers present and they are usually connected to specific interfaces, but they almost can be related to the v6 prefixes as well. Obviously tagging doesn't help here either.

As for contrast we've been using a different program for IPAM for years which can mark any address as "gateway", and when one pulls up a data sheet of a subnet both the gateway addresses and the interfaces of the routers are listed, extremely conveniently. It is also the way to draw IP topology automagically, like running "virtual traceroute" and draw the path throughout various vlans, VRFs and stuff.

Why this seems to be a largely ignored part in NB?

[candlerb]

Have you considered adding a custom field on the prefix? (Although it would have to be plain text, as "IP address" is not one of the options)

It's not something I've ever felt the need to store, as we have the simple rule that the first available IP address in every subnet is the gateway. Of course, this may be a VRRP or CARP address, and the real gateways are using the next addresses.

[grinapo]

I am not sure that the interface could be modified by a plugin to show it everywhere where a prefix, an interface or a host related to a prefix is shown. For "recording defgw state" tags could work as well as the custom field but neither of those would show up in lists and searches in IPAM. 😞

Storing the defgw information in a human ("we have the simple rule that the first available IP address in every subnet is the gateway") is not really a solution, especially when using ipv6, where an interface may be broadcasting RAs. And especially especially not working when there are incompatible kind of humans integrated into the same system (like after many company mergers).

[candlerb]

Being able to include custom fields as columns in listing views would be a useful feature request in its own right, IMO.

Re IPv6: if you are using RAs then the client picks up the default gateway from those automatically, so there's no need to configure the clients from Netbox data. The routers themselves do need to be configured whether to advertise RAs or not on a given subnet; tags or config contexts are probably the right way to approach that.

If you're not using RAs, then the rule that xxxx::1 is the gateway still works.

[grinapo]

There is two different use cases here:

• recording and storing information, and/or
• configuring devices based on stored information.

I am talking about information store and retrieval, not configuration (which does not mean it can't be used for that), or CMDB. We use defgw lookup to delegate a problem to the responsible people, for example, or to aid investigation, to prevent physically entering the devices and comb out the information from often mindboggingly complex configurations.

Technically, though, it is right that if tags would be shown in all prefix lookups and lists, it would solve half of the problems (since in prefix/ip list the defgw would be visible).

Probably the other half could be solved by a functionality to be able to actually show/list ip+interface records of given tags on the prefix/ip data sheets; so, for example, I would tag gateway addresses as "gw" and I'd set that "gw" tags shall show up on the prefix page, with active link to the IP, subnet, interface and host possessing it. This way gw's would be listed and could be easily clicked through (and, magically, topology would be possible to draw as well).

I still would not subscribe to keep information in humans. ;-)
(Example: we use first IP as gateways for decades. A merged pretty large company always have used last IP for decades. Nobody want to readdress hundreds of routers in various functionality. And then there's the other merged company using whatever IP they wanted for gws. Not all were renumbered as well.)

[jeremystretch]

Why this seems to be a largely ignored part in NB?

The default gateway for any device is just a component of your network's routing topology, which NetBox does not model. There's nothing special about the default route, nor is there any requirement that all interfaces within a prefix must use the same default gateway(s). The flow of traffic is entirely dependent upon your network's routing topology, which NetBox does not model.

[grinapo]

I have read this several times from you @jeremystretch , yes.

First, it is not clear to me why do you think this is not an integral part of IPAM, while NB already contains [physical] topology through interface interconnection. IP topology is not really a magic orb: packets go to either Layer2 endpoints (which you already model through VLANs) or hop through Layer3 routers (which you already touch by using VRFs and NATs; and there are a limited amount of in-the-wild protocols to pick the gw, and in the majority of cases it's either one static, prefix-connected gateway or multiple "static" gateways using some dynamic routing protocol, be that iBGP or Router Advertisement@IPv6). For most of the users it's fairly simple: prefixes have some IPs flagged as "gateways" and where these IPs reside show which interface of which hosts are the gateway for that specific prefix.
For IPv6 this may be rather the interface where the prefix is active (since many just enable RA on the link local address, while others use dedicated static globally accessable addresses), I haven't pondered about that yet.

Second, to me it seems rather obvious that people need this functionality. It seems to be a FAQ, issues repeatedly created and closed, so it seems to me that there is a demand for that feature and I don't immediately see the downsides of implementing it. I really wonder about the reasons to reject it repeatedly, since the implementation seems rather simple. (Also I have mentioned that I am using XXXX for years where we exactly use this functionality with great satisfation, so I have seen a working implementation for what I am talking about.)

Third, my original question stands: where do you suggest to record this, along with other(?) topology information? Where do you keep it (if not in IPAM)? I guess you have a solution and it may be the reason behind not wanting to implement it.

Thank you!

[julianze]

I have read many issues regarding that.

IMHO:
I think we should distinguish first between the wording "default gateway" and "gateway".

---

Default gateway is the default routing information from the devices's point of view.
Every device should have at least one default gateway. But with several NICs there might be more default gateways or gateway informations for some specific destination prefixes within a device.
A default gateway (.254 - router) for devices A can differ with device B in the same subnet (.1 - dedicated loadbalancer).
A device with two NICs has in example the default gateway to subnet A (data access) and the second NIC is in subnet B (storage access).
The device doesn't have gateway/routing information via/for subnet B, because it will only access the storage in the directly connected network. An other device (storage controller) in the same subnet B has a default gateway, because it has to be communicate with external servers.

Again, all this depends on the devices's point of view and will be differ in many infrastructures out there.
I don't think we can model this "point of view" right now in an easy way in netbox.

I think this is a main reason why Jeremy can't agree with our proposals. I hope that i didn't misunderstood your answers in those issues, please correct me @jeremystretch if i am wrong.

---

Our main goal is to document gateway informations for prefixes. A gateway is a combination of a device, an interface and a corresponding ip address on this interface.
A gateway has the function to route between directly connected networks or forward the packets to another gateway which know the right path to the destination.

It's the "exit" out of a subnet.
There could be more than one gateway (router, loadbalancer, vpn gateway etc) in a subnet and a device can be gateway in several subnets due to several Interfaces.

A gateway isn't only a device or an ip address,
so we can't threat those models in netbox exclusively as gateway.

---

So how can we put those information in a correct way to netbox?
devices, interfaces and ip addresses are put together in the assignment of an ip address to an interface of a device.
Maybe there is the correct place?
Like adding a checkbox for 'is gateway'?

In the UI it could be visualize as follows:

---

I have looked around how other tools handles this.
In Racktables those gateway information is configured in the allocation of an ip address as 'router'-type to an interface:

(see http://demo.racktables.org, User: admin // Password: admin)

---

What you are thinking about that?

[sbj-ee]

I just mark the gateway IPs as "reserved" and put "gateway" in the description.

My company just started using 6connect - oy vey... All devices go in as a /32 which is so freaking annoying. I have to hop on the routers to find the subnet mask.

netbox has been awesome for me. My records for 153 racks so far has never been so accurate.

[grinapo]

I just mark the gateway IPs as "reserved" and put "gateway" in the description.

The main problem with all the hacky manual solutions is that they are not database entries: your description won't appear for interfaces, subnet lookups, cannot be searched, etc.

[ITJamie]

we have just come close to the trigger point on the move from racktables to netbox, all other objects are now migrated and "in sync" with racktables, only to now realise this is an issue.
previous org i worked in had made customisations to handle this similar to @julianze 's suggestions.
I am now in the situation of ether needing to mod some of core netbox or figure out how to do this via a plugin. pretty shocked as this wasnt something i even considered as being an issue before

[kkthxbye-code]

almost as a simple text information field

The upcoming version 3.2 allows custom fields to reference other objects. So you would be able to create a custom field on prefixes that points to an ip address object. I'm sure this doesn't solve all your problems, but it might help.

[grinapo]

The upcoming version 3.2 allows custom fields to reference other objects. So you would be able to create a custom field on prefixes that points to an ip address object. I'm sure this doesn't solve all your problems, but it might help.

I wonder. Like noticed that there is "bridge" functionality now but it works in a peculiar way:

• I cannot connect VM interfaces to vhost bridges (I'm still a bit puzzled about recording VM topology, since, for example, an access mode vm interface may be connected to a vhost bridge which has a member of a vlan tagged interface, logically putting the bridge in that vlan, logically putting the VM interface in that vlan, too. And the bridge may connect to multiple vlans in multiple segments, though I do not have such topology.)
• interfaces (and various object screens) are not aware that they are "member of a bridge group" (it is not visible)

One path of the workflow, for example, is to get an IP and see its vlan, its gateway IP(s) and host(s).
Other is to get a VLAN and see the gateway(s) within.
Or to get interfaces of a host and see which hosts are the gateways for which interfaces.

[candlerb]

interfaces (and various object screens) are not aware that they are "member of a bridge group" (it is not visible)

It is for me, on Netbox v3.1.7:

If you want it in an listing page, then click the configure table button to add it as a column.

Bridges only exist within a "device", and they represent as you say bridge groups. These bridge groups aren't VLAN-aware per se, but if you create a bridge called "br1" then you can create child interfaces like "br1.100" and "br1.200", just like on a physical interface.

You cannot connect device them to a "VM" because VMs belong to a cluster, not a device, and are mobile between all the devices in a cluster.

You can model a VM as having an access port on VLAN 123, and you can model a device physical port as having a trunk port containing VLAN 123, and that's all you need. The VM knows which VLAN it is on, and you can trace it through the device if you really need to.

One path of the workflow, for example, is to get an IP and see its vlan, its gateway IP(s) and host(s).
Other is to get a VLAN and see the gateway(s) within.
Or to get interfaces of a host and see which hosts are the gateways for which interfaces.

There is explicit linkage between prefix and VLAN, and implicit linkage between IP address and prefix. That handles all of those cases:

• IP -> Prefix -> VLAN; IP -> Prefix -> gateway (custom field); IP -> Prefix -> child addresses -> hosts
• VLAN -> Prefix(es) -> gateway(s)
• Interfaces -> IPs -> Prefixes -> gateways

I'm assuming that today you will model the default gateway on a prefix as a text custom field, and in future you'll be able to link it to an IP address object. A tagged IP address is another option, but that is harder to find.

[grinapo]

interfaces (and various object screens) are not aware that they are "member of a bridge group" (it is not visible)
It is for me, on Netbox v3.1.7:

(I thought I responded this but it seems pressing the Reply button below really helps.)

I think my main problem was the empty "bridge" page:

There seems to be not reference to bridge group members.

If you want it in an listing page, then click the configure table button to add it as a column.

Indeed, that was a mind slip from me. Thanks!

Bridges only exist within a "device", and they represent as you say bridge groups. These bridge groups aren't VLAN-aware per se, but if you create a bridge called "br1" then you can create child interfaces like "br1.100" and "br1.200", just like on a physical interface.

I will try to build a complete example based on this and see whether it worked.

You cannot connect device them to a "VM" because VMs belong to a cluster, not a device, and are mobile between all the devices in a cluster.

Yes, that is true, however the cluster hosts have to provide the same bridge view all over the cluster members (or migration would not work), so there are "clusterwide bridges" (actually consisting "physically" multiple similarly configured ones), connecting to a specific interface or vlan.

I see the problem connecting such "virtual bridges" to physical ports; logically these virtual bridges consist of (or contain) physical bridges on the vhosts, which connect to physical interfaces connecting physical ports. I am not sure netbox even tries to model topology, so this may be a bit offtopicly specific description. :-) (In Racktables we have to model these using internal switches, to make it possible to automatically walk connections from VM to physical switch ports or VLANs, which is just another hack.)

You can model a VM as having an access port on VLAN 123, and you can model a device physical port as having a trunk port containing VLAN 123, and that's all you need. The VM knows which VLAN it is on, and you can trace it through the device if you really need to.

The usual problem with this approach is incosistency, since the independently recorded data may get out of sync if someone forgets to update one side. Obviously I have to do exactly that to be able to identify VLANs, even if that won't trace them to ports easily.

There is explicit linkage between prefix and VLAN, and implicit linkage between IP address and prefix. That handles all of those cases:

I have to check those a well.

I'm assuming that today you will model the default gateway on a prefix as a text custom field, and in future you'll be able to link it to an IP address object. A tagged IP address is another option, but that is harder to find.

None of these seemed to work very well, unfortunately.

[candlerb]

There seems to be not reference to bridge group members.

You're correct that there isn't a section in the interface page for bridge group members. I previously raised this as #8163 - add a thumbs-up there if this matters to you.

[savv3]

Found my way here looking for a way to mark a single IP as default gateway, and I'm flabbergasted to find that there's now "real" way of doing it. I was looking into moving to NB from phpIPAM (where this is possible), as the ansible modules for NB are much more comprehensive.
In our case we query the API for the subnet information so we can statically set the interface IP address, subnet, gateway and DNS servers when we provision the server.

[a084ed22]

you can add a custom field as needed. Arguably, the default gateway is a property of each specific system and not of the network, so I think it is correct that this is not provided as part of the prefix or ip address model.

[savv3]

Thanks for your reply!
I understand the argument, but I don't agree. With that logic, an IP address could be considered a property of a specific system. Just because I don't need to set the gateway of a subnet, doesn't mean I shouldn't have the option.

[grinapo]

Arguably, the default gateway is a property of each specific system and not of the network, so I think it is correct that this is not provided as part of the prefix or ip address model.

You may misunderstand the purpose. The defgw is one (or multiple) attribute of a (layer3) subnet, and that is documented, and hosts (interfaces) member of said subnet shall use this (or these or any of those) gateways (and it may be separately documented, or manually overridden, but usually isn't, since it's exatly the automatic process I'm looking for). All of the machines use the same gw when they use static routing table.

So you set 192.168.42.1 as the def gw for 192.168.42.0/24, and when you go to any interfaces having an ip in this subnet you will see that the matching gw is 192.168.42.1. Also the network data sheet shows that attribute, along with others.

[xkilian]

What we document is the following: What are the L3 devices connected to a given prefix. This may be typically a router, firewall or similar device.

• This is displayed in the prefix view as a custom-field, named L3_Connexion.
• The custom field is of Multiple object Type.

From the prefix view it is thus easy for a given subnet to know what routing devices are responsible for it. This is required because devices belonging to a prefix may be in multiple physical sites. We needed to know quickly to what routing devices are associated from the prefix view from a network planning perspective.
Because these are objects, the link points to a devices or virtual chassis and is not a text field.
This is also independant to having created an actual IP interface on the routing devices.
As you typically assign the subnet first, associate your devices, then go assign a virtual or physical interface on your device and then assign the IP. You are not designating an IP interface as a gateway, but the data can be derived if you start your query from the prefix view.
A report/extraction could be automated.
This data could be exposed in a web UI with a nice search UI to find out what is the IP interfaces of the routers on each prefix. Expose it in grafana or whatever web platform you use for maintenance or even expose it is a Netbox plugin.
Hope this helps someone.

[grinapo]

Usually the most important difference between manually doing whatever I please (like "tagging" defgw, or putting it into a note) is consistency: when it's part of the storage schema updating the subnet "updates" everything in the subnet, and no need to manually go around 1e30 interfaces and update them one by one. That is my main pain point here since no matter how I hack it, it will not be and stay consistent, and requires manual updates for both the network and the interfaces.

[jeremystretch]

1. Please don't reply to a thread that is nearly two years old to start a new discussion.
2. There is no such thing as a default gateway for a prefix. A default gateway is configured on each host individually. These are usually the same for all end hosts, but not necessarily: It is perfectly valid for different hosts to use different default gateways within a common prefix. Thus, there is no "default gateway" field on the prefix model.
3. In a scenario where you are willing to ignore this reality, you can easily apply a tag or custom field to designate a default gateway for a prefix. Better, though, is to determine the default gateway for applicable segments programmatically (e.g. by using the first available host IP in each prefix), which obviates the need to explicitly track this relationship at all.

[grinapo]

1. Why? This is a discussion (in fact you have converted it to a discussion because you have rejected it as an issue), and it have not been "fixed"/resolved (in these nearly two years). If you already decided that no matter what logical reasons come up you reject the idea then you can ignore it, as you have done in the past. Also you may have noticed that there is significant desire to have the feature.
2. You are ignoring real world use and talk about theory. In reality most networks do have a defined gateway, usually one gateway, and often it's even distributed by DHCP. In static cases hosts use the one defined gateway when they are in the specified L2 domain. What I said (and you may have missed) that it may be sometimes required to manually override the network-assigned global defgw at a specific host (or, as I also mentioned, using multiple gateways/multipath) but this is very rare compared to the rest, and still can be easily integrated in the GUI logic. Since you have rejected the idea from the start there was no discussion about it, nobody had the chance to look at the (possible) border cases and think about the UI. (We are using Racktables right now to manage a rather large number of networks and I have real-life experience how defgw is out there, in heterogenous networking environments, many of them SOHO.)
3. You are unnecessary rude, and you wouldn't be happy to hear reflected it back to you. What you say doesn't work because it does not keep it consistent, and does not make it referenced from all the places a network is referenced. (It is also very unfortunate in the UI since it requires a lot of clicks to get to the information, or it is not visible in summaries, where it would be needed most.) Also "programmatically" is not possible in heterogenous/multitenant environments.

One question you haven't asked (of the many) is that why would this be useful at all?
For me it's because the UI is used not only by network engineers but guys who work with the suff, ranging from cabling through problem investigation to new deployments at SOHO side. People can retrieve information with much more clicks than required, but still maintaining the data without enforced consistency is extremely error-prone in large networks.

[jeremystretch]

I'm not going to argue with you. I've explained why NetBox doesn't do what you're asking. If that doesn't work for you, you're free to fork the project and modify it however you see fit.

Locking this thread as the discussion has concluded.