Understanding the JunOS routing table

January 18, 2019 11:38 am in Juniper | No comments

I was just about to finish another blog post on MPLS when I got a question from a colleague about Junos routing tables. He was confused as to how to interpret the output of a basic Juniper routing table. I spent some time trying to find some resource to point him at – and was amazed at how hard it was to find anything that answered his questions specifically. Sure, there are lots of blogs and articles that explain RIB/FIB separation, but I couldn’t find any that backed it up with examples and the level of detail he was looking for. So while this is not meant to be exhaustive – I hope it might provide you some details about how to interpret the output of some of the more popular show commands. This might be especially relevant for those of you who might be coming from more of a Cisco background (like myself a number of years ago) as there are significant differences between the two vendors in this area.

Let’s start with a basic lab that looks a lot like the one I’ve been using in the previous MPLS posts…

For the sake of focusing on the real topic of this post, I’m not going to dive into the base configuration but beyond configuring the IP address on the interfaces shown on the diagram, the base configuration includes enabling all interfaces (loopbacks too) with OSPF. So let’s begin by looking at the output of vMX1’s global (inet.0) routing table…

This looks largely like I think most of us would expect it to. OSPF has done it’s work and found paths to all of the routers loopback addresses. In the case of 3.3.3.3 it’s found that it has an equal cost path through both vMX2 and vMX3. This all seems to add up and I don’t think anything above should be that shocking to anyone. But what about that >?

Thinking about this logically – I think there are two likely scenarios for what the > means. First – one might assume that since the > is next to the path through vMX1 that this path has been selected by the router as it’s means to reach 3.3.3.3. In this case, I would also assume that all traffic toward 3.3.3.3 would use this path. The second possibility, and the one that folks more familiar with Cisco might lean toward, is that the router will use some type of load balancing mechanism to send traffic over both paths. While these both seem like reasonable assertions to make – the use of the > doesn’t really make sense in scenario 2. I’ll also add that none of this is helped by the fact that the output doesn’t describe what > means. So let’s dig in deeper to see what the router is doing.

The output above showed us what the router is thinking, and while this is good information to have, it doesn’t tell us exactly how it will behave when trying to reach 3.3.3.3 (ah yes – the classic Control versus Data plane discussion). To see what’s going on in the data plane, we can use the show router forwarding-table command…

Whew – that was a long command. Note that everything after forwarding-table is there strictly to limit the output we’re seeing (also note that you need to define a family before you define a table to look at). So in this case – things seem to be as we expected in scenario 1. The router has picked one path it would like to use to reach 3.3.3.3 and has programmed the data plane to send packets in the direction of vMX2 to reach 3.3.3.3.

So then why does the routing table list both possible paths to reach 3.3.3.3 that it learned through OSPF? And what does the > actually mean? And why can’t the router use both paths?

This is where things can get a little deceiving. By default, JunOS won’t program the data plane to use more than one path until you tell it to. To do this, we tell the chassis to perform “per-packet load balancing”. On JunOS, this equates to what other vendors typically call “per-flow” load balancing. To configure it, we create a policy and then attach it to the forwarding table using an export command. The configuration would look like this…

Once applied, let’s look at our routing table one more time…

Hmmmm. Nothing has changed. Let’s look at the forwarding table…

Aha! It did change something. So this is what can be confusing. Based on our first experiment, it sure looked like the forwarding table was based off of what we saw in the routing table. Heck, the > even lined up with the route that was selected for the forwarding table. But now we have a discrepancy. JunOS has perhaps the best separation I’ve seen of control and data plane. The RE (which is what you’re talking to when you’re doing all of this) has all of the facts and is making the assessment as to what the best way is to reach destination prefixes. When it comes time to actually program the forwarding engine(s) – it uses this data – along with your ECMP configuration (the per-packet config we did above). So yes, what you see in the routing table can be a bit deceiving, and if in doubt, you should always check the forwarding table.

Let’s dig in a little deeper now by adding some static routes and see how that impacts things. Let’s configure the following static route on vMX1…

We’re now telling the router that it has a static router to 3.3.3.3 through the same paths that it previously had OSPF paths to reach the same destination. Let’s look at the routing table now…

