On Thu, Jun 01, 2017 at 09:08:45AM +0200, Matthias May wrote:
> On 31/05/17 18:29, Greg Rose wrote:
> > On Wed, 2017-05-31 at 08:32 -0700, Ben Pfaff wrote:
> >> On Wed, May 31, 2017 at 11:39:28AM +0200, Matthias May wrote:
> >>> On 27/05/17 04:29, Hunt Xu wrote:
> >>>> On Fri, May 26, 2017 at 11:46 PM, Ben Pfaff <[email protected]> wrote:
> >>>>> It's becoming more common that OSes include "ip" but not "ifconfig", so
> >>>>> it's best to avoid using the latter.  This commit removes most 
> >>>>> references
> >>>>> to "ifconfig" and replaces them by "ip".  It also adds a build-time 
> >>>>> check
> >>>>> to make it harder to introduce new uses of "ifconfig".
> >>>>>
> >>>>> Signed-off-by: Ben Pfaff <[email protected]>
> >>>>> ---
> >>>>
> >>>> <snip>
> >>>>
> >>>>> diff --git a/Documentation/faq/issues.rst b/Documentation/faq/issues.rst
> >>>>> index c60336a10569..82d0605da125 100644
> >>>>> --- a/Documentation/faq/issues.rst
> >>>>> +++ b/Documentation/faq/issues.rst
> >>>>> @@ -43,8 +43,8 @@ eth0.  Help!
> >>>>>      itself.  For example, assuming that eth0's IP address is 
> >>>>> 192.168.128.5, you
> >>>>>      could run the commands below to fix up the situation::
> >>>>>
> >>>>> -        $ ifconfig eth0 0.0.0.0
> >>>>> -        $ ifconfig br0 192.168.128.5
> >>>>> +        $ ip addr flush dev eth0
> >>>>> +        $ ip addr add 192.168.128.5 dev br0
> >>>>
> >>>> ip addr add 192.168.128.5/24 dev br0
> >>>>
> >>>> It seems using ifconfig without specifying any netmask the 
> >>>> netmask/prefixlen
> >>>> will still be properly set (not diving quite deep, but strace indicates 
> >>>> that
> >>>> this is not done by ifconfig, ifconfig don't even try to set the 
> >>>> netmask),
> >>>> whlie using ip-address with only the address specified the prefixlen is
> >>>> always 32.
> >>>>
> >>>> Some tests on my Ubuntu 16.04:
> >>>> 1a. ifconfig br0 192.168.128.5 -> br0 gets 192.168.128.5/24
> >>>> 1b. ip addr add 192.168.128.5 dev br0 -> br0 gets 192.168.128.5/32
> >>>> 2a. ifconfig br0 172.16.128.5 -> br0 gets 172.16.128.5/16
> >>>> 2b. ip addr add 172.16.128.5 dev br0 -> br0 gets 172.16.128.5/32
> >>>> 3a. ifconfig br0 10.0.128.5 -> br0 gets 10.0.128.5/8
> >>>> 3b. ip addr add 10.0.128.5 dev br0 -> br0 gets 10.0.128.5/32
> >>>>
> >>>>>
> >>> *snip*
> >>>
> >>> You might want to consider to add brd + to the ip command.
> >>> E.g. ip addr add 192.168.128.5/24 brd + dev br0
> >>>
> >>> Without:
> >>> 7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group 
> >>> default qlen 1000
> >>>     link/ether 1a:78:fe:72:9c:be brd ff:ff:ff:ff:ff:ff
> >>>     inet 192.168.128.5/24 scope global br0
> >>>        valid_lft forever preferred_lft forever
> >>>
> >>> With:
> >>> 7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group 
> >>> default qlen 1000
> >>>     link/ether 1a:78:fe:72:9c:be brd ff:ff:ff:ff:ff:ff
> >>>     inet 192.168.128.5/24 brd 192.168.128.255 scope global br0
> >>>        valid_lft forever preferred_lft forever
> >>>
> >>> As you can see the broadcast address isn't set without.
> >>>
> >>> I see you already posted a v4 but this comment seems more appropriate in 
> >>> this thread.
> >>
> >> What happens if no broadcast address is specified?  I've never seen
> >> instructions say that one should specify this, so I really wonder
> >> whether it is necessary.
> > 
> > My understanding of this is that the brd command is used to over ride
> > the broadcast address that would normally be computed by specifying the
> > IP/CIDR.  I don't think it is necessary and I don't generally specify it
> > in normal usage.
> > 
> > Thanks,
> > 
> > - Greg
> 
> Well it may not be needed from a technical point of view, but the output 
> differs compared to when the address is added
> with ifconfig.
> brd + also automatically sets the broadcast address based on netmask and 
> address, and the output then is identical to
> when the address is set with ipconfig.

It's true.  If it turns out to cause a problem, we'll try adding it.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to