Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #226365 > unrolled thread

In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Back to article view | Back to linux.debian.user

Contents

  In network bonding second nic (eth1) is not pingable while first one  (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-21 17:20 +0200
    Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Dan Ritter <dsr@randomstring.org> - 2020-08-21 18:10 +0200
      Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable" deloptes <deloptes@gmail.com> - 2020-08-21 19:40 +0200
      Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-22 07:50 +0200
        Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable" deloptes <deloptes@gmail.com> - 2020-08-22 09:50 +0200
      Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-22 13:20 +0200
        Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Dan Ritter <dsr@randomstring.org> - 2020-08-22 13:50 +0200
          Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Lee <ler762@gmail.com> - 2020-08-22 14:30 +0200
            Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Dan Ritter <dsr@randomstring.org> - 2020-08-22 14:50 +0200
              Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Lee <ler762@gmail.com> - 2020-08-22 16:00 +0200
                Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-22 17:10 +0200
          Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-22 17:00 +0200
            Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Dan Ritter <dsr@randomstring.org> - 2020-08-22 18:10 +0200
              Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable" deloptes <deloptes@gmail.com> - 2020-08-23 21:20 +0200
                Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-24 11:30 +0200
                  Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable" deloptes <deloptes@gmail.com> - 2020-08-24 22:10 +0200
                Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Andy Smith <andy@strugglers.net> - 2020-08-24 13:20 +0200
              Re: In network bonding second nic (eth1) is not pingable while first  one (eth0) is always pingable" Jaikumar Sharma <jaikumar.sharma@gmail.com> - 2020-08-24 11:50 +0200

#226365 — In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Hi folks,

I'm using Debian 10 (point release 5) and i've set up the bonding for
eth0 and eth1 in 'active-backup' mode, i'm using virtualbox VM for
testing it, if i disconnect cable (virtually from first ethernet -
eth0) ping to bond0 IP stops and if i disconnect it from eth1 and
reconnect on eth0 ping again start working. Do not really know what is
wrong!

Problem in [1] (searched mail archives) is same but no solution is
given there or user did not respond further on it, he/she might have
found the solution already, though there are some tests which i've
performed as mentioned in [1] and without bonding (dual network mode)
I can ping both IP from remote.
In this setup i'm using a D-Link 8 port switch to connect eth0 using
ethernet cable and eth1 is connected on wireless adapter of my laptop.

Does somebody know what may be wrong?

[2] bonding output:
user@myhost:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth0 (primary_reselect always)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:be:86:95
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:3a:6e:db
Slave queue ID: 0

[3] configuration : /etc/network/interfaces
user@myhost:~$ cat /etc/network/interfaces
# this file describes the network interfaces available on your system
# and how to activate them. for more information, see interfaces(5).

# the loopback network interface
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet static
address 192.168.0.140
netmask 255.255.255.0
gateway 192.168.0.1
bond-slaves eth0 eth1
bond-mode active-backup
bond-miimon 100
bond-primary eth0
bond-downdelay 200
bond-updelay 200
post-up route add -net 224.0.0.0 netmask 240.0.0.0 dev bond0

Thank you.

Note : As soon as one interface cable is disconnected another
interface becomes active interfaces - this is visible.

Regards,

[1] https://lists.debian.org/debian-user/2012/01/msg01790.html
[2] bonding output
[3] network configuration under /etc/network/interfaces

[toc] | [next] | [standalone]

#226366 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Jaikumar Sharma wrote: 
> Hi folks,
> 
> I'm using Debian 10 (point release 5) and i've set up the bonding for
> eth0 and eth1 in 'active-backup' mode, i'm using virtualbox VM for
> testing it, if i disconnect cable (virtually from first ethernet -
> eth0) ping to bond0 IP stops and if i disconnect it from eth1 and
> reconnect on eth0 ping again start working. Do not really know what is
> wrong!
> 
> Problem in [1] (searched mail archives) is same but no solution is
> given there or user did not respond further on it, he/she might have
> found the solution already, though there are some tests which i've
> performed as mentioned in [1] and without bonding (dual network mode)
> I can ping both IP from remote.

> In this setup i'm using a D-Link 8 port switch to connect eth0 using
> ethernet cable and eth1 is connected on wireless adapter of my laptop.

You don't want a bond, you want a bridge.

Bonding takes two interfaces that talk to the same switch on the
other side, and makes them into one bond nic. You need support
on the switch, too, which is unlikely in a D-Link 8-port unless
it has a management interface -- I think they don't bother under
16 or 24 ports, and even then it's an extra-cost option.

-dsr-

[toc] | [prev] | [next] | [standalone]

#226369 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Dan Ritter wrote:

> You don't want a bond, you want a bridge.
> 
> Bonding takes two interfaces that talk to the same switch on the
> other side, and makes them into one bond nic. You need support
> on the switch, too, which is unlikely in a D-Link 8-port unless
> it has a management interface -- I think they don't bother under
> 16 or 24 ports, and even then it's an extra-cost option.
> 

It is not strictly related to switches, though mostly used in the context.
But it can not prevent you to make a bond between to computers with two
network interfaces.
I am not sure though if this works with a simple VM - we've done this only
on the hardware level/switch.

The switches are indeed expensive new start from 1-2000 and you need two.

If OP would take another PC with two interfaces and configures correctly, it
should work between two of them for test purposes.

 

[toc] | [prev] | [next] | [standalone]

#226402 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On Fri, Aug 21, 2020 at 9:30 PM Dan Ritter <dsr@randomstring.org> wrote:
>
> You don't want a bond, you want a bridge.
>
> Bonding takes two interfaces that talk to the same switch on the
> other side, and makes them into one bond nic. You need support
> on the switch, too, which is unlikely in a D-Link 8-port unless
> it has a management interface -- I think they don't bother under
> 16 or 24 ports, and even then it's an extra-cost option.
Thank you for pointers, this is a test switch at home but of course
we have bigger Cisco switches at office which have management interface.
It look like LACP needs to be checked/enabled on ports which needs to
be used in network bonding.
Thank you.

[toc] | [prev] | [next] | [standalone]

#226405 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Jaikumar Sharma wrote:

> Thank you for pointers, this is a test switch at home but of course
> we have bigger Cisco switches at office which have management interface.
> It look like LACP needs to be checked/enabled on ports which needs to
> be used in network bonding.

Note that LACP is not "active backup" (mode 1) which you have shown in your
configuration. LACP is called Dynamic Link Aggregation (mode 4).
There are 6 types of bonding explained for example here
https://thelinuxcluster.com/2010/01/08/linux-bonding-modes/

All of them configure and behave differently. The peer in case of LACP also
has to be configured accordingly.

I have not done this in debian, but on Red Hat it needed some manual
configuration of the ETHTOOL options for the network devices, so that it
works properly.

[toc] | [prev] | [next] | [standalone]

#226411 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On Fri, Aug 21, 2020 at 9:30 PM Dan Ritter <dsr@randomstring.org> wrote:
> You don't want a bond, you want a bridge.
>
> Bonding takes two interfaces that talk to the same switch on the
> other side, and makes them into one bond nic. You need support
> on the switch, too, which is unlikely in a D-Link 8-port unless
> it has a management interface -- I think they don't bother under
> 16 or 24 ports, and even then it's an extra-cost option.
Just see this webpage on
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/advanced_overcloud_customization/overcloud-network-interface-bonding
it says :

bond_mode=active-backup

This mode offers active/standby failover where the standby NIC resumes
network operations when the active connection fails. Only one MAC
address is presented to the physical switch. This mode does not
require any special switch support or configuration,and works when the
links are connected to separate switches. This mode does not provide
load balancing.

** This mode does not require any special switch support or
configuration -- stated in the above para.
Now, with this is not really clear where the problem is?

thanks.

[toc] | [prev] | [next] | [standalone]

#226412 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Jaikumar Sharma wrote: 
> On Fri, Aug 21, 2020 at 9:30 PM Dan Ritter <dsr@randomstring.org> wrote:
> > You don't want a bond, you want a bridge.
> >
> > Bonding takes two interfaces that talk to the same switch on the
> > other side, and makes them into one bond nic. You need support
> > on the switch, too, which is unlikely in a D-Link 8-port unless
> > it has a management interface -- I think they don't bother under
> > 16 or 24 ports, and even then it's an extra-cost option.
> Just see this webpage on
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/advanced_overcloud_customization/overcloud-network-interface-bonding
> it says :
> 
> bond_mode=active-backup
> 
> This mode offers active/standby failover where the standby NIC resumes
> network operations when the active connection fails. Only one MAC
> address is presented to the physical switch. This mode does not
> require any special switch support or configuration,and works when the
> links are connected to separate switches. This mode does not provide
> load balancing.
> 
> ** This mode does not require any special switch support or
> configuration -- stated in the above para.
> Now, with this is not really clear where the problem is?

You still want bridging, not bonding.

WiFi doesn't have a cable, so it can't tell you when the
connection goes away, and it can't decide by itself to bring up
a connection. You need a management program that will pick a
network from SSID, negotiate any necessary encryption, and do
all that with a MAC address that does not conflict with another
one on the network.

The bond driver itself can't do that. You might be able to get a
higher-order system to take care of it --
/etc/network/interfaces *may* be able to figure out a way,
Network Manager might handle this case -- but I'll bet you a
shiny nickel you will have reliability issues that are much
worse than just connecting it to the wired ethernet and leaving
it alone.

-dsr-

[toc] | [prev] | [next] | [standalone]

#226413 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On 8/22/20, Dan Ritter <dsr@randomstring.org> wrote:
> Jaikumar Sharma wrote:
>> On Fri, Aug 21, 2020 at 9:30 PM Dan Ritter <dsr@randomstring.org> wrote:
>> > You don't want a bond, you want a bridge.
>> >
>> > Bonding takes two interfaces that talk to the same switch on the
>> > other side, and makes them into one bond nic. You need support
>> > on the switch, too, which is unlikely in a D-Link 8-port unless
>> > it has a management interface -- I think they don't bother under
>> > 16 or 24 ports, and even then it's an extra-cost option.
>> Just see this webpage on
>> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/advanced_overcloud_customization/overcloud-network-interface-bonding
>> it says :
>>
>> bond_mode=active-backup
>>
>> This mode offers active/standby failover where the standby NIC resumes
>> network operations when the active connection fails. Only one MAC
>> address is presented to the physical switch. This mode does not
>> require any special switch support or configuration,and works when the
>> links are connected to separate switches. This mode does not provide
>> load balancing.
>>
>> ** This mode does not require any special switch support or
>> configuration -- stated in the above para.
>> Now, with this is not really clear where the problem is?
>
> You still want bridging, not bonding.
>
> WiFi doesn't have a cable, so it can't tell you when the
> connection goes away, and it can't decide by itself to bring up
> a connection. You need a management program that will pick a
> network from SSID, negotiate any necessary encryption, and do
> all that with a MAC address that does not conflict with another
> one on the network.
>
> The bond driver itself can't do that. You might be able to get a
> higher-order system to take care of it --
> /etc/network/interfaces *may* be able to figure out a way,
> Network Manager might handle this case -- but I'll bet you a
> shiny nickel you will have reliability issues that are much
> worse than just connecting it to the wired ethernet and leaving
> it alone.

Or you can just configure the wired ethernet connection to have a
lower (better) routing metric than the wireless connection.  That way
the machine always uses the wired connection if it's up and uses the
wireless connection when the wired connection is down.

There's probably a nice and easy way to do that by changing
/etc/network/something .. I never figured out how to do it that way &
used the 'Advanced Network Configuration' gui tool to set the wired
connection 'Connect automatically with priority' to -999

With the ethernet cable connected to the laptop, 'ip route' shows wls1
with a metric of 600 and enp1s0 with a metric of 100.
With the ethernet cable disconnected the only thing that 'ip route'
shows is wls1.
Yay! automatic failover + automatic selection of the faster interface
when it's up :-)

Lee

[toc] | [prev] | [next] | [standalone]

#226414 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Lee wrote: 
> 
> Or you can just configure the wired ethernet connection to have a
> lower (better) routing metric than the wireless connection.  That way
> the machine always uses the wired connection if it's up and uses the
> wireless connection when the wired connection is down.
> 
> There's probably a nice and easy way to do that by changing
> /etc/network/something .. I never figured out how to do it that way &
> used the 'Advanced Network Configuration' gui tool to set the wired
> connection 'Connect automatically with priority' to -999
> 
> With the ethernet cable connected to the laptop, 'ip route' shows wls1
> with a metric of 600 and enp1s0 with a metric of 100.
> With the ethernet cable disconnected the only thing that 'ip route'
> shows is wls1.
> Yay! automatic failover + automatic selection of the faster interface
> when it's up :-)

This will generally work, but it does have a drawback: you have
two different IPs, so when a change happens, all your existing
connections will drop and new inbound connections will only work
on the NIC that's up.

You'll also need to replicate firewall rules on each NIC.


-dsr-

[toc] | [prev] | [next] | [standalone]

#226417 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On 8/22/20, Dan Ritter <dsr@randomstring.org> wrote:
> Lee wrote:
>>
>> Or you can just configure the wired ethernet connection to have a
>> lower (better) routing metric than the wireless connection.  That way
>> the machine always uses the wired connection if it's up and uses the
>> wireless connection when the wired connection is down.
>>
>> There's probably a nice and easy way to do that by changing
>> /etc/network/something .. I never figured out how to do it that way &
>> used the 'Advanced Network Configuration' gui tool to set the wired
>> connection 'Connect automatically with priority' to -999
>>
>> With the ethernet cable connected to the laptop, 'ip route' shows wls1
>> with a metric of 600 and enp1s0 with a metric of 100.
>> With the ethernet cable disconnected the only thing that 'ip route'
>> shows is wls1.
>> Yay! automatic failover + automatic selection of the faster interface
>> when it's up :-)
>
> This will generally work, but it does have a drawback: you have
> two different IPs, so when a change happens, all your existing
> connections will drop and new inbound connections will only work
> on the NIC that's up.

True.  But it's better than manually switching things around.

hrmm... I just went back to the original post; I missed this bit the
first time around:
> In this setup i'm using a D-Link 8 port switch to connect eth0 using
> ethernet cable and eth1 is connected on wireless adapter of my laptop.

eth0 and eth1 are probably on two different networks (same as my wls1
& enp1s0 are on two different networks); that'd be my guess for why
failover doesn't work.  Both NICs need to be on the same network for
bonding to work.

Lee

[toc] | [prev] | [next] | [standalone]

#226419 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

> hrmm... I just went back to the original post; I missed this bit the
> first time around:
> > In this setup i'm using a D-Link 8 port switch to connect eth0 using
> > ethernet cable and eth1 is connected on wireless adapter of my laptop.
>
> eth0 and eth1 are probably on two different networks (same as my wls1
> & enp1s0 are on two different networks); that'd be my guess for why
> failover doesn't work.  Both NICs need to be on the same network for
> bonding to work.
Thanks for explanation on it further, in fact, as i stated earlier,
this is test scenario which i was talking about on a VM having
wireless and wired LAN connection in bonded mode with D-Link 8 port
switch.
Actual hardware and test scenario are different - managed Cisco switch
and two ethernet connections for bonding - which i've to test further
and get a result on this same.
Both interfaces are on the same network.
Thanks.

** Sent again, as i missed to add debian user list in these two mails
, sorry. thanks.

On Sat, Aug 22, 2020 at 8:16 PM Jaikumar Sharma
<jaikumar.sharma@gmail.com> wrote:
>
> > hrmm... I just went back to the original post; I missed this bit the
> > first time around:
> > > In this setup i'm using a D-Link 8 port switch to connect eth0 using
> > > ethernet cable and eth1 is connected on wireless adapter of my laptop.
> >
> > eth0 and eth1 are probably on two different networks (same as my wls1
> > & enp1s0 are on two different networks); that'd be my guess for why
> > failover doesn't work.  Both NICs need to be on the same network for
> > bonding to work.
> Thanks for explanation on it further, in fact, as i stated earlier,
> this is test scenario which i was talking about on a VM having
> wireless and wired LAN connection in bonded mode with D-Link 8 port
> switch.
> Actual hardware and test scenario are different - managed Cisco switch
> and two ethernet connections for bonding - which i've to test further
> and get a result on this same.
> Both interfaces are on the same network.
> Thanks.

[toc] | [prev] | [next] | [standalone]

#226418 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On Sat, Aug 22, 2020 at 5:10 PM Dan Ritter <dsr@randomstring.org> wrote:
> You still want bridging, not bonding.
Preferred is bonding, if it works :)
> WiFi doesn't have a cable, so it can't tell you when the
> connection goes away, and it can't decide by itself to bring up
> a connection. You need a management program that will pick a
> network from SSID, negotiate any necessary encryption, and do
> all that with a MAC address that does not conflict with another
> one on the network.

 Have to test it with two wired connections connected to Cisco managed switch.