So now we have the static routes AND the OSPF routes. What can this possibly mean? I’ll start by saying that once you get used to this output, you’ll learn to love it. What JunOS does is show you all of the possible means and paths to reach a given prefix. In this case, it has both OSPF based paths and paths based on the static routes that we just added. I like to think of this output in terms of protocols, paths, and next-hops….

When I look at the routing table this is how I perceive this output. You might be wondering why Im referring to a the larger blocks as protocols and paths. Hold that thought for now as we’ll see with BGP this behavior is slightly different. So in the above output the active path is the static path which has two next-hops – one to 10.1.1.1 and one to 10.1.1.7.

So why do we see all 4 possible next hops from both protocols? Does it mean that it’s using all four? Certainly not – things like administrative distance still apply and you can tell that the router has selected the static routes to use based on the * next to the protocol Static. The * is important as it tells you what the active path is for a given destination prefix.

Seeing all of the possible paths in the routing table is just JunOS telling you about all the reachability information for a given prefix from all possible sources. On most Cisco platforms, the routing table only shows you the one that was selected for forwarding. What I like about the JunOS approach is that I can see all the options available to reach a given prefix (as well as which one was picked) all in one command.

By now you’re probably still curious about this > symbol. We now see it under both the static path and the OSPF path. What does this indicate? The > indicates the “selected” path. Let’s look at the route output in more detail so you can see what I’m talking about…

So we can see that the > matches up with the selected statement on each routing entry. Selected routes are just the best route out of all possible routes in a given path. Again – this is really only relevant if we remove our ECMP configuration so that the router was only sending traffic toward a single next hop. For OSPF, since the paths are equal cost, the lower RID wins as we can see that’s the selected route within the OSPF path. With static routes that are of equal cost – the router randomly picks one (I thought for sure there’d be some method to this but Juniper docs say otherwise).

To show one last variation in routing table output – let’s now add in BGP so we can see what that looks like in the routing table…

Note that the router already has some base configuration (namely a router-ID that matches the router’s loopback address)

vMX1 configuration…

vMX2 configuration…

vMX3 configuration…

vMX4 configuration…

The above configuration simply configured all other routers as iBGP peers and configured a basic export policy that advertises both connected and static routes. After applying this configuration, let’s look at the routing table on vMX1 again for the 3.3.3.3 prefix…

So continuing our theme we now have all 3 protocols listed (3 paths) as having reachability to 3.3.3.3. Note that the static route path still has the * by it indicating it’s the preferred path because of it’s AD. Note that the BGP path is listing a next hop both through vMX2 and vMX4. It’s important to clarify that this is next hop reachability for the source of the advertisement 3.3.3.3. One of the things that often get’s people hung up is the difference between ECMP and BGP multipath. For instance, Juniper routers by default do not enable BGP multipath for eBGP or iBGP sessions. Looking at the above output might make you question that – but also remember that this is an iBGP configuration. That is – I’m only learning about 3.3.3.3 from one place and that’s 3.3.3.3 itself. iBGP peers do not share advertisements they learn with other iBGP peers because iBGP assumes a full mesh. That being the case – there isn’t even a need for BGP multipath because I only have one BGP path to reach the destination. I do however, have multiple IGP (and static too) paths to reach the router advertising 3.3.3.3.

Now let’s add multipath so you can see what I’m talking about. On vMX[2-4] add the following static route configuration…

Now let’s see what vMX1 has in it’s routing table for that prefix….

Excellent! Now you can see that the JunOS routing table maintains a path per BGP peer. We can see that the BGP path from 3.3.3.3 is preferred (and has multiple IGP routes available) but we also see the other paths from vMX2 and vMX4. Care to guess why the path from vMX3 is preferred?

We still have those static routes in for 3.3.3.3 and JunOS is preferring the lower IGP metric when it picks the active path. If we remove those static routes, we’ll see that JunOS will fall back to selecting the route with the lowest RID. Let’s remove those statics to validate that assumption…

Yep! The path from 2.2.2.2 to reach 9.9.9.9 is now preferred. So now what about multipath? If we look in the forwarding table for 9.9.9.9/32 we’ll see what we expect – a single entry pointing to 10.1.1.1…

