Aaron's Worthless Words

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.

The logical tunnel (lt-0/0/0) interface is a special little guy that allows you to connect its units to each other.  The result is similar to connecting an Ethernet cable from one physical interface to another. With a little configuration, these guys provide a point-to-point interface that you can include in your routing setup.  Let’s look at an example.

set interfaces lt-0/0/0 unit 100 encapsulation ethernet
set interfaces lt-0/0/0 unit 100 peer-unit 200
set interfaces lt-0/0/0 unit 100 family inet address 192.168.0.100/24

set interfaces lt-0/0/0 unit 200 encapsulation ethernet
set interfaces lt-0/0/0 unit 200 peer-unit 100
set interfaces lt-0/0/0 unit 200 family inet address 192.168.0.200/24

The encapsulation lines are pretty straightforward. In this case, I want the link to appear as an Ethernet interface, but you can choose frame-relay, vlan, bridging, and others.

The peer unit lines tell what unit is connected to what other unit. Each lt-0/0/0 unit is a point-to-point link, so you have to tell the router what’s on the other end of the link (sorry…no multiaccess here). In this case, I want unit 100 to connect to unit 200, so I configure both units with the appropriate peer unit.

Of course, we can all figure out that we’re using IPv4 on these new units as well. In this case, I’ve put both interfaces on the 192.168.0.0/24 network (how original!).

Now that we have our interfaces configured, we need to put these interfaces into the correct VR. Don’t forget the security zone, too, if you’re running in flow mode. That’s beyond the scope here, though.

set routing-instances VR100 instance-type virtual-router
set routing-instances VR100 interface lt-0/0/0.100
set routing-instances VR100 interface lo0.100

set routing-instances VR200 instance-type virtual-router
set routing-instances VR200 interface lt-0/0/0.200
set routing-instances VR200 interface lo0.200

I put lo0.100 and lo0.200 in there to have something to advertise. You’ll see that in a second.

Now, let’s see if we can ping across.

root@TestSRX# run ping 192.168.0.100 routing-instance VR200
PING 192.168.0.100 (192.168.0.100): 56 data bytes
64 bytes from 192.168.0.100: icmp_seq=0 ttl=64 time=1.879 ms
64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=3.480 ms
<SNIP>

Woot! It works. Now we can treat these new interaces as if they are regular ole Ethernet. Since I’m not ready to try and blog about IS-IS, let’s just use the standard OSPF. I’m not going to go through the steps to configure OSPF, but here’s the routing table after all the interfaces are included.

root@TestSRX# run show route                  

VR100.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.100/32      *[Direct/0] 00:41:33
                    > via lo0.100
10.0.0.200/32      *[OSPF/10] 00:00:28, metric 1
                    > to 192.168.0.200 via lt-0/0/0.100
192.168.0.0/24     *[Direct/0] 00:38:21
                    > via lt-0/0/0.100
192.168.0.100/32   *[Local/0] 00:38:21
                      Local via lt-0/0/0.100
224.0.0.5/32       *[OSPF/10] 00:01:18, metric 1
                      MultiRecv

VR200.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.100/32      *[OSPF/10] 00:00:28, metric 1
                    > to 192.168.0.100 via lt-0/0/0.200
10.0.0.200/32      *[Direct/0] 00:41:33
                    > via lo0.200
192.168.0.0/24     *[Direct/0] 00:38:21
                    > via lt-0/0/0.200  
192.168.0.200/32   *[Local/0] 00:38:21
                      Local via lt-0/0/0.200
224.0.0.5/32       *[OSPF/10] 00:01:18, metric 1
                      MultiRecv

Look! OSPF routes! Sweet. Just to keep my OCD at bay, let’s ping from the loopback of one VR to the loopback of the other.

root@TestSRX# ping source 10.0.0.100 routing-instance VR100 10.0.0.200
PING 10.0.0.200 (10.0.0.200): 56 data bytes
64 bytes from 10.0.0.200: icmp_seq=0 ttl=64 time=1.463 ms
64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=1.443 ms
<SNIP>