> The bond driver itself can't do that. You might be able to get a
> higher-order system to take care of it --
> /etc/network/interfaces *may* be able to figure out a way,
> Network Manager might handle this case -- but I'll bet you a
> shiny nickel you will have reliability issues that are much
> worse than just connecting it to the wired ethernet and leaving
> it alone.
Sure, will look into more detail into /etc/network/interfaces/

** earlier mail missed adding debian user list. sorry.

Thanks.

On Sat, Aug 22, 2020 at 8:20 PM Jaikumar Sharma
<jaikumar.sharma@gmail.com> wrote:
>
> On Sat, Aug 22, 2020 at 5:10 PM Dan Ritter <dsr@randomstring.org> wrote:
> > You still want bridging, not bonding.
> Preferred is bonding, if it works :)
> > WiFi doesn't have a cable, so it can't tell you when the
> > connection goes away, and it can't decide by itself to bring up
> > a connection. You need a management program that will pick a
> > network from SSID, negotiate any necessary encryption, and do
> > all that with a MAC address that does not conflict with another
> > one on the network.
>
>  Have to test it with two wired connections connected to Cisco managed switch.
>
> > The bond driver itself can't do that. You might be able to get a
> > higher-order system to take care of it --
> > /etc/network/interfaces *may* be able to figure out a way,
> > Network Manager might handle this case -- but I'll bet you a
> > shiny nickel you will have reliability issues that are much
> > worse than just connecting it to the wired ethernet and leaving
> > it alone.
> Sure, will look into more detail into /etc/network/interfaces/
>
> Thanks.