So not let’s enable BGP multipath on vMX1…

And now if we look at the routing table we should see something much more interesting…

Notice how the active path now has routes for both the next-hop to vMX2 and vMX4. What’s happening here is the router is saying that it can use both the paths to vMX2 and vMX4 to reach 9.9.9.9/32. The forwarding table would shows a similar story…

The key here is that JunOS is copying other equal cost next-hops from other paths into the active path. This may be more clear if we slightly modify the lab to include a link between vMX1 and vMX4.

With that link in place (and configured for OSPF and BGP peerings between vMX1 and vMX4) our routing table now looks like this…

You can more clearly see now that each of the other non-selected paths has copied it’s next-hop into the active path to be used for forwarding…

So there you have it – a quick intro into JunOS routing table entries. I hope you found this useful!

MPLS 101 – MPLS VPNs

April 10, 2018 6:47 pm in Juniper, MPLS | 1 comment

In our last post, we removed our last piece of static configuration and replaced static routes with BGP.  We’re going to pick up right where we left off and discuss another use case for MPLS – MPLS VPNs.  Really – we’re talking about two different things here.  The first is BGP VPNv4 address families used for route advertisement.  The second is using MPLS as a data plane to reach the prefixes being announced by VPNv4 address family.  If that doesn’t make sense yet – don’t worry – it will be pretty clear by the end of the post.  So as usual – let’s jump right into this and talk about our lab setup.

As I mentioned in the last post, setting up BGP was a prerequisite to this post – so since that’s the case – Im going to pick up right where I left off.  So I’ll post the lab topology picture here for the sake of posting a lab topology – but if you want to get your configuration prepped – take a look at the last post.  At the end of the last post we had our two clients talking to one another using MPLS as the data plane forwarding mechanism and BGP as the route or prefix advertisement mechanism.

To do this – we peered router 1 to router 4 with BGP and let them advertise the directly connected prefixes that met a prefix-list based filter.  This worked great and removed the need for us to use static routes to force a recursive routing lookup into the inet.3 table so that we could use MPLS labels for forwarding.  But now what happens if we want to support more than one tenant?  Let’s say that Im running an ISP and I want to provide connectivity between different endpoints in the network for different tenants.  And what if those tenants use the same IP networks?  The only way to solve that problem is to provide a means of layer 3 isolation on my network so each tenant can stay isolated.  So in our example above, let’s say that client 1 and client 2 are members of company ABC and we’re tasked with providing them an isolated path across my amazing 4 router backbone network.  To do this, there are 2 main problems we have to solve.

  • Distributed L3 Isolation – How do we extend that isolation across the backbone so that company ABC can reach all of their locations?
  • Local L3 Isolation – How do we provide local isolation on the router where the client enters the backbone?

So let’s tackle these problems one at a time.

Distributed L3 isolation

Up until now we’ve been using the default or global table on each router to provide routing functionality.  If we look at the routing-table on the router 1 we’ll see all of the OSPF based loopback addresses as well as the remote BGP prefix we learned from router 4…

Bottom line – we’re dealing with a common routing table. To provide isolation, we’ll need to fix this. So the first thing we need to do is figure out how we do this with BGP. At the moment, BGP is talking between router 1 and router 4 in the default or global table. Prefixes it advertises to other peers live here and prefixes it learns land here. So let’s back up a second. We know that we want to support multiple customers – and those customers could use the same prefixes – so how can we possibly have BGP advertising the same prefixes for different customers? The answer comes in the form of VPNv4 prefixes. You see – to make a routing advertisement unique, VPNv4 prefixes just add additional distinguishing information onto a route advertisement. This distinguishing information is aptly called a “route distinguisher” or more commonly just an “RD”. And RD is a 64 bit value that prefaces a customers routing advertisement. For instance…

You can see above that to make a standard prefix a VPNv4 prefix we simply preface it with an RD. That RD can come in three different forms…

The form you use doesn’t matter much but you should use the same form for consistency sake. So now the question becomes, how do we get BGP to send and understand VPNv4 prefixes? To do that, we need to activate a new address family – VPNv4. This is easy to do, we simply enable the inet-vpn family under the ibgp group we created earlier…