Well, look at that.  It works again.

Let’s look back at the topic we’re discussing, though.  If we use OSPF between the VRs, we need to make sure our routing design allows us to filter routes between the VRs; the risk is that you may wind up having all the routes from each VR advertised to the other.  Kind of defeats the purpose, eh?  Running BGP between the VRs might be an option that allows you to control what routes go in and out.  Statics might be the answer, as well.  As long as you can filter the advertisements, you wind up with a pretty elegant solution for sharing routes between VRs.

Send any Marshmallow Peeps questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

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.

What I’m talking about is the old-school, static IPSec VPNs that we’ve all configured a million (or so) times.  You know the ones with crypto maps applied to interfaces?  Well, we’re going to configured one of those for the VRF called “CUSTOMER1″ terminated on an interface in the “INTERNET” VRF.  

There’s some terminology for these VRFs, actually.  The INTERNET VRF, which has the tunnel endpoint is called the front VRF (FVRF); CUSTOMER1 is called the internal VRF (IVRF).  I’ll try to remember to use those terms, but I make no promises.

First, we need to create the VRFs themselves.  Since the endpoints are in two different VRFs, we’ll need to have some routes leaked from the IVRF to the FVRF.  I could write 847829843828 words on route leaking and not cover everything in my limited experience, so you’ll have to look that up on your own if you don’t know what I’m talking about.  Route-target 65000:1 is exported from INTERNET and imported into CUSTOMER1

ip vrf INTERNET
rd 65000:1
route-target export 65000:1
!
ip vrf CUSTOMER1
rd 65000:101
route-target import 65000:1

At this point, we just put the interfaces in the right VRF along with their addresses.  We’ll also configure an ISAKMP policy just like we’ve done a million times.

crypto isakmp policy 100
 encr aes
 authentication pre-share
 group 2
!
interface Ethernet0/0
 ip vrf forwarding INTERNET
 ip address 192.0.2.1 255.255.255.0
!
interface Ethernet0/1.1
 encapsulation dot1Q 1
 ip vrf forwarding CUSTOMER1
 ip address 192.168.201.1 255.255.255.0

Next we’ll create a keyring that’s referenced by the IVRF.  This will make the key for the remote end available for use by that VRF.

crypto keyring KEY1 vrf INTERNET
  pre-shared-key address 192.0.2.101 key TEST.KEY

Now we create and ISAKMP profile, which is really the blood and guts that make all this work.  An ISAKMP profile references some of the important pieces of the tunnel – the IVRF in which to place the traffic, the keyring to use, and tunnel endpoint, and the FVRF where the tunnel terminates.

crypto isakmp profile CUSTOMER1-PROFILE
   vrf CUSTOMER1
   keyring KEY1
   match identity address 192.0.2.101 255.255.255.255 INTERNET

We’ll then create the ACL for interesting traffic. I’ll save some trees and not go through that since this should be pretty easy by now.

Now we can create the crypto map. This will be just like any other crypto map you’ve ever made with one exception; this is where you include that nifty ISAKMP profile we just made.

crypto map CM 100 ipsec-isakmp
 set peer 192.0.2.101
 set transform-set TS
 set isakmp-profile CUSTOMER1-PROFILE
 match address CUSTOMER1-TRAFFIC

Just like in other cases, we need to add a static route to make sure the router sends the packets destined for the remote end of the tunnel out the right interface. Since the FVPN is INTERNET, we’ll add static routes for that VRF. We’ll do the same for the tunnel endpoint just in case the default routes doesn’t go the right way.

ip route vrf INTERNET 192.0.2.101 255.255.255.0 192.0.2.2
ip route vrf INTERNET 10.0.0.0 255.255.255.0 192.0.2.2

Now the tunnel should be up, right? Probably not. If you take a close look, you’ll see that the FVRF has the route to the remote network, but the IVRF – the one that will use the tunnel – doesn’t. We’ll need to use MPBGP to leak those routes from one VRF to another. Did I mention that route leaking can get long-winded and that I’m not going to get into it? Yeah…it can get that bad. Just trust me that this works.

