Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Changed ipaddress of a droplet Question Question
No connection after reboot Question Question

Question

Cannot ping a secondary address assigned to a private interface in a VPC?

Posted August 27, 2020 1.2k views
Networking

Created two droplets in a VPC and each gets a ‘eth1’ with a IP address in some subnet.

Add another address from the same subnet to 'eth1’ on one droplet.
I cannot ping that address from the second droplet.

I can see ARPs coming through for the DO assigned addresses.

Is there some filtering going on in between?

Add a comment
chinchani
By:
chinchani

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Changed ipaddress of a droplet Question Question
No connection after reboot Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer
Yannek August 28, 2020

Hi,

The solution you are going to apply seems to not be officially supported by DO. Accordingly to the DO’s doc, ‘VPCs do not support multicast or broadcast’ - https://www.digitalocean.com/docs/networking/vpc/ .
However, your goal is still achievable. So, you added an IP address to the interface eth1 on (let’s call it) droplet1. To make it visible on droplet2 you need to update its ARP table. You can do that with arp command. On droplet2 execute:

sudo arp -v -i eth1 -s droplet1_added_ip droplet1_eth1_mac_address

e.g. sudo arp -v -i eth1 -s 192.168.10.10 ea:82:31:14:0a:fb

To display ARP table, execute arp command with no parameters.

Unfortunately, such solution needs updating droplet2’s ARP table, at least after its restarting. I am not sure if you would have to update it periodically as well. On some network devices static ARP entries are held just for few hours.

Reply Report
  • GetGunthr August 28, 2020

    @chinchani I had the exact same problem and same question. Especially after watching Rafael Rosa talk about how easy this is in his webinar at https://youtu.be/nbo5HrmZjXo.

    I found the solution to my problem, I am guessing you might have same issue. Are you running a DO cloud firewall on your VPC? If so, the internal IPs are blocked by the Inbound Rules. This was a surprise to me, I assumed the Inbound Rules only applied to the public network (eth0 on the NICs) but by default they apply to all traffic - hence the default ‘All IPv4’ and 'All IPv6’ source settings.

    There are a couple ways to configure your rules. For me the easiest was to add ICMP rule from teh 'New Rule’ dropdown and specify for Sources the subnet mask for all the internal IPs (i.e. 192.168.0.0/24). This worked great.

    Another way is to use TAGS. If you Tag all your Droplets, you can use the tag name as a source, then create a rule using tags instead of IPs. For example, I have two droplets serving as front-end web servers (App-01 and App-02) and a database droplet (Data-01). Both web server droplets have the tag WEB and the database droplet has the tag DATABASE. I chose New rule > Custom, and specified the following:

    • Protocol : TCP
    • Ports : 3306
    • Sources: WEB DATABASE

    When I saved the rule, the type automatically changed to MySQL. Now my front-end droplets can talk to my database droplet no problem.

    Hope this helps.

    Reply Report

Related

Looking for something else?

Ask a new question Search for more help