There are a few ways to leak routes in and out of virtual routers in Junos. On the list is a cool feature called the logical tunnel interface.

So, what am I talking about?  One way to separate traffic on a router is to use virtual routers (VRs) so that you wind up with multiple routing tables on the same router.  This separate traffic, but you will usually (read: always) have a demand to get traffic from one VR to another.  There are a few different way to do that (see rib-group, instance-import, next-table, et al.), but one really cool way to do it is through logical tunnel interfaces.

Man, time is hard to come by of late.  I’ve had so little time to rest that’s it’s hard to get my thoughts together.  It’s a good thing in this case, though, since it’s my fantastic job that’s taking all my time.  It’s great to see new network and learn their internals…especially when they were designed by some long-time CCIEs who actually knew what they were doing.

One of the big things that I’m dealing with lately is VRFs.  I’ve implemented some VRF-lite stuff, but I’ve never had any practical experience with the full force of them.  I’m definitely learning here.  Since the blog here is really about my sharing what I’ve learned, let’s go through something that came up recently - terminating VPNs on one VRF while passing traffic to another.

My ISP at home is great.  I have infinite bandwidth because they have no idea how to do any rate limiting.  Heck, they’re not even skilled enough to know that I have several public IP addresses from their DHCP server.  That means, though, that they’re not ready for IPv6.  They’ve ignored my emails and support tickets asking about their deployment strategy, so I gave up and looked at turning up a tunnel with a broker.  I chose Hurricane Electric for no particular reason; they were just the first ones I found.  The setup was super-easy and works flawlessly.

I’m still studying for the ONT test, so I did some labs tonight.  One of them was to demonstrate the qos pre-classify command for tunnel interfaces.  When you have a packet sent over a GRE tunnel, the ToS field gets copied to the GRE packet, but there’s no way to see the original packet’s higher-level headers on the way out the interface.  This can be a problem if your service policy needs to see protocol, port, IPs, etc.  The fix for that is to enable qos pre-classify on the tunnel interface and cyrpto map; doing so will provide a copy of the original packet to the physical interface to classify the packet thoroughly.