What we’re going to do is to start up BGP for both VRFs. At the same time, we’ll redistribute the static routes that we added above from the FVRF into the IVRF. Since we set up our imported and exported route-targets in the VRF definition, the static routes will magically appear in both VRFs.

router bgp 65000
bgp router-id 192.0.2.1
!
address-family ipv4 vrf INTERNET
 redistribute static
 exit-address-family
!
address-family ipv4 vrf CUSTOMER1
 exit-address-family

If we do a show ip route vrf CUSTOMER1, we’ll see the static routes from the INTERNET VRF. They’re real easy to spot. :)

...
B        10.0.0.0 [20/0] via 192.0.2.102 (INTERNET), 00:00:05
...
B        192.0.2.1 [20/0] via 192.0.2.102 (INTERNET), 00:00:05
...

That should do it. Now you should be able to talk from your local network in the CUSTOMER1 VRF and talk through a tunnel that’s established on the INTERNET VRF.

Send any Juniper configs questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

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.

When you add a new tunnel to your account, you are given a 64-bit IPv6 network to use at your local site and you have the option of asking for a 48-bit network as well.  I’m not planning on having more than one IPv6 subnet right now and the number of hosts don’t quite reach 1.84467441 × 10¹⁹, so I opted to stick with the provided network.  HE also provides an IOS configlet for your end of the tunnel.  Here’s the config I’m using sans the default route out Tunnel0.

interface Tunnel0
 description To Hurricane Electric IPv6
 no ip address
 ipv6 address 2001:470:1F0E:446::2/64
 ipv6 traffic-filter ACL-TUN0 in
 ipv6 inspect INSP-OUT out
 tunnel source FastEthernet0/1
 tunnel destination 216.218.224.42
 tunnel mode ipv6ip
end

We’re talking IOS here.  I have an ASA 5505 on the head of my network, and, though it supports IPv6 routing (and filtering), it doesn’t support the manual tunnel used to connect to HE.  I ended up picking an 1841 off of eBay to run parallel to my firewall.  There are other ways to connect the tunnel, though, and HE provides configurations for lots of platforms like Windows and Linux hosts; I’m a network guy, though…why not just install more network gear?

Don’t get caught up in the warm glow of IPv6, though.  This is the open Internet just like when your grandmother plugs the new Macbook Pro you got her directly into the cable modem.  You will need to put in some filtering and inspection to protect yourself at the edge.  Though beyond scope today, take a look at the lines for ipv6 inspect and ipv6 traffic-filter for a starting point.

Send any native IPv6 support questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

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.

Here’s the lab.  I was testing from TestHost1 to TestHost2 and configuring R1 to do the pre-classification.  Both R1 and R2 are 3640s running IOS 12.4(25b) and have a GRE tunnel between them.

I created a policy map that simply acknowledges the existence of ICMP packets; the router doesn’t do anything except match them in a class-map and smile at them on the way through.  Here’s the snippet.

class-map ICMP
 match protocol icmp
!
policy-map PM-S1/0-OUT
 class ICMP
!
interface S1/0
 service-policy output PM-S1/0-OUT
!
interface tunnel 0
 qos pre-classify

Not much going on there.  We match ICMP using NBAR’s built-in protocols and do absolutely nothing.  I did a few pings and noticed that there were no matches to the ICMP class and that all the packets were classified as class-default .  I thought that the pre-classify wasn’t working, so I cursed for a while after making no progress at all.  I had no idea what was wrong.

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: ICMP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: protocol icmp
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      467 packets, 39832 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

I need to stop here so people don’t get confused.  The configuration that you see is correct; the problem was actually with the NBAR protocols in the class-map.  As Jeremy Stretch notes at the bottom of this article, there’s some issue with matching NBAR protocols.  I later used an extended ACL to match ICMP which worked.  The same is true for the SSH stuff later.  Back to the show.

Here’s what I wound up with after cursing a lot and making random configuration changes to get the blasted thing to work.  Notice the order of the classes.

class-map match-any TUNNEL
 match protocol gre
