Default Gateway for a system v/s Default gateway per Interface
Ratan Gupta
ratagupt at linux.vnet.ibm.com
Fri May 8 16:35:35 AEST 2020
Jonathan,
On 5/4/20 9:44 PM, Johnathan Mantey wrote:
> Ratan,
>
> We're not using Windows. What is the Linux kernel/systemd going to do
> for the Metric? So far the only value that has been applied to the
> Metric is "0" (assigned by ??).
I was trying to explain your query "What does it mean to "use the
default metric"?" I am hoping the Idea would be same to understand the
behavior of default metric value.
In OpenBmc systemd assigns the default metric value for static
routes/DHCP routes(if the DHCP server is not providing the metric value)
Default Metric means what systemd-networkd assigns if the metric is not
given by the user(in case of static)/DHCP server. Static Routes gets
added as default metric value as 0 by systemd-networkd.
> As the Microsoft article points out, using a low value Metric for
> "private" nets is to be avoided.
> Our DHCP servers are supplying a Metric value of 1024. I'm sure other
> network managers use different values.
I am hoping that this behavior in your case is coming through
systemd-netwokd, I also observed this.
https://github.com/systemd/systemd/blob/c51c6f2f574e8c107994057c13a6506d93966a23/src/network/networkd-dhcp-common.h#L8
> I don't know how to solve this issue. Especially for the IPMI use case
> of assigning a static address. IPMI doesn't have the ability to assign
> metric values. At least with Redfish we can have that feature added.
As I mentioned before that we can come up with route management feature
where user can add/delete/update route(i.e) user can change the metric
value also for a route.
>
> On 5/4/20 6:38 AM, Ratan Gupta wrote:
>>
>>
>> On 4/29/20 12:19 AM, Johnathan Mantey wrote:
>>> I think I understand most of your plan.
>>>
>>> What does it mean to "use the default metric"?
>>
>> https://support.microsoft.com/en-in/help/299540/an-explanation-of-the-automatic-metric-feature-for-ipv4-routes
>>
>> Instead of user level application assigns the metric value, Let the
>> kernel decide which gateway should be used.
>>
>> I understand that there should be a way through which we should be
>> able to change the metric value but that can be implemented later
>> with some thing like route management where user should be able to
>> add HostRoutes/Network routes etc, chnaging the values of the routes
>> etc.
>>
>>>
>>> On 4/28/20 8:16 AM, Ratan Gupta wrote:
>>>>
>>>> Hi Jonathan,
>>>>
>>>> On 4/28/20 1:00 AM, Johnathan Mantey wrote:
>>>>> Ratan,
>>>>>
>>>>> Can you provide more info about how you plan to implement this?
>>>> I am not getting, Do you mean to say how to get the per interface
>>>> gateway from system? that would be through netlink, and during
>>>> configuration we would use the systemd-networkd file configuration.
>>>>>
>>>>> The Redfish schemas already have a per IP addr Gateway entry,
>>>>> which OBMC is ignoring. Is it better to modify the existing D-Bus
>>>>> schema (i.e. versioning discussion), or just use what is presently
>>>>> in existence?
>>>> Redfish schema are getting changed to accommodate this through the
>>>> following issue https://github.com/DMTF/Redfish/issues/3609.
>>>>
>>>> The above issue(gateway/interface) exist only for the IPv4 redfish
>>>> schema, IPv6 redfish is already having default gateway per interface
>>>>
>>>> http://redfish.dmtf.org/schemas/v1/EthernetInterface.v1_5_1.json#/definitions/EthernetInterface
>>>>
>>>>>
>>>>> That said, doing as you propose melds better with how IPMI (i.e
>>>>> Set LAN Configuration Parameter 12) works.
>>>>>
>>>>> As Patrick pointed out, there's no IPMI or Redfish control over
>>>>> the routing metric parameter. What are your thoughts on how to
>>>>> reconcile applying a metric value?
>>>> We will go with default metric value as today as underlying stack
>>>> tries for fallback gateway.
>>>>> I've long been desirous of getting Williams submission merged:
>>>>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-networkd/+/20799
>>>>> as it can be used to improve the collection of netlink stats.
>>>>>
>>>>> Redfish exacerbates this whole problem by allowing a collection of
>>>>> static IP addresses (and a DHCP addr) per NIC, unlike IPMI which
>>>>> was very one to one with IP addr/NIC.
>>>>>
>>>>> Thanks for investigating this and working to implement a solution.
>>>>>
>>>>> On 4/27/20 4:11 AM, Ratan Gupta wrote:
>>>>>>
>>>>>> Thanks Patrick, William for sharing the feedbacks
>>>>>>
>>>>>> I will start working on the changes.
>>>>>>
>>>>>>
>>>>>> On 4/24/20 11:15 PM, William Kennington wrote:
>>>>>>> Sounds good to me, we have needed this for a long time because
>>>>>>> the current gateway configuration breaks our v6 stack with
>>>>>>> multiple NICs.
>>>>>>>
>>>>>>> On Fri, Apr 24, 2020 at 8:21 AM Patrick Williams
>>>>>>> <patrick at stwcx.xyz <mailto:patrick at stwcx.xyz>> wrote:
>>>>>>>
>>>>>>> On Fri, Apr 24, 2020 at 08:36:26PM +0530, Ratan Gupta wrote:
>>>>>>> > ~~~~~~~~~~~~~
>>>>>>> > Kernel IP routing table
>>>>>>> > Destination Gateway Genmask Flags MSS
>>>>>>> Window irtt
>>>>>>> > Iface
>>>>>>> > 0.0.0.0 19.168.2.1 0.0.0.0 UG 0
>>>>>>> 0 0
>>>>>>> > eth0
>>>>>>> > 0.0.0.0 10.10.10.1 0.0.0.0 UG 0
>>>>>>> 0 0
>>>>>>> > eth1
>>>>>>> > ~~~~~~~~~~~~~~
>>>>>>> >
>>>>>>> > Kernel will first try using the default gateway having
>>>>>>> higher metric
>>>>>>> > value and then fall back to the lower.
>>>>>>>
>>>>>>> I'm not seeing us with an interface to adjust the metric for an
>>>>>>> interface. I think we need to add that at the same time?
>>>>>>>
>>>>>> Not now, As per my testing if metric value is not defined and
>>>>>> both the routes
>>>>>>
>>>>>> having same metric then kernel tries one after other. We can
>>>>>> bring the metric
>>>>>>
>>>>>> later.
>>>>>>
>>>>>>> Otherwise, I
>>>>>>> don't think we have a way to specify which interface
>>>>>>> outside-the-subnet
>>>>>>> should go (vs today we can set the default-gateway to the
>>>>>>> desired
>>>>>>> interface's gateway).
>>>>>>> --
>>>>>>> Patrick Williams
>>>>>>>
>>>>>
>>>>> --
>>>>> Johnathan Mantey
>>>>> Senior Software Engineer
>>>>> *azad te**chnology partners*
>>>>> Contributing to Technology Innovation since 1992
>>>>> Phone: (503) 712-6764
>>>>> Email: johnathanx.mantey at intel.com
>>>>> <mailto:johnathanx.mantey at intel.com>
>>>>
>>>> Ratan
>>>>
>>>
>>> --
>>> Johnathan Mantey
>>> Senior Software Engineer
>>> *azad te**chnology partners*
>>> Contributing to Technology Innovation since 1992
>>> Phone: (503) 712-6764
>>> Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>
>>>
>
> --
> Johnathan Mantey
> Senior Software Engineer
> *azad te**chnology partners*
> Contributing to Technology Innovation since 1992
> Phone: (503) 712-6764
> Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200508/722ae7f0/attachment-0001.htm>
More information about the openbmc
mailing list