I have run into issue with running JVM processes on Docker after upgrading library due to development reasons to new version (Corda 4), as up to now I was setting the program (node) running in a Docker container to listen on all interfaces (0.0.0.0) while running in host mode on AWS EC2, which would bind it to all network interfaces, listening on all interfaces and using that forward.
Now in latest, 4, they have coded in https://github.com/corda/corda/blob/061db8b1a1ac1fa9f1a063caf7ce4f009aa283db/node/src/main/kotlin/net/corda/node/internal/Node.kt#L322 preventing this feature.
This in conjunction with https://docs.corda.net/corda-configuration-file.html
In practice the ArtemisMQ messaging services bind to all local addresses on the specified port. However, note that the host is the included as the advertised entry in the network map. As a result the value listed here must be externally accessible when running nodes across a cluster of machines. If the provided host is unreachable, the node will try to auto-discover its public one.
This results in having to specify the public IP in the node configuration, which it then tries to bind to, but it cannot as EC2 does not have the public ip visible as a direct network interface, just an internal routing interface(NIC) which at a later stage in their stack gets translated to public IP.
AWS EC2 instance ifconfig:
br-9121696521bd Link encap:Ethernet HWaddr 02:42:56:7C:6A:27
inet addr:172.18.0.1 Bcast:172.18.255.255 Mask:255.255.0.0
...
docker0 Link encap:Ethernet HWaddr 02:42:78:C3:69:1B
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
...
eth0 Link encap:Ethernet HWaddr 02:5F:BE:63:67:82
inet addr:10.0.0.56 Bcast:10.0.0.255 Mask:255.255.255.0
...
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
...
veth0c214d6 Link encap:Ethernet HWaddr BE:2A:29:08:94:B3
inet6 addr: fe80::bc2a:29ff:fe08:94b3/64 Scope:Link
...
veth2b54799 Link encap:Ethernet HWaddr 66:81:E9:01:91:10
inet6 addr: fe80::6481:e9ff:fe01:9110/64 Scope:Link
...
veth60fffa5 Link encap:Ethernet HWaddr 7A:FE:10:33:A9:80
inet6 addr: fe80::78fe:10ff:fe33:a980/64 Scope:Link
...
vethe4f9a9a Link encap:Ethernet HWaddr EE:C7:CB:C8:25:85
inet6 addr: fe80::ecc7:cbff:fec8:2585/64 Scope:Link
Outcome:
Corda now forces me to set in node.conf p2pAddress which is then published to NMS, and used by other nodes to communicate with it.
I cannot set EC2 public IP as Corda attempts to "bind" to the NIC with that hostname, which is not exposed directly to EC2
I cannot set it to 0.0.0.0 to make it bind to all nics and listen to all incoming routes as they hardcoded in core Node.kt to stop node if 0.0.0.0 provided
I can only set to ip visible in container/host which are not visible outside -> node unreachable
I have looked at trying to fool Docker network stack into representing its local ip to that of the external ip as it is virtual network layer, but it only provides subnetting ability to existing NIC (10.0.x.x IP) or in loopback ip ranges ( 192.168.x.x or 10.x.x or 172.x.x.x)
This post Running corda nodes in different machines also exemplifies precisely my issue and the solution i came to as well, which they closed off in 4.0
Question/Possibilities
Option 1 (AWS/Docker):
Spoof Public IP to be visible in EC2 as actual NIC IP via Docker IPAM/Pipeworks or Linux specific via IP masquerading with a virtual interface ?
Option 2(Corda specific):
Change configuration to somehow accept 0.0.0.0 or make detectPublicIp be more inteligent and use NMS to discover its own IP. I expected it to have this intelligence but I later discovered it just looks on at available NIC's. It fails with AMQ224000 error.
From my understanding Corda 4.0 is unable to run on public cloud providers (Azure/AWS/GC) due to it requiring NIC with Public IP to be present, element which Azure/AWS/GC do not have available, could somebody from Corda team correct me if I am wrong ?
If I understand correctly, the internal Artemis server cannot bind as it's using(by default) the p2pAddress which now has to be a valid public one. You can override this by providing a messagingServerAddress as well. See https://docs.corda.net/corda-configuration-file.html?highlight=messagingserveraddress for a bit more details.
Related
I am struggling with a network problem.
My computer needs to be linked to two differents networks. one via PCI the other one via a USB adapter. The pci is the "usual" network, the usb is to use for specific address.
I have tried differents solutions, with dns, multiple wired connection, modifiying /etc/network/interfaces, ...
But I can't manage to have the 2 networking working at the same time.
Do you have any solution. I am working with Debian - jessie.
Cheers
Since you haven't specified any networks, IP addresses or device names, I will use my machine as an example.
I have an IOGear ethernet USB dongle which shows up as device enx0050b6d341bb, and an RTL811 PCI ethernet device which shows up as eth0. eth0 is plugged into the "main" network which has a DHCP server and enx0050b6d341bb is connected to a private switch on my workbench.
If I want to use eth0 to connect to the internet, but use enx0050b6d341bb to connect to anything on network 192.168.168.0/24, /etc/network/interfaces will look like this:
auto lo
iface lo inet loopback
# Obtain DHCP address from server
auto eth0
iface eth0 inet dhcp
# Connect to 192.168.168.0 network
auto enx0050b6d341bb
iface enx0050b6d341bb inet static
address 192.168.168.3
network 192.168.168.0
netmask 255.255.255.0
Since I only have one device using DHCP, my default route will automatically go through that device, which happens to be exactly what I want :-)
solargy#GEPY633007AX:~$ ip route
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.67
192.168.168.0/24 dev enx0050b6d341bb proto kernel scope link src 192.168.168.3
The above shows that my default traffic will go through eth0 and that any traffic for addresses in network 192.168.168.0/24 will go through enx0050b6d341bb. To verify that, you can find out which device will be used to communicate with address 192.168.168.2:
solargy#GEPY633007AX:~$ ip route get 192.168.168.2
192.168.168.2 dev enx0050b6d341bb src 192.168.168.3
cache
As you can see, any traffic for 192.168.168.2 will go through enx0050b6d341bb.
I'm trying to create a bash script and a small part of it requires figuring out if, given an IP address of another computer, what interface is on that same network.
So if my computer is has the following interfaces (not including lo):
eth0 Link encap:Ethernet HWaddr XX
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
wlan0 Link encap:Ethernet HWaddr XX
inet addr:192.168.5.100 Bcast:192.168.5.255 Mask:255.255.255.0
and I know that there is a computer at the following address:
192.168.0.101
is there a simple way to extract the answer eth0?
P.S. This question is NOT asking about getting the the interface given the address of my own computer like this post is.
no, the name eth0 is not broadcasted in any way, so there is no way to get it remotely. it is just a name that is only internally used.
You'd have to log into the remote machine (ssh) and get the info using for example ifconfig.
if you need the macaddress of the remote machine (on your network) use arp:
arp 192.168.0.101
I have IPv6 on a linux machine and my network and it works. Now I want to set up DHCP for it. I set up the isc-dhcp-server and configured the subnet.
Another linux machine (both debian 7) acts as test-client and gets the IP, but not in the range configured, and, much worse, gets a /64 subnet and not a /80.
Since the IP pool available on the router is already a subset of the /64 assigned to another upstream-machine, I need a smaller subnet. I cannot allow it to be /64.
Config of dhcp server:
subnet6 2a01:4f8:202:6106:acda::/80 {
range6 2a01:4f8:202:6106:acda:f000::/84;
option dhcp6.name-servers 2a01:4f8:202:6106::2;
prefix6 2a01:4f8:202:6106:acda:c000:: 2a01:4f8:202:6106:acda:f000:: /84;
}
ifconfig output on client:
debian#arm:~$ sudo ifconfig
[sudo] password for debian:
eth0 Link encap:Ethernet HWaddr c8:a0:30:ae:48:24
inet addr:192.168.0.104 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::caa0:30ff:feae:4824/64 Scope:Link
inet6 addr: 2a01:4f8:202:6106:acda:ff2f:452c:b7b5/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:185 errors:0 dropped:0 overruns:0 frame:0
TX packets:201 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18222 (17.7 KiB) TX bytes:23159 (22.6 KiB)
Interrupt:56
A windows-7 machine also connected does not get an IPv6 address at all.
config of the radvd on the server (in case it matters)
interface eth0 {
AdvSendAdvert on;
prefix 2a01:4f8:202:6106:acda::/80 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
route 2000::/3
{
};
};
What's wrong? Why is this not working? Is the bad subnet-size a bug in the server? Or the client?
Result of the bad subnet-size is that for example the nameserver, 2a01:4f8:202:6106::2 , in the 64-bit range, is not reachable. The client thinks it should be on the lan segment and tries to get the link-local IPv6 and the ethernet MAC of it and fails. It needs to go via the router. When I set the subnet manually to /80 everything works fine.
First of course the general warning: using non-/64 subnet sizes will break things. Your ISP should really give you a decent amount of address space to work with, like a /48 or a /56. You can then route /64s out of that wherever you want.
Then you have to look at how your ISP gives you your current /64. If they route it to a LAN that is connected to your server's eth0 interface then there is nothing much you can do except bridging or proxy-ND because you have to make it look like everything is directly connected to that LAN. Both methods have their own complications.
If you are bridging to a LAN managed by your ISP then you shouldn't run anything like radvd or dhcpd because you'll interfere with your ISP.
If you are using proxy-ND or your ISP routes the /64 to your server (so you have a different IPv6 address on your server's interface to the ISP and the ISP routes the /64 to that interface) then you should indeed run radvd and dhcpd but only on the internal interface, not towards your ISP.
Back to your RA+DHCPv6 setup because that part of your question is easy to answer. There are three things wrong with your radvd setup (so, yes, it matters a lot :)
First you cannot do SLAAC (StateLess Address Auto Configuration) on anything except a /64 so you'll have to turn AdvAutonomous off. Then you have to tell the clients that a managed (stateful) DHCPv6 server is available so turn the AdvManagedFlag on. And the route 2000::/3 is also unnecessary. You are advertising that you are the default gateway and this more-specific doesn't add anything useful.
interface eth1 {
AdvSendAdvert on;
AdvManagedFlag on;
prefix 2a01:4f8:202:6106:acda::/80 {
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr on;
};
};
I am trying to run PTPDV2 (precision timing protocol) server which binds on interface for setting up multicasting.
I have a following virtual interface
eth1:0 Link encap:Ethernet HWaddr 00:00:50:A0:42:BD
inet addr:10.2.0.17 Bcast:10.2.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xa000
Now, I don't have any issues binding to a normal interface, but for any virtual interface I get a failure.
(ptpd debug1) 09:28:12.995509 (init) netInit
(ptpd debug1) 09:28:12.996254 (init) Local IP address used : 10.2.0.17
(ptpd error) 09:28:12.997099 (init) failed to call SO_BINDTODEVICE on the interface (strerror: No such device)
I need some pointers to overcome this issue. Any help here is appreciated.
I found a workaround to this problem. But it may not be the perfect solution. I am still open for suggestions.
I observed that socket bind is successful, so the socket does get the IP address of eth1:0 . But SO_BINDTODEVICE was failing since this was a virtual interface.
So i decided to call SO_BINDTODEVICE on the real interface that is eth1, since both eth1:0 and eth1 share same MAC.
Which this, i am no longer blocked as the responses are typically unicast for me. But this may not work perfectly if some one wants multicast support on receiving too.
Open for suggestion
I have a problem:
When I try to connect to a network, initially with ifconfig eth2 I get (correctly):
eth2 inet addr:192.168.1.56 ....
inet6 addr: fe80:221:ff:fe96:4598/64
but after a few seconds the 102.168.1.56 disappears and after some other seconds disappears the inet6 address too. In this case the network is wireless and no DHCP.
At uni, the connection is a DHCP one. It works for the first few seconds but after it doesn't.
Any possible solution?
Whats this 102.168.1.56?
cat /var/log/syslog will give more info about what happening in the system. Usually it contains large amount of information.