!
policy-map PM-S1/0-OUT
 class TUNNEL
 class ICMP

I know that order is going to be important, but these are matching two totally different things, so it shouldn’t matter, right?  I checked out the policy-map again and saw that every packet was matching the TUNNEL class-map, and none were matching the ICMP class-map.

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: TUNNEL (match-any)
      441 packets, 49392 bytes
      5 minute offered rate 2000 bps
      Match: protocol gre
        441 packets, 49392 bytes
        5 minute rate 2000 bps

    Class-map: ICMP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name ICMP
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      467 packets, 39832 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

I finally went downstairs, talked it over with my wife who is my rubber duck, and finally figured it wouldn’t hurt to change the order of the classes.  Once I put ICMP before TUNNEL, it started matching.  I thought that was odd, so I left ICMP and added an SSH class and put it after the TUNNEL class.  I saw the ICMP match and the tunnel match, but I didn’t see a single match on SSH even though I was SSHed through (not to) the router. 

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: ICMP (match-any)
      252 packets, 28224 bytes
      5 minute offered rate 0 bps
      Match: access-group name ICMP
        252 packets, 28224 bytes
        5 minute rate 0 bps

    Class-map: TUNNEL (match-any)
      5 packets, 440 bytes
      5 minute offered rate 0 bps
      Match: protocol gre
        5 packets, 440 bytes
        5 minute rate 0 bps

    Class-map: SSH (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name SSH
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      547 packets, 46588 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

When I moved SSH above TUNNEL, it started incrementing as it should.  The best that I can tell is that both the original packet and the GRE packet are being evaluated when pre-classification is enabled.  Since all the packets in the lab are going over a GRE tunnel, GRE will always be matched if you assess before everything else.

For the record, I did this lab twice – once with the GRE tunnel encrypted and once without encryption.  The results of the pre-classification were the same in both attempts; GRE matches every time.

Send any ROUTE class vouchers questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website

• VPNs (Didn’t ISCW cover this?)
  • Provide
    • Confidentiality
    • Integrity
    • Authentication
  • Types
    • Remote-access
      • Client-initiated
      • NAS-initiated
    • Site-to-site
      • LAN-to-LAN
      • Extranet
• L3 Tunneling protocols
  • GRE
  • IPSec
• Pre-classify allows traffic to be classified before being sent across a tunnel or crypto-ed.
  • qos pre-classify
  • Provides a view into the original IP headers
  • To classify on pre-tunnel header, apply the policy to the tunnel interface WITHOUT pre-classify.
  • To classify on post-tunnel header, apply the policy to the physical interface WITHOUT pre-classify.
  • To classify on pre-tunnel header, apply the policy to the physical interface WITH pre-classify.
• SLA – agreement with provider to guarantee QoS mechanisms across their network based on your markings.
  • Assures availability, loss, throughput, delay, and jitter.
• End-to-end QoS
  • To be effective, each hop in the path must have QoS configured similarly.
  • Necessary in three locations
    • Campus – within the customer network
    • The edges – customer facing the provider, provider facing customer
    • On the provider network
• QoS tasks
  • Campus access switches
    • Speed/duplex settings
    • Classification
    • Trust
    • Phone/access switch configs
    • Multiple queues on switch ports, including priority for VOIP
  • Campus distribution
    • L3 policing and marking
    • Multiple queues on switch ports, including priority for VOIP
    • WRED
  • WAN edge
    • SLA definitions
    • LLQ
    • LFI
    • WRED
    • Shaping
  • Provider cloud
    • Capacity planning
    • PHB
    • LLQ
    • WRED
• Enterprise campus QoS implementation
  • Implement multiple queues to avoid congestion
  • Assign VOIP and video to highest priority queue
  • Esablish trust boundaries
  • Use policing to rate-limit excess traffic
  • Use hardware QoS when possible
• Control Plane Policing (CoPP)
  • Applies QoS policy to traffic destined for the router
    • Routing protocols
    • Management protocols
  • Can be used to avoid DOS attacks
  • Applied to control-plane in global config

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

More Posts - Website