[j-nsp] GRE Strangeness

[Chris]

Hi all,

I have a couple of EX4200's that are stacked currently and I am trying
to get a GRE tunnel working on them with the destination being a Linux box.

Here is the setup so far:

I have a network of 192.168.1.0/24 behind the Linux box. This network is
trying to reach 10.10.10.0/24 which is attached to the pair of EX4200's.
The EX4200's have a tunnel endpoint IP of 10.5.5.1, while the Linux box
is 10.5.5.2.

The EX4200's have this for the config relevant to the tunnel:

root at acc-core> show configuration interfaces
....
ge-0/0/26 {
    description "M1Ke-1 CMC1";
    unit 0 {
        family ethernet-switching {
            vlan {
                members Management;
            }
        }
    }
}
....
gre {
    unit 0 {
        tunnel {
            source 176.74.24.241;
            destination 203.170.85.3;
        }
        family inet {
            address 10.5.5.1/30;
        }
    }
}
....
vlan {
    unit 100 {
        description "Management VLAN";
        family inet {
            address 10.10.10.254/24;
        }
    }
}
....
root at acc-core> show configuration routing-options static
...
route 192.168.1.0/24 next-hop 10.5.5.2;
...
root at acc-core> show configuration vlans
Management {
    vlan-id 100;
    l3-interface vlan.100;
}

There are no filters currently on them.

The strangeness is as follows:

>From the Linux box I can ping 10.5.5.1 (likewise the other way, the
EX4200's can ping 10.5.5.2).
>From the Linux box I can ping 10.10.10.254 (Juniper vlan.100 interface)
>From the Linux box I CAN'T ping 10.10.10.100 (Device behind Juniper,
plugged into ge-0/0/26)
>From the Juniper I CAN ping 10.10.10.100
>From the Juniper I CAN ping 192.168.1.254
>From the 10.10.10.100 device, I can't ping 192.168.1.0/24

The source for Linux box pings is 192.168.1.254.

On the Juniper, the routing table shows these entries:

For troubleshooting this issue, the first thing I checked was the routes:

root at acc-core> show route 192.168.1.254

inet.0: 9443 destinations, 9444 routes (9443 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

192.168.1.0/24     *[Static/5] 00:36:39
                    > to 10.5.5.2 via gre.0

I then tryed a traceroute from the 10.10.10.100 device to 192.168.1.254.
This results in a loop:

traceroute to 192.168.1.254 (192.168.1.254), 30 hops max, 40 byte packets
 1  10.10.10.254 (10.10.10.254)  1.084 ms  3.707 ms  0.588 ms
 2  xx.xx.xx.42 (xx.xx.xx.42)  0.412 ms  0.303 ms  0.525 ms
 3  xx.xx.xx.41 (xx.xx.xx.41)  0.877 ms  0.896 ms  3.826 ms
 4  xx.xx.xx.42 (xx.xx.xx.42)  3.347 ms  2.971 ms  2.956 ms
 5  xx.xx.xx.41 (xx.xx.xx.41)  2.557 ms  1.01 ms  1.181 ms

The .41 address is the border of the network, which it shouldnt be going
to. The border has a route learnt from the EX4200's via iBGP for
10.10.10.0/24 to go back to it, so the loop continues. The border is
giving a default route out to the EX4200's:

root at acc-core> show route 0.0.0.0

inet.0: 9455 destinations, 9456 routes (9455 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[BGP/170] 02:44:32, MED 0, localpref 100, from
176.74.24.251
                      AS path: 15830 I
                    > to 176.74.24.242 via vlan.50

Even with that route there, it should be looking at the more specific
/24 route that I have added in, I can't see any reason for it to go
through via the defaults. Has anyone seen this behaviour before? I have
been pulling my hair out for the last couple of hours trying to figure
it out, no doubt the problem is something basic after all that.

Thanks