Let’s add the same change to router 4 as well – set protocols bgp group ibgp family inet-vpn unicast

So now what?  Surprisingly, that’s sort of it.  Feel like you missed something?  Don’t worry!  It will all come together soon, but we need to tackle the next task of providing local L3 isolation before we can see any real progress.  So let’s get that out of the way and then see where we stand.

Local L3 Isolation

Providing local layer 3 isolation on a router is pretty simple thing to do in most cases.  Both Juniper and Cisco allow you to define VRF (Virtual Routing and Forwarding) instances which create isolated routing tables.  You can then add interfaces from the router/switch into a given VRF.  By default, all interfaces live in the default (sometimes called global) routing table.  Moving them to a VRF removes them from the default routing table and places them in the VRF’s routing table.  Let’s take a look at what it would take to add a Company ABC VRF on router 1 and 4 so I can show you what I mean.

Even in this mode, where we are just defining local VRFs (sometimes called VRF-lite mode), there are some differences in how you define them between Juniper and Cisco.  In Cisco – a VRF is a VRF regardless if you’re using it locally or intend to use it in conjunction with something like MPLS and VPNv4.  On a Juniper, there are two routing-instance types for VRFs.  One for VRF-lite mode and one for using VRFs in conjunction with VPNv4…

The two we’re going to concern ourselves with are types virtual-router and vrf. virtual-router defines the VRF-lite mode where the VRF is only local to the box. Since we know we want distributed isolation, we’re going to need to use the vrf instance type. Let me show you why. Here’s the definition of a simple routing-instance…

Notice that the definition is incredibly simple. We define the name, the type, and the interface we want in it. This configuration is valid and passes a commit check. Let’s commit it and take a quick look around…

Once committed – we can see that we now have a new routing table on the router named company_abc.inet.0. That routing table has the prefixes associated with ge-0/0/0 in it. So if we look at the global or default routing table, we’ll notice these are now gone…

So this means that any traffic that comes into this IP interface on this router will be only allowed to talk other prefixes in this table. At this point – there aren’t any.  So how do we get some?  BGP and it’s VPNv4 route advertisements to the rescue!

In the last section, we talked about the need for VPNv4 routes, and we learned how to enable them in BGP, but we didnt really define any.  That’s because RD’s are defined as part of a routing-instance.  Here’s where we’ll see the difference between the virtual-router and the vrf instance type with Juniper.  If we try to define an RD in our existing routing-instance, we’ll see this…

So as it turns out we need to use the vrf instance-type in order to define an RD.  So let’s change our configuration to look like this…

Notice we changed the type to vrf and added a route-distinguisher of 65000:150.  Now if we try and commit this we’ll see…

So now it also wants a route target. What’s that all about?  I mean – we already made the routes unique by tacking on an RD.  So what purpose does a route-target serve?  Route targets (known as RTs) are what is actually used to make policy decisions about a prefix.  Whereas RDs serve only to make a quote unique – RTs are the gate keepers to a VRF and what the router uses to decide what route advertisements can/should go where.  What often confuses people is that the definition of an RT and RD can be identical if you wish. For the sake of this lab we’ll make them different but do note that they follow the same type definition/format as RDs as we showed in the earlier section. So let’s add an RT to our definition…

Once again – let’s now make the same similar changes on router 4 (I’ll provide these in set syntax so you can see the actual commands I used)…

Note that in my lab the customer facing interface for client 1 and client 2 differs so you can’t copy and paste this configuration to both routers without changing the interface. 

So now that this is all in place – we can do some validation.  Let’s start on router 1…

Notice that under the peer4.4.4.4 we now see the additional bgp.l3vpn.0 family.  The fact that its listed under the peer tells us that router 1 has negotiated this functionality with router 4.  In other words – they’re talking VPNv4 at this point.  We can also see what prefixes are being advertised by router 1…

Above we can see that for the BGP peering to router 4 (4.4.4.4) router 1 lists the 10.2.2.0/31 prefix as part of the company_abc.inet.0 table.  However – notice that the next-hop of this prefix is listed as Not Advertised.  We can confirm that this is not being advertised by running a similar command on router 4…

