What you have:
bond (bond0) interface (all modes except 4) with at least 2 ifaces (say eth0 / eth1) connected on the same external switch
bond0 interface joined on a software bridge (br0)
virtual machine (vm0) (eg LibVirt::LXC) with an interface on br0
What you get:
vm0 is not able to connect to (most) IP addresses via bond0 over br0
"bond0: received packet with own address as source address" in syslog
Why you get this:
When vm0 wants to contact an external IP address it will send out an ARP request. This L2 broadcast with the source mac of vm0 will leave through (depending on bonding mode) eg eth0, but via the external switch, re-enter through eth1 and thus bond0. Hence the switch br0 will learn the mac-address of vm0 on the port connected to bond0. As a consequence the ARP-reply is never received by vm0.
What can you do to resolve:
The reason I post this, next to sharing the info, is that I wasn't able to figure out a good enough solution. Those I did find are:
On vm0 set static ARP entry
Use bond0 mode=4 but your external switch must support this
Configure your external siwtch to use private VLAN on eth0/eth1 but only works in some use-cases and adds complexity
Add both physical interfaces to the bridge with spanning tree enabled, instead of using bond driver
Statically configuring the MAC of vm0 on the correct port of br0 is not an option on Linux (works on OpenBSD though)
I'm really hoping for a more elegant solution here... Anyone?
Thanks
I've got the same problem and I come up with the same analysis.
The only non-invasive/scalable solution I've found is to use the active/backup bonding (mode 1). The tradeoff is that you lose the aggregation.
IMO, the best solution is to use 802.3ad, but I can't always use it because I'm limited with 6 port-channels on most of my switches.
Try these options in bridge:
brigde_fd 0
bridge_stp off # switch on with more system like this
bridge_maxage 0
bridge_ageing 0
bridge_maxwait 0
Taken from this thread:
kvm bridge also in proxmox
Related
I have an interface eth0, from which I want to mirror all incoming traffic to, say, eth1, so I use the following commands:
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: prio 1 u32 match u32 0 0 action mirred ingress mirror dev eth1
It works perfectly with everything except VLAN-tagged packets - they can be seen in Wireshark on eth0, but they do not appear on eth1. If I do:
vconfig add eth0 $TAG
Where $TAG is some tag from my input traffic, the corresponding packets start to appear on eth1.
But, as I have written, I want to capture all incoming traffic, and that means I want to capture all VLAN tags as well. I'm pretty sure it will work if I add all tags from 2 up to 4094, creating all those sub-interfaces, but I wonder if there is some smarter way to do so? Also, I'm concerned about performance issues, which may appear when having so much interfaces. Thanks!
After researching more I have discovered that the utility bridge, which is part of iproute2 collection, can be used to solve this issue. I have no idea why the following approach works, but you can try to do the same if you have a similar problem.
So, suppose we already have the setup I described earlier (without vconfig-adding the VLAN tags), then do:
ip link add bridge_dev type bridge
ip link set bridge_dev up
ip link set eth0 master bridge_dev
These commands create a bridge device, turn it on and set eth0 device as a slave of the bridge_dev. Right after the last command I start seeing the VLAN-tagged packets on eth1, as expected.
Note that you can also add VLAN tags to bridge devices, like:
bridge vlan add vid 2-4094 dev bridge_dev self
I expected to only see VLAN packets after that command, but apparently it's not necessary. I would welcome anyone who could explain, why this works.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
I would like to configure a wlan0 static ip and connect through it by ssh.
Here my /etc/network/interfaces :
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
adress 192.168.0.2
netmask 255.255.255.0
auto wlan0
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.100.102
netmask 255.255.255.0
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
When I do ifconfig my wlan0 and eth0 interfaces are correctly configured :
However, when I want to ssh my raspberry by wifi, my Wifi router give to my raspberry the ip : 192.168.100.116.
How can I force my Wifi router to give 192.168.100.102 to my rapsberry pi ?
Moreover, My Wifi router give to my raspberry sometimes 192.168.100.102 and sometimes 192.168.100.116
Don't know why
I experienced similar issues when I wanted to connect my Rasperry Pi 2 with Raspbian Jessie Lite in a headless configuration for access using SSH from my Windows 10 PC with PuTTY.
In my case it turned out that the Ahavi daemon (an implementation of zeroconf) conflicted with the DHCP and name server options of my router.
Raspbian Jessie and Raspbian Jessie Lite comes pre-configured with an Avahi and a DHCP client deamon for automated network configuration. In most situation this will probably work fine, but if not, things take a turn for the worse with unpredictable side-effects.
Instead of going too deep into any details (its really a long story) I will just summarize here what I did and why. There are too many possible issues and I dont want to push you into the wrong direction. Try it out. If it fails, look for another approach or leave a comment for clarification.
Now let's get your feet wet:
Try it first on a non-productive SD card with a fresh copy of Raspbian Jessie (for headless servers I prefer Raspbian Jessie Lite).
Start the Raspberry Pi with a keyboard and a monitor connected and login with user pi.
Start raspi-config with sudo raspi-config and make sure to turn on the SSH server (menue 7 Advanced Options -> A4 SSH).
Get your current IP address for eth0 with ifconfig.
Try to connect to this address over ethernet using ssh. In case you cant connect, resolve this issue first. You cant connect over WLAN at this stage.
In case your connection succeeds, you can do the rest of your configuration using this connection over ssh.
Purge the avahi-daemon
$ sudo apt-get purge avahi-daemon
Dont worry about the error message 'rmdir: failed to remove ‘/var/run/avahi-daemon’: Directory not empty'. This is related to a an empty socket and a pid file, that currently cannot be removed. You can ignore this message or remove the directory manually, but it wont hurt in case you just leave it.
$ sudo rm -r /var/run/avahi-daemon
Configure /etc/network/interfaces
It's important to know, that we need only one single change in this file. Open /etc/network/interfaces for changes with the editor of your choice (note: if you followed this steps 1:1 extended vim is not yet installed).
$ sudo nano /etc/network/interfaces
Add the line auto eth0 just before the existing line iface eth0 inet manual. That's all we have to do here is to here. After the changes the file should look like this:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Note: make sure to read and to understand the comments on top of the file!
Configure the DHCP client daemon
Next, as stated in the comments of the previously edited file, add the static ip configuration at the end of the configuration file for the DHCP client daemon.
It might sound silly to use a DHCP client if we are going to use static IP addresses anyway. However, when I tried to remove the DHCP client daemon I experienced new configuration and/or dependency issues. Finally I decided to keep as close to the standard configuration as possible and leave it as is.
The configuration is done at the very end in the file /etc/dhcpcd.conf (watch proper spelling). The last line in the file should read: 'nohook lookup-hostname'. So let's open the the file in the editor and scroll down to the bottom of the file.
$ sudo nano /etc/dhcpcd.conf
Add there the static ip definition. In my case the definitions at the of /etc/dhcpcd.conf look like this:
nohook lookup-hostname
# static ip configuration for eth0 and wlan0
interface eth0
static ip_address=192.168.1.61/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1 8.8.8.8
interface wlan0
static ip_address=192.168.1.62/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1 8.8.8.8
Note that the syntax is different from the syntax used in /etc/network/interfaces. For a full class C network the netmask must be provided in form of a /24 at the end of the IP address. For further details consult man dhcpcd.conf.
Reboot and test your configuration with eth0
After the next reboot you should have a reliable network configuration with static ip addresses. But remember, we are not yet finished and only eth0 will work. At this point even no IPv4 address will be shown for wlan0 if ifconfig is issued
In case it fails and you didn't do anything wrong so far (carefully check for typos), then you have another issue that must get fixed first; in this case this solution is probably not for you.
Configure WLAN
To configure WLAN we have to edit /etc/wpa_supplicant/wpa_supplicant.conf and add a network configuration to it.
In my case I'm using WPA/PSK for secure access and after modifying the country code and adding the network entry, the content of the file looks something like this:
country=CH
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
# home network; allow all valid ciphers
network={
ssid="home"
scan_ssid=1
key_mgmt=WPA-PSK
psk="very secret passphrase"
}
ssid="home" is the WLAN network name (SSID) of the WLAN router or access point.
scan_ssid=1 scans for hidden SSID's. This is usual practice but can slowdown the scan process.
key_mgmt=WPA-PSK defines that WPA pre-shared key management protocol will be used.
psk="very secret passphrase" defines your passphrase to access the router.
Replace the values assigned for ssid and psk with the real values for your secure WLAN access. There are several supported protocols, some requiring other and more options.
Consult man wpa_supplicant.conf for additional and more detailled information.
Reboot and test your configuration with wlan0
Now it's time to reboot and test wlan0. The ip address configured for wlan0 should now appear if ifconfig is issued.
If this is the case you should be able to access the Rasperry Pi using ssh with the IP address configured for wlan0.
I hope you are happy and everything works fine for you so far. If this is the case, I could stop writing here and leave you alone. But wait, there is more!
Two network connections, does that make sense?
If you connect to the Raspberry Pi from the same network over both, eth0 and wlan0 and issue an ifconfig to take a look at the transmitted and received packets or bytes, you will recognize, that even you connected to the IP for wlan0 most traffic is going through eth0.
I cant explain why this is the case, but obviously somehow the packets are routed along the faster path which sounds good so far.
However, I've seen rare situations where this behaviour was undesirable and slowed my connections down. Since I'm using my Raspberry Pi either near my router using a wired connection to eth0 or more distant from the router with no access to a cable using wlan0, I decided to stop wlan0 if a cable with an active connection to the router is attached to eth0.
To do this I created the script /home/pi/ifdown-wlan-if-not-needed.sh
#!/bin/sh
#### Shutdown wlan0
# Test eth0 for a cable attached and
# shutdown wlan0 if this is the case.
###
sleep 30
cable=$(cat /sys/class/net/eth0/carrier)
echo $cable
if [ "$cable" = "1" ]; then
sudo ifdown wlan0
fi
exit 0
Then I've set the script to executable
$ chmod +x /home/pi/ifdown-wlan-if-not-needed.sh
And added it for execution after reboot with crontab -e to the crontab of user pi.
#reboot /home/pi/ifdown-wlan-if-not-needed.sh
Name to IP address resolution
So far I have not yet addressed the name to IP address resolution problem. How this can be done best, depends on your network equipment and use case.
My router provides the ability to bind names to MAC addresses, hostnames and IPv4 adresses. However, for some reason none of these options really work. Some times it works by simply using the given name, other times the suffix .home is needed. Sometimes the names disappear from the list or no name resolution takes place even everything looks ok.
I finally defined the adresses in the C:\Windows\System32\drivers\etc\hosts file of my Windows PC and my Notebook. This is certainly not state of the art but works reliable and without hassle.
However, I cant guarantee that what I did works for you too, but I hope it brings you on the right track to get your problem solved. I've been using my configuration since the release of Raspbian Jessie about one year ago. It survived any updates without hassle so far.
Good luck!
Login on your router management interface and (if it has this feature, most do have it) reserve a DHCP address on the router for your selected client, so that the specific client always has the same IP address. See this article for more information.
I want send out data from one NIC and received by another NIC on a CENTOS6.4( X86 frame ,3 NIC, one is onboard realtek's, the other two is intel NICs ).
First,I configured intel nic ip: (eth0) 192.168.1.1/24 and (eth1) 192.168.1.2/24 on two intel NICs.
Second, I add route by following cmds:
# route add -host 192.168.1.1 dev eth1
# route add -host 192.168.1.2 dev eth0
Third, I enabled accept_local in /etc/sysctl.conf:
net.ipv4.conf.eth0.accept_local = 1
net.ipv4.conf.eth1.accept_local = 1
And I also disabled iptables and SElinux. I reboot the system, then use a wire connect eth0 and eth1, then I test like this:
#ping 192.168.1.1 -I eth1
Message returned:
"From 192.168.1.2 icmp_seq=xx Destination Host Unreachable"
Has I missed something?
I have read this topic How can configure linux routing to send packets out one interface, over a bridge and into another interface on the same box already.
try set sysctl -w net.ipv4.conf.all.rp_filter=2
Refer https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
accept_local - BOOLEAN
Accept packets with local source addresses. In combination
with suitable routing, this can be used to direct packets
between two local interfaces over the wire and have them
accepted properly.
rp_filter must be set to a non-zero value in order for
accept_local to have an effect.
rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
in startup scripts.
I have two machines each with two valid network interfaces, an Ethernet interface eth0 and a tun/tap interface gr0. The goal is to start a TCP connection on machine A using interface gr0 but then have the responses (ACKs, etc) from machine B come back over the Ethernet interface, eth0. So, machine A sends out a SYN on gr0 and machine B receives the SYN on its own gr0 but then sends its SYN/ACK back through eth0. The tun/tap device is a GNU Radio wireless link and we just want the responses to come through the Ethernet.
What's the easiest way to accomplish this? I need to research more on TCP/IP, but I was initially thinking that source-spoofing outgoing packets would tell the receiver to respond to the spoofed address (which should get routed to eth0). This would involve routing the IPs from the tun/tap interfaces through gr0 and leave the other traffic to eth0.
We are using Linux and a Python solution would be preferable.
Thanks for looking!
You could add an additional address to the lo interface on each system and use these new addresses as the TCP connection endpoints. You can then use static routes to direct which path each machine takes to get to the other machine's lo address.
For example:
Machine A:
ip addr add 1.1.1.1/32 dev lo
ip route add 2.2.2.2/32 dev eth0 via <eth0 default gateway>
Machine B:
ip addr add 2.2.2.2/32 dev lo
ip route add 1.1.1.1/32 dev gr0
Then bind to 1.1.1.1 on machine A and connect to 2.2.2.2.
You may be interested in enabling logging of martian packets net.ipv4.conf.all.log_martians, and disable reverse path filtering net.ipv4.conf.<interface>.rp_filter on the affected interfaces.
This sysctl vars are accesible via the sysctl utility and/or the /proc filesystem.
Greetings,
For various reasons, my connection to the internet looks like this:
[DSL Modem in Bridge Mode] <-ethernet-> (eth0)[Linux system](eth1) <-ethernet-> [Wireless Router]
(Where the Linux system is running PPPoE, BIND, DHCP, etc.)
In order to diagnose a recent problem, I needed to connect to the web interface on the DSL modem. In order to do this I have to connect from a specific address range and as I am running PPPoE on eth0, I haven't assigned an address to it nor even turn it on. (The modem's web interface is at a fixed IP address regardless of what mode the modem is in and only answers to traffic from a fixed address range)
So anyway, to connect to the modem, and not finding anything helpful on the internet, I just tried assigning an IP address to eth0 after already starting PPPoE (like this: ifconfig eth0 192.168.1.5 netmask 255.255.255.0 up). I didn't really think that it would actually work. But it did. I.e. PPPoE and a static address assigned to eth0 at the same time and both worked correctly. Thus my question.. Should it? Is it safe to do this long-term or am I just lucky that it works long enough for me to get that which I need to done?
Thanks!
It's fine. PPPoE and IP are carried in Ethernet frames of different types.