[toc] | [prev] | [next] | [standalone]

#226420 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Jaikumar Sharma wrote: 
> On Sat, Aug 22, 2020 at 5:10 PM Dan Ritter <dsr@randomstring.org> wrote:
> > You still want bridging, not bonding.
> Preferred is bonding, if it works :)

>  Have to test it with two wired connections connected to Cisco managed switch.

This really sounds like you're trying to test out a scenario in
a situation where it can't possibly work.

Don't do that. Test it in as close a simulation to reality as
possible.

-dsr-

[toc] | [prev] | [next] | [standalone]

#226449 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Dan Ritter wrote:

>> Have to test it with two wired connections connected to Cisco managed
>> switch.
> 
> This really sounds like you're trying to test out a scenario in
> a situation where it can't possibly work.
> 

But this is exactly what he has to do - connect two wired network interfaces
to a managed switch. Then configure LAGG (LACP) on the switch for the two
ports and LAGG (LACP) on the PC/server.

[toc] | [prev] | [next] | [standalone]

#226467 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On Mon, Aug 24, 2020 at 12:47 AM deloptes <deloptes@gmail.com> wrote:
> But this is exactly what he has to do - connect two wired network interfaces
> to a managed switch. Then configure LAGG (LACP) on the switch for the two
> ports and LAGG (LACP) on the PC/server.
Right :)
For my tests on Cisco switch  at office (without any changes on
switch) and using bonding in  "active-backup" mode, I can ping the
active interface using bond0 IP after plugging out the network cable
of the cable of active interface.
Only catch was all interfaces must be on same VLAN - problem was found
that one of the interface was in different VLAN and that is why ping
was failing - I asked my IT guy to put all interfaces in same VLAN and
everything worked like charm

