Score:1

Server

Can't ping internal network namespace

Gompu

12/3/22, 2:19 PM

I have created two network namespaces, i.e., red and blue on centos machine as follows:

[root@ip-xxx-xxx-xxx-xxx ~]# ip netns add red
[root@ip-xxx-xxx-xxx-xxx ~]# ip netns add blue

[root@ip-xxx-xxx-xxx-xxx ~]# ip netns
blue
red

I have created the virtual cable 'veth-red' and 'veth-blue' and then connected them using the following command:

[root@ip-xxx-xxx-xxx-xxx ~]# ip link add veth-red type veth peer name veth-blue

Then I attached the appropriate interface to each namespace as follows:

[root@ip-xxx-xxx-xxx-xxx ~]# ip link set veth-red netns red
[root@ip-xxx-xxx-xxx-xxx ~]# ip link set veth-blue netns blue

I then assigned IP addresses to each of these namespaces as follows:

[root@ip-xxx-xxx-xxx-xxx ~]# ip -n red addr add 192.168.15.1 dev veth-red

[root@ip-xxx-xxx-xxx-xxx ~]# ip -n blue addr add 192.168.15.2 dev veth-blue

I then bring up the interface using the IP link set up command for each device within the respective namespaces.

[root@ip-xxx-xxx-xxx-xxx ~]# ip -n red link set veth-red up
[root@ip-xxx-xxx-xxx-xxx ~]# ip -n blue link set veth-blue up

Then, when I check the interfaces inside each namespace, I get the 'veth-red' in 'red' namespace and 'veth-blue' in blue namespace as follows:

[root@ip-xxx-xxx-xxx-xxx ~]# ip -n red link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
17: veth-red@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7e:9d:42:79:2d:2f brd ff:ff:ff:ff:ff:ff link-netnsid 1
[root@ip-xxx-xxx-xxx-xxx ~]# ip -n blue link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
16: veth-blue@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 62:aa:79:55:46:56 brd ff:ff:ff:ff:ff:ff link-netnsid 0

My doubt arises when I try to send a ping from red to blue (IP address: 192.168.15.2) as follows:

[root@ip-xxx-xxx-xxx-xxx ~]# ip netns exec red ping 192.168.15.2
connect: Network is unreachable

Can someone let me know why am I getting 'Network is unreachable' when I did everything by the book? Please help

331

1 + 3

networking

Michael Hampton

12/3/22, 2:55 PM

Show `ip -n red address` (and `blue`).

Gompu

12/3/22, 3:28 PM

[root@ip-xxx-xxx-xxx-xxx ~]# ip -n red address 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 17: veth-red@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 7e:9d:42:79:2d:2f brd ff:ff:ff:ff:ff:ff link-netnsid 1 inet 192.168.15.1/32 scope global veth-red valid_lft forever preferred_lft forever inet6 fe80::7c9d:42ff:fe79:2d2f/64 scope link valid_lft forever preferred_lft forever

Michael Hampton

12/3/22, 3:33 PM

That's unreadable. Edit your question.

Score:2

Server

chutz

12/4/22, 4:29 AM

You can troubleshoot with the route command:

# ip -n red route get 192.168.15.2
RTNETLINK answers: Network is unreachable

That's a good hint. You don't have a proper routing in the namespaces. In this case, it is because you missed the netmask when adding the IP address:

# ip -o -n red a
7: veth-red    inet 192.168.15.1/32 scope global veth-red\       valid_lft forever preferred_lft forever

Try adding the IP address with a /24 so the routing table knows that it can reach other IPs in the network through this interface.

clear all IP addresses first

# ip -n red  addr flush dev veth-red
# ip -n blue addr flush dev veth-blue

Add the correct IP with netmask (using /24 as least confusing, but even /30 will work for your example).

# ip -n red  addr add 192.168.15.1/24 dev veth-red
# ip -n blue addr add 192.168.15.2/24 dev veth-blue

And you're done:

# ip netns exec red ping -c2 192.168.15.2
PING 192.168.15.2 (192.168.15.2) 56(84) bytes of data.
64 bytes from 192.168.15.2: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 192.168.15.2: icmp_seq=2 ttl=64 time=0.022 ms

--- 192.168.15.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1035ms
rtt min/avg/max/mdev = 0.022/0.028/0.034/0.006 ms```

0 + 1

Gompu

12/4/22, 2:16 PM

Thanks, this worked

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Can't ping internal network namespace

TH: ไม่สามารถ ping เนมสเปซเครือข่ายภายใน

RO: Nu se poate trimite ping la spațiul de nume al rețelei interne

RU: Не удается пропинговать пространство имен внутренней сети

VI: Không thể ping không gian tên mạng nội bộ

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.