I am trying to map the notion of an openstack port to an IP abstraction. In the openstack documentation I see :
"A port is a connection point for attaching a single device, such as the NIC of a server, to a network. The port also describes the associated network configuration, such as the MAC and IP addresses to be used on that port."
So I assume a port must correspond to an IP interface (which in turn can map to a bridge, an ethernet interface or to one end of a veth link).
Is this a correct assumption? I am trying to figure out what IP abstraction maps to a loadbalancer port and I can't yet find it.
Thanks
Answering my own question (hopefully of help to others):
An openstack port corresponds to an ovs (or linnuxbridge) port that connects you up to a virtual network. A prefix of the port ID is used as a bridge name. You can create a port to a network and add it to a router.
Related
If I connect a device via ethernet onto a switch, and do not receive an IP address via DHCP, how do I determine what the correct settings for that network should be, i.e. how do I choose a static IP address, subnet mask and gateway?
The specifics in my case are that I have an NVR with an 8 port POE switch that has 3 cameras plugged into it. I plugged my Windows 10 PC into the switch, expecting to be issued an IP address from the NVR via DHCP, but my PC was not given an IP. Perhaps the NVR assigns IPs via BOOTP? I want to get onto the network, probably by assigning a static IP that's not already used, then determine the IPs of the cameras so I can stream video from them directly using VLC.
Can I use tcpdump? There should be plenty of traffic from the cameras to the NVR.
how do I choose a static IP address, subnet mask and gateway?
The short answer - this should be done by your network administrator. If you are the network administrator - you should. But seems that you are connecting to the network you know nothing about.. Anyway here are some points that perhaps can help you.
There is a special thing called ARP Duplicate Address Detection (DAD). In Linux you can check if the particular IP is occupied in your broadcast segment with help of arping utility. From MAN page:
-D
Duplicate address detection mode (DAD). See RFC2131, 4.4.1.
Returns 0, if DAD succeeded i.e. no replies are received.
So if IP address is occupied you will see something like:
-bash-4.4# arping -D 10.0.99.99 -I eth0
ARPING 10.0.99.99 from 0.0.0.0 eth0
Unicast reply from 10.0.99.99 [DE:AD:BE:EF:00:8D] 1.274ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
If this IP address is vacant, you'll see no responses. Read about ARP ping in Windows.
Also you can inspect the network through the tcpdump (to see some IP addressing info at least in broadcast packets), nmap and some other scanning utilities, but this topic is too broad (and at the same time it's well disclosed on the Internet). Btw you have to consider network architecture difficulties: vlan and so on.
I'm not sure if I understand the purpose of OpenStack Neutron management subnet right.
OpenStack docs suggest that it is a VLAN that is created to let OpenStack components to talk to each other and also allows me to SSH into the host (physical machine).
I assumed that upon splitting a network interface into VLANs for OpenStack, I abandon the IP address, assigned to that physical interface in untagged l3 network (say, 10.100.70.), and instead split it into 3 VLANs, and again get an IP address from my provider infrastructure in another provider subnet on this logical interface (say, 10.100.71.).
But here is a page that explains how to install OpenStack with InfiniBand, and it makes use of both management VLAN and PXE/admin interface. So I keep an IP in the untagged PXE network and also create a tagged management VLAN and get IP addresses on both.
Aren't PXE/admin network and management VLAN network redundant here?
I have machine with two Ethernet network interfaces. eno0 and eno1. eno0 is where the internet is plugged in and eno1 has a connected Ethernet device. I got its IP through Link-Local Address method and it's 168.254.80.23. I would like to send a packet to port 5000.
I would like to use Rust's UdpSocket to connect to this address and given port and send some packet. One such packet is already correctly described in the variable buf_with_message:
let sock = UdpSocket::bind("0.0.0.0:0"); //Let system assign me an ip and port
sock.connect(("168.254.80.23",5000)); // Connect to device ip and pre-designated port 5000
sock.send(&buf_with_message).unwrap(); //Send the packet
That connection occurs as it should, but the packet is send over eno0 instead of eno1. I have no idea how to specify the interface it should use. I have found some answers that in C SO_BINDTODEVICE could be used to do this.
I have also tried assigning an IP to the interface through
sudo ifconfig eno1 192.0.2.10
and then changing the 0.0.0.0 address in UdpSocket::bind to this new address with no positive result.
I see a potential solution to go straight to raw sockets using the pnet crate but I think that would be overkill.
I am aware that RFC 3927 warns against hosts with multiple interfaces, but I didn't find any options for an alternative without ditching LLA and implementing a DHCP server.
I have started a DHCP server and I am communication over the IP that is given through DHCP. I have no idea why LLA assigned IP doesn't work when DHCP does, but it works for now.
When setup a IP-Alias via gloud command or the interface, it works out of the box. But in the machine itself, i do not see any configuration, ip addr-entries, no firewall rules, no routes that would allow to be the machine pingable - but it's pingable (local and remote)! (for example 10.31.150.70, when you setup a 10.31.150.64/26-subnet, and you primary IP is 10.31.150.1)
On the other hand, the primary IP of the machine is a /32-Netmask. For example:
10.31.150.1/32, Gateway: 10.31.0.1/16. So, how can the machine reach the gateway, 10.31.0.1, when the gateway is out of the range?
When removing the Main-IP via ip addr del, the aliases aren't pingable anymore.
Google runs a networking daemon on your instance. It runs as the google-network-daemon service. This code is open source and viewable at this repo. This repo has a Python module called google_compute_engine which manages IP aliasing among other things. You can browse their code to understand how Google implements this (they use either ip route or ifconfig depending on the platform)
To see the alias route added by Google on a Debian box (where they use ip route underneath for aliasing) run the following command.
ip route ls table local type local dev eth0 scope host proto 66
If you know your Linux commands, you can remove appropriate routes after stopping the daemon, and then assign the alias IP address to your primary interface as the second IP address to see the ifconfig approach in action as well.
When alias IP ranges are configured, GCP automatically installs VPC network routes for primary and alias IP ranges for the subnet of the primary network interface. Alias IP ranges are routable within the GCP virtual network without requiring additional routes. That is the reason why there is no configuration on the VM itself but still it's pingable. You do not have to add a route for every IP alias and you do not have to take route quotas into account.
More information regarding Alias IP on Google Cloud Platform (GCP) can be found in this help center article.
Be aware that Compute Engine networks only support IPv4 unicast traffic and it will show the netmask as /32 on the VM. However, it will still be able to reach the Gateway of the subnet that it belongs to. For example, 10.31.0.0/16 includes hosts ranging from 10.31.0.1 to 10.31.255.254 and the host 10.31.150.1 is within that range.
To further clarify why VM instances are assigned with the /32 mask, it is important to note that /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communications are established and everything works.
In addition to that, network masks are enforced at the network layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway).
Note that removing the primary IP will break the reachability to the metadata server and therefore the IP aliases won't be accessible.
What are the effects of incorrectly setting the netmask? I have a C++ application that sets the network mask of a device. If the netmask is set incorrectly, tftp doesn't seem to work properly. Why would this happen? What other problems occur when the netmask is not properly set for a device/PC?
While this question is probably more about IP networks than programming it is a challenging subject for many developers.
The netmask delimits the host address (your PC or server) and the network address (the part of the logical network infrastructure in which your system lives). The two parts are used to deliver the data packet to the correct device. The network address is obtained by ANDing the netmask with the IP Address. Consider the following scenario:
IP Address: 10.0.1.1
Netmask: 255.255.0.0
The host address portion of the IP address for our PC is 1.1, so the PC knows that any host addresses starting 10.0. are local to it. Any addresses that then start 10.1, etc, are not 'local' and will need to be forwarded to a router. If you have another device intended to be on the same network that is:
IP Address: 10.0.2.1
Netmask: 255.255.255.0
Here the netmask is wrong for our example setup, this device is now going to see the network address as 10.0.2 and the host address as 1, if it tries to communicate with 10.0.1.1 it will see a network address of 10.0.1! Not local and so will refer it to the default router for forwarding. If the netmask was correctly set (i.e. the same as the first example, assuming that's the correct setting for your network) then the second device would see the first as local, i.e. on the 10.0 network and wouldn't attempt to forward the packet to a router.
Many protocols will happily cope with this but tftp is intended to operate within a single network and so will fail as there's a perception that the target is on a different network.
This may not describe your exact situation but I hope that the example demonstrates the important principle that configuration matters, you can't have an inaccurately configured environment and expect it to work.
The netmask determines which IP adresses are local (non-routed); IP adresses outside that range go through the router. If the netmask is wrong, the program tries to directly access sites where it has to go through the router, or vice versa.
The netmask defines, which part of the IP-address is used as address for the network and which part is used for the workstations.
First Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.0.0
Both IPs are in the same net. They can communicate with each other without needing a router. That's because the IP-addresses will result in the same bitmask when you or it with the netmask.
Second Example:
IP1: 192.168.20.4
IP2: 192.168.192.4
NM: 255.255.128.0
Now both IPs are in different networks because when you or the IP-addresses with the Netmask, the resulting bitmask will be different and they wont be able to communicate with each other without a router that routes between the two networks.
You can test this by yourself with ipcalc.
Possible implications of mismatched netmask are explained here. In short:
The host is likely to construct routing table incorrectly.
The host will miss some broadcast packets and not send broadcasts properly.
Mis-function of TFTP is almost for sure caused by the first reason. It affects any other IP protocol in the same way.
Other answers mention only the first problem (which is OK, as the second one is rather marginal). Note that it is not the netmask of the interface itself which determines how the IP packets would be routed - it is the routing subsystem of the host; but the netmask is normally used for constructing the routing table.