Try configure SRX FW , try set static arp
[edit interfaces ge-0/0/3 unit 0 family inet address 10.1.1.1/24]
user#host# set arp 10.1.1.3 mac 01:ff:85:7f:78:03
return :
Invalid unicast address at '01:ff:85:7f:78:03'
Why is this invalid?
Solved , happened IP is a Cluster IP which is Multicast mac
as simply say "mac" JunOS assumed unicast which is invalid
So say "multicast mac" and should be OK
Fun
Regards
Brian
Related
is it possible to reply all incoming packets/request on same network interface?
This is my setting: I have a headless Raspberry Pi (raspbian) with two network interfaces (eth0 and eth1). The fist interface (eth0) uses a public IP address, which is static. This interface is intended to provide access to the Pi (time- and web server, SSH) via the Internet. The second interface (eth1) uses the Raspberry Pi for general Internet connection (perform updates, sync own time or whatever) and uses a dynamic IP via DHCP. A general Internet connectivity over eth0 is not possible, so I have to use eth1 on the Pi.
My problem is that Internet (on the Pi) and the Internet access to the Pi are not working correctly.
first configuration (/etc/dhcpcd.conf):
interface eth0
static ip_address=141.41.241.68/28
static routers=141.41.241.65 192.168.0.1
after reboot 'ifconfig' shows the correct IP settings:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 141.41.241.68 netmask 255.255.255.240 broadcast 141.41.241.79
...
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
...
result:
Internet on the Raspberry Pi (eth1): doesn't work
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): works fine
Apache web server (TCP): works fine
NTP time server (UDP): works fine
Now I tried to change the metric of the interfaces, hoping that the change of prioritization is successful
second configuration (/etc/dhcpcd.conf):
interface eth1
metric 200
interface eth0
static ip_address=141.41.241.68/28
static routers=141.41.241.65 192.168.0.1
metric 201
result:
Internet on the Raspberry Pi (eth1): works fine
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): doesn't work
Apache web server (TCP): doesn't work
NTP time server (UDP): doesn't work
Ok. I think all traffic going out to eth1 at default. With the tool 'iptraf-ng' I was able to see the problem:
TCP Connections (Source Host:Port) Iface
--------------------------------------------------
80.187.108.126:53024 eth0
141.41.241.68:80 eth0
141.41.241.68:80 eth1
80.187.108.126:53024 eth1
80.187.108.126:53025 eth0
141.41.241.68:80 eth0
141.41.241.68:80 eth1
80.187.108.126:53025 eth1
UDP Connections
--------------------------------------------------
UDP (76 bytes) from 80.187.108.126:28599 to 141.41.241.68:123 on eth0
UDP (76 bytes) from 192.168.0.101:123 to 80.187.108.126:28599 on eth1
We see:
On TCP: some connections going out to the wrong interface (eth1).
On UDP: The request from 80.187.108.126 came over eth0 and the response was sent over eth1.
Next, I defined the routing table to reply incoming packets on same network interface...
echo 100 public >> /etc/iproute2/rt_tables
ip rule add from 141.41.241.68/32 table public
ip route add default via 141.41.241.65 dev eth0 table public
result:
Internet on the Raspberry Pi (eth1): works fine
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): works fine
Apache web server (TCP): works fine
NTP time server (UDP): doesn't work
and 'iptraf-ng' shows:
TCP Connections (Source Host:Port) Iface
--------------------------------------------------
141.41.241.68:80 eth0
80.187.108.126:52083 eth0
141.41.241.68:80 eth0
80.187.108.126:52084 eth0
141.41.241.68:80 eth0
80.187.108.126:52085 eth0
141.41.241.68:80 eth0
80.187.108.126:52086 eth0
141.41.241.68:80 eth0
80.187.108.126:52087 eth0
UDP Connections
--------------------------------------------------
UDP (76 bytes) from 80.187.108.126:28599 to 141.41.241.68:123 on eth0
UDP (76 bytes) from 192.168.0.101:123 to 80.187.108.126:28599 on eth1
We see:
On TCP: now it works correctly
On UDP: same problem :(
What can I do to send UDP responses over the correct interface (eth0)? I have no idea why TCP works fine but UDP fails :(
Its very frustrating and I have no more ideas.
I hope someone can help.
best regards,
SBond
Thanks for the read.
I'd like to preface this with the fact that I am weak on dev-ops! :)
First off, my environment:
3 node cluster each of which are CentOS 7 VMs running in VirtualBox 5.1.3. I have an additional network adaptor enabled running an internal network visible only to the VMs.
I have configured the VMs to use the additional adaptor and am able to ping all nodes via it's network.
etcd config:
{ "Network": "172.30.0.0/24", "Backend": { "Type": "vxlan" } }
nmcli output:
enp0s3: connected to enp0s3
"Intel 82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)"
ethernet (e1000), 08:00:27:DD:CB:CA, hw, mtu 1500
ip4 default
inet4 10.0.2.15/24
inet6 fe80::49e4:5aa5:65c8:6e48/64
enp0s8: connected to enp0s8
"Intel 82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)"
ethernet (e1000), 08:00:27:40:11:AE, hw, mtu 1500
inet4 192.168.0.10/24
inet6 fe80::90cc:f3b4:7e73:cf3f/64
I am working through the installation/configuration instructions in the following documentation.
I wanted to run through this full installation to grasp the overall topology if the product.
Installation seems to be fine and I am able to deploy pods to the cluster. The issue is that flanneld does not seem to be working. I have it explicitly bound to the internal network adapter in the config (enp0s8), however it's showing:
flannel.1: disconnected
"flannel.1"
vxlan, 0A:91:01:BC:7D:7D, sw, mtu 1450
Any insight on this issue would be appreciated. I have done due diligence before reaching out to the community!
Thanks in advance.
Braden
I am trying to launch scapy using Mininet and get this error:
IOError : [Errno 99] Cannot assign requested address
Error happens in
linux.py,line 151, in read_routes
ifreq = ioctl(s, SIOCGIFADDR,struct.pack("16s16x",LOOPBACK_NAME))
Any solutions or ideas?
note: host was added into existed network,may be this cause some misconfiguration
No loopback interface was added. Solution (from terminal):
ifconfig lo up
ifconfig lo 127.0.0.1
For a long time I had troubles using several software (early versions of Teamspeak 3, netcat, openvpn) communicating using UDP protocol. Today I identified the problem.
The main goal for me was to use openvpn over udp which did not seem to work on my server which has multiple ip addresses (runs Ubuntu Server Kernel 3.2.0-35-generic).
Using following config:
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 11:11:11:11:11:11
inet addr:1.1.1.240 Bcast:1.1.1.255 Mask:255.255.255.224
...
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 1.1.1.240
broadcast 1.1.1.255
netmask 255.255.255.224
gateway 1.1.1.225
up ip addr add 1.1.1.249/27 dev eth0
down ip addr del 1.1.1.249/27 dev eth0
up ip addr add 2.2.2.59/29 dev eth0
down ip addr del 2.2.2.59/29 dev eth0
up route add -net 2.2.2.56 netmask 255.255.255.248 gw 2.2.2.57 eth0
# default route to access subnet
up route add -net 1.1.1.224 netmask 255.255.255.224 gw 1.1.1.225 eth0
Problem:
A simple tcpdump at the server reveals that udp packets (tested with netcat and openvpn) received at 2.2.2.59 are replied from 1.1.1.240 (client: 123.11.22.33)
13:55:30.253472 IP 123.11.22.33.54489 > 2.2.2.59.1223: UDP, length 5
13:55:36.826658 IP 1.1.1.240.1223 > 123.11.22.33.54489: UDP, length 5
Question:
Is this problem due to wrong configuration of the network interface or the application itself (OpenVPN, netcat)?
Is it possible for the/an application to listen on multiple ip addresses and reply from the interface address where it received the packet on UDP like it's doing when using TCP.
I know that you can bind applications for specific ip but that would not be the way to go.
I cannot see that this behaviour is due to the UDP protocol itself, since the application is possible to determine at which interface address the packet was received.
Specifically, openvpn has the --multihome option for handling this scenario correctly.
My Dear All the Greatest Lords,
Some expert listed the details of connecting to a wireless network as,
This is a step-to-step guide for connecting to a WPA/WPA2 WiFi network via the Linux command line interface. The tools are:
wpa_supplicant
iw
ip
ping
iw is the basic tool for WiFi network-related tasks, such as finding the WiFi device name, and scanning access points. wpa_supplicant is the wireless tool for connecting to a WPA/WPA2 network. ip is used for enabling/disabling devices, and finding out general network interface information.
The steps for connecting to a WPA/WPA2 network are:
Find out the wireless device name.
$ /sbin/iw dev
phy#0
Interface wlan0
ifindex 3
type managed
The above output showed that the system has 1 physical WiFi card, designated as phy#0. The device name is wlan0. The type specifies the operation mode of the wireless device. managed means the device is a WiFi station or client that connects to an access point.
Check that the wireless device is up.
$ ip link show wlan0
3: wlan0: (BROADCAST,MULTICAST) mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
Look for the word "UP" inside the brackets in the first line of the output.
In the above example, wlan0 is not UP. Execute the following command to bring it up:
$ sudo ip link set wlan0 up
[sudo] password for peter:
Note: you need root privilege for the above operation.
If you run the show link command again, you can tell that wlan0 is now UP.
$ ip link show wlan0
3: wlan0: (NO-CARRIER,BROADCAST,MULTICAST,UP) mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
Check the connection status.
$ /sbin/iw wlan0 link
Not connected.
The above output shows that you are not connected to any network.
Scan to find out what WiFi network(s) are detected
$ sudo /sbin/iw wlan0 scan
BSS 00:14:d1:9c:1f:c8 (on wlan0)
... sniped ...
freq: 2412
SSID: stanford
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: (0x0000)
... sniped ...
The 2 important pieces of information from the above are the SSID and the security protocol (WPA/WPA2 vs WEP). The SSID from the above example is stanford. The security protocol is RSN, also commonly referred to as WPA2. The security protocol is important because it determines what tool you use to connect to the network.
Connect to WPA/WPA2 WiFi network.
This is a 2 step process. First, you generate a configuration file for wpa_supplicant that contains the pre-shared key ("passphrase") for the WiFi network.
$ sudo -s
[sudo] password for peter:
$ wpa_passphrase stanford >> /etc/wpa_supplicant.conf
...type in the passphrase and hit enter...
wpa_passphrase takes the SSID as the single argument. You must type in the passphrase for the WiFi network stanford after you run the command. Using that information, wpa_passphrase will output the necessary configuration statements to the standard output. Those statements are appended to the wpa_supplicant configuration file located at /etc/wpa_supplicant.conf.
Note: you need root privilege to write to /etc/wpa_supplicant.conf.
$ cat /etc/wpa_supplicant.conf
# reading passphrase from stdin
network={
ssid="stanford"
#psk="testtest"
psk=4dfe1c985520d26a13e932bf0acb1d4580461dd854ed79ad1a88ec221a802061
}
The second step is to run wpa_supplicant with the new configuration file.
$ sudo wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
-B means run wpa_supplicant in the background.
-D specifies the wireless driver. wext is the generic driver.
-c specifies the path for the configuration file.
Use the iw command to verify that you are indeed connected to the SSID.
$ /sbin/iw wlan0 link
Connected to 00:14:d1:9c:1f:c8 (on wlan0)
SSID: stanford
freq: 2412
RX: 63825 bytes (471 packets)
TX: 1344 bytes (12 packets)
signal: -27 dBm
tx bitrate: 6.5 MBit/s MCS 0
bss flags: short-slot-time
dtim period: 0
beacon int: 100
Obtain IP address by DHCP
$ sudo dhclient wlan0
Use the ip command to verify the IP address assigned by DHCP. The IP address is 192.168.1.113 from below.
$ ip addr show wlan0
3: wlan0: mtu 1500 qdisc mq state UP qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.113/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::76e5:43ff:fea1:ce65/64 scope link
valid_lft forever preferred_lft forever
Add default routing rule.
The last configuration step is to make sure that you have the proper routing rules.
$ ip route show
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.113
The above routing table contains only 1 rule which redirects all traffic destined for the local subnet (192.168.1.x) to the wlan0 interface. You may want to add a default routing rule to pass all other traffic through wlan0 as well.
$ sudo ip route add default via 192.168.1.254 dev wlan0
$ ip route show
default via 192.168.1.254 dev wlan0
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.113
ping external ip address to test connectivity
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=135 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=135 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=48 time=134 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 134.575/134.972/135.241/0.414 ms
The above series of steps is a very verbose explanation of how to connect a WPA/WPA2 WiFi network. Some steps can be skipped as you connect to the same access point for a second time. For instance, you already know the WiFi device name, and the configuration file is already set up for the network. The process needs to be tailored according to your situation.
Thoroughly followed the above tutorial, I failed to connect the wireless router.
(working as root)
......
#wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D wext
#iw wlan0 link
Not connected.
Even I disable the WPA authentication using,
iwconfig wlan0 essid XXXXXXXXXXXXX
of no avail.
But the GNOME wireless tray is functioning(can select, connect, disconnect etc.)
Thank you a lot in advance.
Latest wpa_supplicant is able to do all the job itself.
The wpa_supplicant option you wrote seem to me ok.
But please, check the options in the file "/etc/wpa_supplicant.conf", if it readable and is well written (ssid,wpa,password correct....)