3

I'm trying to setup a very simple OSPF network with Vyatta. From the best of my knowledge they let all traffic in by default, and I haven't set any firewall rules. The vyatta instances are launched as virtual instances inside DevStack, and I've allowed ICMP messages to get inside them.

The network looks like this: Network topology

I'm able to ping from:
* 10.0.1.4 (R1 eth1) to 10.0.1.6 (R2 eth0) and vice versa
* 10.0.2.7 (R3 eth0) to 10.0.2.5 (R2 eth1) and vice versa

However, when I try to ping from R1 to R2 on the address 10.0.2.5 I never get back any reply on R1. When sniffing traffic with tcpdump on R2 I can see the following:

16:31:29.540951 IP 10.0.1.4 > 10.0.2.5: ICMP echo request, id 7301, seq 14, length 64
16:31:29.541297 IP 10.0.2.5 > 10.0.1.4: ICMP echo reply, id 7301, seq 14, length 64
16:31:30.540303 IP 10.0.1.4 > 10.0.2.5: ICMP echo request, id 7301, seq 15, length 64
16:31:30.540536 IP 10.0.2.5 > 10.0.1.4: ICMP echo reply, id 7301, seq 15, length 64
16:31:31.541623 IP 10.0.1.4 > 10.0.2.5: ICMP echo request, id 7301, seq 16, length 64
16:31:31.542315 IP 10.0.2.5 > 10.0.1.4: ICMP echo reply, id 7301, seq 16, length 64

It seems that the request is received and a reply is sent back, but it never gets back to R1. I can verify this by sniffing on eth0 on R0 without seeing any traffic going trough the interface. This is a big confusion for me.

The same thing happens when I try to ping from R3 to 10.0.1.6.

When I try to ping from R1 to R3 and sniff traffic with tcpdump on both R2 and R3 I can see that the requests goes trough R2 but never reaches R3.

Output from tcpdump on R2:

16:38:13.230972 IP 10.0.1.4 > 10.0.2.7: ICMP echo request, id 7302, seq 5, length 64
16:38:14.230283 IP 10.0.1.4 > 10.0.2.7: ICMP echo request, id 7302, seq 6, length 64
16:38:15.232537 IP 10.0.1.4 > 10.0.2.7: ICMP echo request, id 7302, seq 7, length 64
16:38:16.241314 IP 10.0.1.4 > 10.0.2.7: ICMP echo request, id 7302, seq 8, length 64

The routing table on R1 shows that it should send the requests with destination of 10.0.2.0/24 to R2 on ip 10.0.1.6 and routing table on R3 shows that it should send the requests with destinations of 10.0.1.0/24 to R2 on ip 10.0.2.5. This is also confirmed with the output from above.

Below is output from the ip route and configuration from R1, R2, R3

ip route for R1:

vyatta@R1:~$ show ip route

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 10.0.0.0/24 is directly connected, eth0
O   10.0.1.0/24 [110/10] is directly connected, eth1, 17:04:56
C>* 10.0.1.0/24 is directly connected, eth1
O   10.0.1.4/32 [110/10] is directly connected, lo, 16:15:49
C>* 10.0.1.4/32 is directly connected, lo
O>* 10.0.2.0/24 [110/20] via 10.0.1.6, eth1, 17:03:23
C>* 127.0.0.0/8 is directly connected, lo

ip route for R2:

vyatta@R2:~$ show ip route

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

    O   10.0.1.0/24 [110/10] is directly connected, eth0, 01:39:14
C>* 10.0.1.0/24 is directly connected, eth0
O   10.0.1.4/32 [110/20] via 10.0.1.4 inactive, 00:51:29
O   10.0.2.0/24 [110/10] is directly connected, eth1, 01:39:08
C>* 10.0.2.0/24 is directly connected, eth1
C>* 127.0.0.0/8 is directly connected, lo

ip route for R3:

vyatta@R3:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

O>* 10.0.1.0/24 [110/20] via 10.0.2.5, eth0, 17:07:20
O>* 10.0.1.4/32 [110/30] via 10.0.2.5, eth0, 16:20:33
O   10.0.2.0/24 [110/10] is directly connected, eth0, 17:08:05
C>* 10.0.2.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo

R1 configuration

