[j-nsp] GRE Strangeness

Chris lists at blackhat.bz
Tue Jul 12 04:07:33 EDT 2011


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



More information about the juniper-nsp mailing list