2

I'm trying to encapsulate IP packets in MPLS, transported over a GRE tunnel between two Linux hosts (a and b). a has 10.199.0.1 on GRE tunnel interface foo4, while b has 10.199.0.2 on GRE tunnel interface foo4. I'm able to ping each other with the the following route:

10.199.0.0/24 dev foo4

on both a and b.

Now I want to encapsulate the packets that go through the tunnel with MPLS. I'm doing the following on a:

ip route change 10.199.0.0/24 encap mpls 100 dev foo4

... which encapsulates the packets from a that go into 10.199.0.0/24 according to my understanding. And the following on b to decapsulate the packet:

ip -f mpls 100 dev lo

... which decapsulates the packet and sends it to the local loopback for further routing.

With the above setting, a and b are both able to ping each other.

Then I'm applying the same strategy to b:

On b:

ip route change 10.199.0.0/24 encap mpls 101 dev foo4

On a:

ip -f mpls 101 dev lo

Yet it's not working. When I ping b from a, I get the following capture on a:

tcpdump: listening on foo4, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:47:50.888846 Out ethertype MPLS unicast (0x8847), length 104: MPLS (label 100, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 16234, offset 0, flags [DF], proto ICMP (1), length 84)
    10.199.0.1 > 10.199.0.2: ICMP echo request, id 21604, seq 1, length 64
14:47:50.894911  In ethertype MPLS unicast (0x8847), length 104: MPLS (label 101, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 49128, offset 0, flags [none], proto ICMP (1), length 84)
    10.199.0.2 > 10.199.0.1: ICMP echo reply, id 21604, seq 1, length 64

... and the following capture on b:

tcpdump: listening on foo4, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:51:03.544222  In ethertype MPLS unicast (0x8847), length 104: MPLS (label 100, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 56858, offset 0, flags [DF], proto ICMP (1), length 84)
    10.199.0.1 > 10.199.0.2: ICMP echo request, id 27962, seq 1, length 64
14:51:03.544393 Out ethertype MPLS unicast (0x8847), length 104: MPLS (label 101, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 54680, offset 0, flags [none], proto ICMP (1), length 84)
    10.199.0.2 > 10.199.0.1: ICMP echo reply, id 27962, seq 1, length 64

The packet reply packet has been received, yet ping didn't say that it received the packet (i.e. no reply on ping's stdout).

When I ping a from b, however, a did not make a reply. tcpdump on a:

15:15:13.594917  In ethertype MPLS unicast (0x8847), length 104: MPLS (label 101, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 52653, offset 0, flags [DF], proto ICMP (1), length 84)
    10.199.0.2 > 10.199.0.1: ICMP echo request, id 47152, seq 2, length 64

tcpdump on b:

15:17:08.450994 Out ethertype MPLS unicast (0x8847), length 104: MPLS (label 101, exp 0, [S], ttl 64)
        (tos 0x0, ttl 64, id 52944, offset 0, flags [DF], proto ICMP (1), length 84)
    10.199.0.2 > 10.199.0.1: ICMP echo request, id 49211, seq 1, length 64

(the captures above are not performed in the same time; please ignore the difference in echo id's, sequence numbers and times)

My questions are as follows:

  • why when pinging b from a, ping reports that no reply has been received, despite the fact that echo replies are actually received?
  • why a won't respond to b's echo requests?

closed as off-topic by Ron Maupin Jun 28 '18 at 0:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Feb 19 '18 at 20:08
2

It turned out that I forgot to accept mpls input as well as to turn of rp_filter on machine a. Doing the following worked out the problem:

sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.mpls.conf.foo4.input=1

Not the answer you're looking for? Browse other questions tagged or ask your own question.