vyatta@R1:~$ show configuration                                                 
interfaces {
    ethernet eth0 {
        address 10.0.0.5/24
    }
    ethernet eth1 {
        address 10.0.1.4/24
    }
    loopback lo {
        address 10.0.1.4/32
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            network 10.0.1.0/24
        }
    }
}
service {
    ssh {
    }
}
system {
    config-management {
        commit-revisions 20
    }
    console {
        device ttyS0 {
            speed 9600
        }
    }
    host-name R1
    login {
        user vyatta {
            authentication {
                encrypted-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.vyatta.pool.ntp.org {
        }
        server 1.vyatta.pool.ntp.org {
        }
        server 2.vyatta.pool.ntp.org {
        }
    }
    package {
        repository community {
            components main
            distribution stable
            url http://packages.vyatta.com/vyatta
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }

R2 configuration

vyatta@R2:~$ show configuration                               
interfaces {
    ethernet eth0 {
        address 10.0.1.6/24
        hw-id 00:0c:29:9f:5f:22
    }
    ethernet eth1 {
        address 10.0.2.5/24
        hw-id 00:0c:29:9f:5f:23
    }
    loopback lo {
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            network 10.0.1.0/24
            network 10.0.2.0/24
        }
    }
}
service {
    ssh {
    }
}
system {
    config-management {
        commit-revisions 20
    }
    console {
        device ttyS0 {
            speed 9600
        }
    }
    host-name R2
    login {
        user vyatta {
            authentication {
                encrypted-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.vyatta.pool.ntp.org {
        }
        server 1.vyatta.pool.ntp.org {
        }
        server 2.vyatta.pool.ntp.org {
        }
    }
    package {
        repository community {
            components main
            distribution stable
            url http://packages.vyatta.com/vyatta
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug

Configuration for R3

vyatta@R3:~$ show configuration                               
interfaces {
    ethernet eth0 {
        address 10.0.2.7/24
    }
    loopback lo {
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            network 10.0.2.0/24
        }
    }
}
service {
    ssh {
    }
}
system {
    config-management {
        commit-revisions 20
    }
    console {
        device ttyS0 {
            speed 9600
        }
    }
    host-name R3
    login {
        user vyatta {
            authentication {
                encrypted-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.vyatta.pool.ntp.org {
        }
        server 1.vyatta.pool.ntp.org {
        }
        server 2.vyatta.pool.ntp.org {
        }
    }
    package {
        repository community {
            components main
            distribution stable
            url http://packages.vyatta.com/vyatta
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
}

Can someone tell me what I'm missing? It's a really simple configuration but from what I've read it should work.

Thanks, Muff

  • If you are only sniffing on R2, you cannot be sure that the replies from R2 do not get back to R1, nor can you be sure that R3 never gets the requests. You need to include complete configurations from all three routers. Also, you need to make sure that R1 and R3 don't have a firewall or something else which blocks incoming ICMP. – Ron Maupin Feb 11 '16 at 18:27
  • What I mean is that R2 seems to be responding because of: 10.0.2.5: ICMP echo request, id 7301, seq 14, length 64 10.0.1.4: ICMP echo reply, id 7301, seq 14, length 64 I was sniffing on R1 and R3 as well, but didn't see anything on them. Since I'm using Vyatta I don't think theres anything blocking because from what I've understood it let all traffic in by default, and I'm also able to ping the routers when inside the network – Muff Feb 11 '16 at 18:36
  • You need to edit your question to include this information, and the full configurations for each router. With incomplete information, you are asking us to guess. – Ron Maupin Feb 11 '16 at 18:38
  • I've done so now. – Muff Feb 12 '16 at 8:32
  • Respectfully, OSPF does not ping. ICMP includes ping. You might try sourcing your ping from a different interface. – Ronnie Royston Sep 12 '16 at 16:27
2

On R1, you have :

ethernet eth1   address 10.0.1.4/24
loopback lo address 10.0.1.4/32

Change the loopback IP address, it should be better.

| improve this answer | |
  • What should I change it to? And why does it matter for this case? – Muff Feb 12 '16 at 9:13
  • it's abnormal to have the same IP address - actually to have IP networks that overlap - on different interfaces. – JFL Feb 12 '16 at 9:15
  • Ok. I've changed it to 127.1.1.1/24 now. But still without any success to ping other segments – Muff Feb 12 '16 at 10:12
  • @Muff, if you ever want to advertise or use your loopback for routing, you need to use a real IP address, not a host loopback address (127.0.0.0/8), which is different than a router loopback address. – Ron Maupin Feb 12 '16 at 15:16
  • Ok, but shouldn't it be possible to ping the eth0 and eth1 interfaces on the routers over different network segments regardless of this? – Muff Feb 12 '16 at 15:25
0

It turned out that the setup I had was 100 % working. The error was in the DevStack environment somehow. I spent way too many hours debugging my setup before I tried to completely re install DevStack. When I did, it worked.

Hope the config I provided above helps someone in the future.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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