We can see here that router 4 is not receiving any prefixes from router 1 (1.1.1.1). So what’s going on? Shouldn’t this all work? Let’s take a closer look at the advertised routes on router 1 by tacking on the extensive keyword to the advertised routes command…

Huh – So its saying that it failed to allocate a next-hop address on LAN. What does that mean?  Let’s take a step back and talk about what’s going on right now and see if we can sort this out.

We mentioned earlier that there were two separate goals here.  One was to enable Distributed L3 isolation across our MPLS cloud and the second was to do it locally on each router that clients connect to.  We talked about how to enable BGP to advertise unique prefixes per customer (or VPN) but we didn’t talk about how that ties into MPLS to make a working data plane.  So how does this all work together?  The answer comes in the form of a label stack.  Let’s talk through what we think should be happening and then see if we can validate this in the lab.

So the first thing we need to know is that MPLS labels can be stacked.  In all of our previous posts, there was a single MPLS label and it was swapped at each MPLS hop.  This is how MPLS forwards traffic.  Adding more than one label opens up some interesting possibilities in terms of applications.  In the case of VPNv4 route advertisements, it means I can tell remote peers about an additional label.  So let’s walk through how this might work…

The picture above shows two label advertisements.  The first is the LDP label advertisement shown with the blue arrows.  As we saw in the post on LDP this label distribution occurs hop by hop and each label is locally significant.  In this case, router 4 is telling router 3 – “If you want to get to an LSP that ends at me (4.4.4.4) send me a frame with a top label of 3”.  Router 3 records that request in it’s local label database – and then tells it’s other LDP peers about this.  Router 3 tells router 2 – “If you want to get to an LSP that ends at router 4 send me a frame with the top label of 299808”.  And finally – router 2 tells router 1 – “If you want to get to an LSP that ends at router 4 send me a frame with the top label of 299936”.  This is how LDP works and it’s well described in the earlier post.  What’s new is the green line shown above.  This is a label allocated and learned by BGP and advertised to all VPNv4 capable BGP peers.  So how does this new label work?

  • When the top client wants to talk to the bottom client it will send traffic to router 1.  That interface is part of a local VRF (company_abc VRF) on the router and that VRF has an associated RD and RT.
  • Router 1 will do a route lookup in the company_abc routing table and see if it has a matching destination prefix for the traffic.  In this case, it would have learned the prefix 10.2.2.2/31 through BGP (specifically through the BGP VPNv4 advertisements).  If we examine that advertisement sent by router 4 for 10.2.2.2/31 we should see that the advertisement includes a VPN label. 
  • This VPN label will be pushed onto the frames label stack first.  Since the LSP for this traffic still ends at router 4 – the LDP based label will then also be pushed on the label stack. 
  • When router 2 receives the MPLS frame, it will only process the top label leaving the bottom label (the VPN label in this case) intact.  Router 2 will process the frame, swap the top label, and send it on it’s way. 
  • Each subsequent MPLS hop will do the same thing only dealing with the top label

The flow looks like this…

Pretty slick huh?  Notice that since router 4 had sent router 3 the label of 3 (Implicit Null) to reach 4.4.4.4 router 3 has obliged and popped the top label off of the stack.  In a scenario without MPLS VPNs, this would mean that router 4 would receive a native Ethernet frame and IP packet.  However – even after popping the top label we still have the VPN label to contend with.  This puts us in a little bit of a unique scenario and helps describe why things aren’t currently working.  In a typical MPLS configuration, the clients would more likely be CE or Customer Edge routers.  Router 1 and router 4 would be serving as PEs or Provider Edge routers.  In that scenario it is almost guaranteed that router 1 and router 4 would be routing to reach remote prefixes.  That is the link between the PE and the CE would be a transit network and the PE would be learning prefixes over some sort of dynamic routing protocol from the CE.  In that scenario, JunOS can advertise a label for each potential next hop address it needs to talk to.  That means when it receives a frame with a VPNv4 label it can directly translate this to a next hop and forward the packet.  In our case – the destinations are directly attached to a multi-access network.  This means that the next-hop is not well known and that the router will need to perform normal ARP discovery to find the MAC address for the destination.  So rather than a label to next hop direct mapping, we’re asking the router to perform two different actions when it receives a VPNv4 labelled frame.  First it has to use the VPN label to determine what VRF the traffic should land in – then it needs to ARP to find the destination.  That is why this is currently not working – the routers recognize that this is a problem and therefore wont allocate a VPNv4 label for the customer prefix.  Hence the message Need a nexthop address on LAN.  There are a couple of ways to solve this and this Juniper article does a good job explaining them.  In our case, we’re going to use the vrf-table-label command to fix this.  In addition to changing the label allocation method for VPNv4 prefixes – this also allows traffic to be recirculated on the router so that the VPN label can be popped and the ARP process can happen.  So let’s add the following configuration to router 1 and router 4…