Thank you all  for different pointers & insights were given in the discussions.

Regards,

[toc] | [prev] | [next] | [standalone]

#226477 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Jaikumar Sharma wrote:

> For my tests on Cisco switch  at office (without any changes on
> switch) and using bonding in  "active-backup" mode, I can ping the
> active interface using bond0 IP after plugging out the network cable
> of the cable of active interface.
> Only catch was all interfaces must be on same VLAN - problem was found
> that one of the interface was in different VLAN and that is why ping
> was failing - I asked my IT guy to put all interfaces in same VLAN and
> everything worked like charm

active-backup does not require specific configuration on the switch but of
course you have to have the same VLAN on all ports same as in the bond on
the server. But again it is not LACP (mode4). LACP requires configuration
on both ends (LAG) and has the advantage that it negotiates the active
interface. In the case only one link is active. If it fails the other takes
over and both devices are notified.

[toc] | [prev] | [next] | [standalone]

#226471 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

Hello,

On Sun, Aug 23, 2020 at 09:16:48PM +0200, deloptes wrote:
> Dan Ritter wrote:
> > This really sounds like you're trying to test out a scenario in
> > a situation where it can't possibly work.
> > 
> 
> But this is exactly what he has to do - connect two wired network interfaces
> to a managed switch. Then configure LAGG (LACP) on the switch for the two
> ports and LAGG (LACP) on the PC/server.

Have I misunderstood how the OP is trying to replicate it though? My
Understanding was they are taking a bare metal machine with one
Ethernet and one WiFi, then exporting those to a virtual machine as
two virtual Ethernets. Then they are trying to use the bonding
driver on those virtual Ethernets.

I use bonding on bare metal servers a lot and it "just works". I
don't know what is wrong in OP's case but if they really are trying
to do it the way I understand then I suspect those who say the WiFi
is the problem are correct.

Cheers,
Andy

[toc] | [prev] | [next] | [standalone]

#226469 — Re: In network bonding second nic (eth1) is not pingable while first one (eth0) is always pingable"

On Sat, Aug 22, 2020 at 9:36 PM Dan Ritter <dsr@randomstring.org> wrote:
> This really sounds like you're trying to test out a scenario in
> a situation where it can't possibly work.
>
> Don't do that. Test it in as close a simulation to reality as
> possible.
Thanks Dan for insights, it worked - I humbly appreciate you for insights given.

Regards,

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web