How to Configure Routing Policies that Advertise Routes in Junos

By Walter J. Goralski, Cathy Gadecki, Michael Bushong

In the Junos OS, getting BGP routes into the routing table is a matter of advertising. The default behavior of BGP is to accept all loop-free routes learned via BGP. You must configure routing policies to make sure that these routes are propagated through the network.

image0.jpg

Each link in the topology is a subnet to which the routers are connected. These subnets are included in the route table as static routes (direct routes, to be more precise). If you can advertise those subnets to your internal neighbors, you’ll have BGP routes to all your internal peers.

Configuring routing policy requires the definition of the policy and the application of that policy on either the inbound (import) control traffic or the outbound (export) control traffic.

In this case, you want to include static routes, so you use the accept action. This policy is named ibgp-export and has one term, export-statics, that advertises all static addresses with BGP:

[edit policy-options]
policy-statement ibgp-export {
  term export-statics {
   from protocol static;
   then accept;
  }
}

In this routing policy, you accept all routes that are static. Whether you accept them as you receive protocol control traffic or include them in your outbound protocol control traffic depends on where you apply the policy. In this example, you include the routes in your outbound BGP advertisements, so you need to apply the policy as an export policy for your IBGP group:

[edit protocols]
bgp {
  group my-guys {
   type internal;
   export ibgp-export;
   neighbor 192.168.14.1;
   neighbor 192.168.14.2;
   neighbor 192.168.14.4;
  }
}

Issuing a show route command reveals that BGP routes are now in the routing table:

user@router2> show route
inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.14.1/24  *[BGP/100] 6w0d 01:56:10
to 192.168.14.3 via fe-0/0/0.0
192.168.14.2/24  *[BGP/100] 6w0d 01:56:10
to 192.168.14.3 via fe-0/0/0.0
192.168.14.4/24  *[BGP/100] 6w0d 01:56:10
to 192.168.14.3 via fe-0/0/0.0
192.168.64.0/21  *[Direct/0] 6w0d 02:03:45
via fxp0.0
192.168.71.246/32 *[Local/0] 6w0d 02:03:45
Local via fxp0.0
192.168.102.0/23  *[BGP/100] 6w0d 02:03:45
to 192.168.71.254 via fxp0.0
207.17.136.0/24  *[Static/5] 6w0d 02:03:45
to 192.168.71.254 via fxp0.0
207.17.136.192/32 *[Static/5] 6w0d 01:56:10
to 192.168.71.254 via fxp0.0
…

You can identify the BGP routes by the content within brackets. Bracketed content indicates how the route was learned and specifies the local preference.

The local preference is used to choose among routes to the same destination prefix. Lowest value wins, so (for example) a static route next hop (local preference 5) is used instead of a BGP (100) next hop (in some cases they share the same next hop, but that is not always true).

The local preference is used to decide which route to use if there are two routes to the same destination. For example, if a static route has a local preference of 5, and BGP has a local preference of 100, the router will use the static route because of the higher preference value (lower number).

After configuring the routing policy for your IBGP routers, you must configure the policy for your EBGP router. As it turns out, you can use a very similar policy and apply it on your external group:

[edit policy-options]
policy-statement ebgp-export {
  term export-statics {
  from protocol static;
  then accept;
  }
}

Now apply it to your external group:

[edit protocols]
bgp {
  group those-guys {
   type external;
   export ebgp-export;
   peer-as 65002;
   neighbor 10.0.26.2;
  }
}

The application of these two routing policies ensures that routes are shared within your IBGP mesh and that those routes will not be leaked via the EBGP connection between autonomous systems (AS), which is important because you don’t want to flood (or, by extension, be flooded by) internal routes into a neighboring network.

Issuing a show route protocol bgp command on each of the routers should reveal that only the expected routes are included in the route tables.

Consider setting up an aggregate route to represent your entire set of addresses. For example, if you have a lot of contiguous 192.168.x/24 addresses, configure an aggregate route and filter those routes.