Now if we try to ping client 1 from client 2 – we should see it’s working as expected…

Let’s look at what’s happening in more detail…

Notice that router 1 now shows it is advertising the prefix to router 4. Also note that it’s allocated a VPN label of 16 to use for this VRF.  The other impact that vrf-table-label has is that it allocates a single label for all prefixes for a given VRF (which makes way more sense given the command you entered).  So that means that all prefixes on router 1 that are a part of company_abc VRF will be advertised with a label of 16 to router 4.  Let’s look and see what we learned from router 4…

Here we can see that to reach the network 10.2.2.2/31 router 1 believes it should impose a bottom label of 16 and a top label of 299936.  Just like we expected it would!  Let’s verify that 16 is in fact the VPN label that router 4 sent to router 1….

Note: This can be the confusing things about small MPLS labs.  Often times, the same label is allocated on different boxes.  In our case – both router 1 and router 4 allocated a per VRF label of 16 for company_abc VRFs.  

Lots of interesting information here.  In the top highlighted section we can see that the company_abc routing table did receive an entry for 10.2.2.2/31 with a VPN label of 16, an RD of 65000:150, and next hop of router 4 (4.4.4.4).  Notice that the RT is listed as a community on that advertisement.  Recall that the RT is how we define routing policy in terms of what we import and export into a VRF.  At this point – since we haven’t applied any import or export policy for the VRF – JunOS will happily receive and advertise all advertisements in a given VRF.  We’ll look at this more in a later post.

The second highlighted section show the entry in the bgp.l3vpn.0 table.  This table stores all VPNv4 advertisements received by the router.  In a later post where we look at having multiple customers on the same MPLS backbone we’ll see that all of their advertisements land in this table before specific entries make it into the customer specific VRF tables.  So I think we can safely update our digram to look like this…

Last but not least, lets do some packet captures to validate this is actually whats hitting the wire…

ICMP echo request on the wire between routers 1 and 2…

ICMP echo request on the wire between routers 2 and 3…

ICMP echo request on the wire between routers 3 and 4…

The capture confirms the flow we described in the diagram perfectly!  In the above captures – the first label listed (top down) is the top label.  You can also tell that the VPN label of 16 is the bottom label since that label has the bottom of the label stack bit set to 1.  Notice that in the capture between router 3 and 4 we only have one label.  Recall that router 4 is asking router 3 to perform PHP to remove the LDP label before forwarding it the frame.

This has been a warp speed tour of MPLS VPNs and we relied on lots of the default functionality to make this work.  In the next post, I hope to cover more specifics about VRF import and export based on the RTs.  Stay tuned!

MPLS 101 – Dynamic routing with BGP

April 3, 2018 6:17 pm in Juniper, MPLS | 1 comment

In our last post we talked about how to make the MPLS control plane more dynamic by getting rid of static LSPs and adding in LDP to help advertise and distribute LSPs to all MPLS speaking routers.  However – even once got LDP up and running, we still had to tell the routers to use a given LSP.  In the last post, we accomplished this by adding recursive static routes in the inet.0 table to force the routers to recurse to the inet.3 table where the MPLS LSPs lived.  In this post, we’re going to tackle getting rid of the static routes and focus on replacing it with a dynamic routing protocol – BGP.

So to start off with, let’s get our lab back to a place where we can start.  To do that, we’re going to load the following configuration on each router show in the following lab topology…

