Generic Route Encapsulation (GRE) EX4300
As of 14.1X53-D35.5 EX4300's support GRE tunnels. The following is a quick run through on the configuration and then verification of the tunnel operation.
In this experiment we want to send all traffic destined for 192.168.33.3 over a GRE tunnel that is terminated on irb.100 on one side of the network and on irb.120 on the other. EX4300-2 has no role in the GRE and is only participating in OSPF. This lab assumes all routing has already been configured and all interfaces and IP's are reachable prior to starting the GRE configuration.
NOTE: There is no requirement to #set chassis fpc 0 pic 0 tunnel-services. The gr-0/0/0 interface is instantiated by the JUNOS software package and is available in 14.1X53-D35.5. The GRE interface is not available in the EX4300 until this D35.5 version.
On EX4300-1 the source interface is where the tunnel will terminate on the switch and the destination is the exit point of the tunnel on EX4300-3.
EX4300-1 Configuration:
EX4300-1# show interfaces gr-0/0/0
unit 13 {
tunnel {
source 192.168.100.1;
destination 192.168.120.1;
}
family inet {
address 100.2.2.2/30;
}
}
For a path back across the tunnel on EX4300-3 we reverse the source and destination addresses.
EX4300-3 Configuration:
EX4300-3# show interfaces gr-0/0/0
unit 13 {
tunnel {
source 192.168.120.1;
destination 192.168.100.1;
}
family inet {
address 100.2.2.1/30;
}
}
By adding an IP address on the tunnel itself we can provide a point of reference when forwarding routes and it can be used for troubleshooting. Since it is point-to-point you can use any /30 or /31 that you have available. In this case I chose the 100.2.2.0/30 network.
NOTE: You will no doubt notice that we are using gr-0/0/0 interface with unit 13. While I randomly chose unit 13 you can utilize up to 512 subinterfaces. However, only gr-0/0/0 can be instantiated, and is done so in software, you cannot add your own gr-0/0/14 interface for example.
Once you have committed the changes - A quick check of the interface status and routes on EX4300-1 and EX4300-3 show the interface is up and up.
EX4300-1 Check:
EX4300-1# run show interfaces gr-0/0/0 terse
Interface Admin Link Proto Local Remote
gr-0/0/0 up up
gr-0/0/0.13 up up inet 100.2.2.2/30
EX4300-3 Check:
EX4300-3# run show interfaces gr-0/0/0 terse
Interface Admin Link Proto Local Remote
gr-0/0/0 up up
gr-0/0/0.13 up up inet 100.2.2.1/30
And now we should be able to ping across the tunnel.
EX4300-3 PING:
EX4300-3# run ping 100.2.2.2 source 100.2.2.1 count 5 rapid
PING 100.2.2.2 (100.2.2.2): 56 data bytes
!!!!!
--- 100.2.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.249/1.416/1.691/0.162 ms
Now we need to tell our devices what traffic will utilize the GRE Tunnel (gr-0/0/0.13) that we have pinned up. For this exercise we are going to tell the loopbacks on both access devices to utilize the tunnel to communicate with each other.
EX4300-1 Routing Options:
EX4300-1# show routing-options
static {
route 192.168.44.4/32 next-hop 192.168.100.2;
route 192.168.33.3/32 next-hop 100.2.2.1;
}
On EX4300-1 we tell the device to reach 192.168.33.3 the next hop is the IP address of the GRE Tunnel.
Likewise on EX4300-3 we do the same thing towards 192.168.44.4 and point the next-hop to the remote end of the tunnel.
EX4300-3 Routing Options:
EX4300-3# show routing-options
static {
route 192.168.33.3/32 next-hop 192.168.120.2;
route 192.168.44.4/32 next-hop 100.2.2.2;
}
Once committed we can see the routes in the routing-table pointing to the GRE interface.
EX4300-1 Route towards 192.168.33.3:
EX4300-1# run show route 192.168.33.3
inet.0: 32 destinations, 35 routes (32 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.33.3/32 *[Static/5] 00:43:18
> to 100.2.2.1 via gr-0/0/0.13
[OSPF/150] 00:45:49, metric 0, tag 0
> to 10.1.1.9 via xe-1/0/32.98
EX4300-3 Route towards 192.168.44.4:
EX4300-3# run show route 192.168.44.4
inet.0: 34 destinations, 38 routes (34 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.44.4/32 *[Static/5] 00:42:48
> to 100.2.2.2 via gr-0/0/0.13
[OSPF/150] 00:46:38, metric 0, tag 0
> to 10.1.1.13 via irb.99
Next we can go to the respective access devices and source a traceroute from the loopback address to verify the tunnel is being utilized.
EX3300-1:
EX3300-1# run traceroute 192.168.33.3 source 192.168.44.4
traceroute to 192.168.33.3 (192.168.33.3) from 192.168.44.4, 30 hops max, 40 byte packets
1 192.168.100.1 (192.168.100.1) 2.931 ms 2.139 ms 3.359 ms
2 100.2.2.1 (100.2.2.1) 3.202 ms 2.313 ms 2.378 ms
3 192.168.33.3 (192.168.33.3) 4.175 ms 2.846 ms 2.974 ms
As you can see we are utilizing the tunnel interface and eliminating the extra hop that would be seen on a normal traceroute without the tunnel.
SUMMARY:
This was a successful lab test and concludes this post. Leave a comment for any questions.
No comments:
Post a Comment