Default Gateway for a system v/s Default gateway per Interface
Johnathan Mantey
johnathanx.mantey at intel.com
Tue May 5 02:14:05 AEST 2020
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 ??). 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 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.
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/20200504/03ec2469/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200504/03ec2469/attachment-0001.sig>
More information about the openbmc
mailing list