You’ll notice that these base configurations include configuration for not only the interfaces, but also OSPF, LDP, and MPLS.  Basically we’ve configured everything we had in the last post with the exception of the static routes.  At this point, client 1 and client 2 will not be able to communicate to one another.  So let’s now look at how we configure BGP.

You might recall that I mentioned in a previous post that BGP was interesting in the regard that it could list a next hop for a destination prefix that was not directly connected to the router.  This is because BGP can leverage recursion which is exactly what we had been doing with the static routes in the previous two posts.  So let’s go ahead and setup a BGP peering to try and replace what we leveraged with static routes previously.  The first thing we need to do is define what our BGP peers will be and in what AS (autonomous system) they each reside in.  In our case, to keep things simple initially, we’re going to put all of our peers in the same AS (65000) for now.  As for the peers, we’re going to peer router 1 to router 4.  You might be wondering why we aren’t peering routers 2 and 3 with anything.  Recall that those are MPLS P routers and don’t require any knowledge of the actual prefixes they are passing traffic for.

If you’re familiar with BGP, then there shouldn’t be anything terribly new for you here.  Juniper configuration breaks the configuration into groups.  In my case, I have a single group called ibgp in which I define the type of peering that Im working with internal as well as my neighbor, the local address I want to talk to that neighbor on, and the peer autonomous system.  Juniper also breaks out the AS and router-id into the routing-options stanza which can take some getting used to if you’re used to working on other platforms.

Now that its configured, we should be able to check and see that we have a BGP peering between router 1 and router 4…

Looks like the peering is up as we can see in the Up/Dwn column that we list an up time and the state is not Active.  However – we dont appear to be getting any routes.  We can see that the number of received routes is still 0.  So why is that?  Well it’s because we haven’t told BGP about any of the routes.  To do that, we need to define a routing policy that we can then have BGP reference as an export policy.  Here are two basic policies that we’ll be using in this example…

If you’re not familiar with Juniper policies (terms, from, then, etc) I’d suggest you spend some time reading through the Juniper Day One: Configuring Junos Policy and Firewall Filters eBook.  It’s a great read and has lots of good examples.  While the logic may seem basic at first, I assure you that there are lots of places you can shoot yourself in the foot if you don’t understand the defaults and the means in which routers process policy.  So let’s walk through the above policy logic as applied on router 1 briefly…

  • We start with a policy-statement called mpls_bgp
    • This has a term defined in it called the routes_for_mplswhich defines two match criteria…
      • Routes that are from the protocol direct which are routes the router believes to be directly connected
      • Routes that match a route filter looking for the exact prefix 10.2.2.0/31
      • If the two above requirements are met, we proceed to the thenaction which is to accept or allow the advertisement.
    • If the above term is not matched, the policy has a default action to reject

Pretty straight forward right?  Then all we do is apply the routing-policy to the BGP process by tagging it as the export policy underneath the BGP protocol stanza.  If you’re following along and have applied the policy to both routers you should see that client 1 can now ping client 2 once again.  We can also do some validation on the routers to validate they have the appropriate prefixes…

First we look to ensure that we see the destination prefix that client 2 is a member of (10.2.2.2 /31) on router 1. We see that we do in fact have a routing entry for the 10.2.2.2/31 prefix and that it lists it coming from 4.4.4.4 (router 4).  We also see that recursion has occurred and router 1 has gleaned the MPLS information from the inet.3 table in order to know what MPLS label to push onto the traffic.  With that information, as well as the next-hop interface and IP to reach 4.4.4.4 from OSPF (10.1.1.1 and ge-0/0/1.0) we have all the information we need to send the traffic on its way towards client 2.  We can also validate that we’re advertising the 10.2.2.0/31 prefix to router 4 by using the advertising-protocol command syntax on router 1…

As before – the advantage here is that routers 2 and 3 have no idea about the prefixes which routers 1 and 4 are advertising to each other…

So at this point, the only thing we’d need to do is add any additional prefixes to the routing-policy in order to have BGP dynamically advertise them to the other BGP peer.  This doesn’t buy us too much in over what we had with static routes, but it does setup us up to talk about the topic for our next post – VPNv4 with MPLS.  Stay tuned!

« Older entries