Now for the fun stuff.
I think this is the part I found most interesting while making this content.
We're going to look at routing policies.
These control, which routes are important to and exported from the routing table
as well as any extra attributes applied to them.
Just like any enterprise grade vendor,
you can manipulate routes and their attributes.
For example, the AC path and local preference in BGP
or the metric in open,
we can also filter routes that we're willing to accept
from neighbors called importing in Junos
as well as the routes we export to name is simply called exporting.
Speaking of exporting, we can export routes
from one routing protocol to another.
For example, we may learn routes from RIP
and then advertise them in Ospina.
You might know this under the name route redistribution.
In fact, we'll try exactly that in the lab on the website
in Junos.
All importing and exporting takes place from the viewpoint of the routing table.
It is core to all routing policies.
When neighbors send routes, they pass through an import policy
This may filter routes so they never end up in the routing table.
Or perhaps the policy will manipulate route settings like the metric
before they reach the routing table.
Once the routes make it into the routing table,
the best are selected to be placed in the forwarding table.
On the other side,
we can use policies to control which routes are advertised to neighbors.
We can also manipulate attributes at this point, too.
These policies are called export policies.
A route needs to be active in the routing table
before they can be evaluated by an export policy.
Juno's comes with a series of default routing policies
which control how routes are handled if we haven't configured our own.
In most cases, the rules are simple.
If a route is learned from one neighbor, advertise them to other neighbors.
However, there is a different default import
and export routing policy for each routing protocol
and sometimes the behavior is a bit surprising.
Here is a summary of the behavior of each routing protocol.
We're going to look at the basics of how these protocols behave
and why
BGP is special, as it has a few additional
tables called rib in and rib out.
Rib In contains all the prefixes that have been learned from peers
these prefixes then pass through a route policy
where they're filtered in, modified as needed.
The surviving prefixes are then added into the INET zero or on at 60 routing table.
The default import routing policy is to accept all prefixes
without modification and install them into the routing table.
The same concept works for about an export policy.
Will select routes from the routing table, apply any necessary modifications
and put the resulting prefixes in, rip out anything and rip out.
We then shared with peers
the default BGP export policy accepts
all active prefixes into rip out without modification.
The details of ISIS are a bit beyond the scope of this series.
So for now, think of ISIS as a routing protocol
that behaves in a very similar way to OSPITE.
These protocols use a link state database
to build a view of the entire network area,
which is built by flooding LSA messages between neighbors.
All neighbors must have identical copies of the LSB.
The default
import policy is to accept all routes and import them into the routing table.
This policy can't be overridden because the SDB should never be fielded
or changed.
To do so would mean that neighbors would not have identical databases.
The default export policy is to reject all routes.
Sounds crazy, right?
But when you think about it, it's really not.
Neighbors share rounds by flying LSA messages,
which comes out of the SDB not the routing table.
So an export policy is not required.
Remember in Junos routing
policies, a routing table centric
he's one that's a bit wild.
The default rip import policy will accept all routes
and install them into the routing table.
However, the default export policy is to reject everything.
This means that a route learned from one rip neighbor will not be advertised to
another rip neighbor.
Once again, this sounds crazy,
but this really shows two things about Juniper.
One is a low opinion of RIP, which I think most network engineers will agree with.
And the second is Juniper's history in the service provider market
riff was never used much by service providers.
But although I can think of a case where it definitely was
so, Juniper never had much use for it.
However, if we really want to use RIP,
we can create our own policy to override this behavior.
To start with, I found this to be one of the trickiest
concepts to get my head around, especially around export
policies for OSP and ISIS.
So take your time on this and remember
to think about it from the perspective of the routing table.
Let's put all of this into action.
We're going to use route policies to advertise static routes into open
the route away.
Using is called R one, and it already has a few opf neighbors.
There are also a few active static routes in the routing table.
So how do you think we can add these into our spam?
We need to use an export policy.
This is because we're exporting routes from the routing table into our SPF.
So step one is to create a policy statement under the policy options
hierarchy.
Each policy statement needs a name,
so we'll call ours opf export.
Remember a few years ago when we looked at firewall filters?
Well, I hope you're paying attention because firewall filters
are used in the configuration of routing policies.
We'll start by creating a term called redistribute static
Technically, we can have a single unnamed term if we want,
but for organization and troubleshooting, I prefer to name all my terms.
Next, we need to match conditions with the from statement.
The first condition we're interested in is the protocol type.
We only want to match static roots
to be a bit more specific We will limit our matching
to only 121682540 24.
There are two ways we could do this.
One is called a root filter, and the other is a prefix list.
A prefix list is defined separately, contains groups of networks,
and can be reused in other policies.
Round filters are defined inside the policy and have advanced
matching options.
So we'll use a root filter.
Include the subnet
if I use the question mark now you can see the additional matching options.
We can match
several networks with longer or the all longer statements.
We only want to match one network so exact fits our needs.
If we want to, we can also apply an action on the very same line
when we're using a root filter.
Try playing with this in the lab if you can.
And finally, we set our action with the
then statement
the second half to this process is applying
the policy we're exporting from the routing table to our SPF.
So we apply this policy to our SPF
as an export policy
just for interest sake.
It's also possible to apply an export policy to the forwarding table to
these controls, which routes are exported from the routing table
to the forwarding table.
Let's take a look to see if this worked
over on radar, too.
We can confirm that we have learned this route through SPF
as these one originated in our SPF, they listed as external routes.
There are two types of external routes called Type one and type two.
Type two is the default,
the two types of routes referred to how cost or metric
is calculated for this route.
When we redistribute a route, it's given a cost.
For example, it may have cost of ten
when the type two route is being shared with neighbors.
The cost does not change
when a type of one route is being shared with neighbors.
The original cost is added to the cost of any links between the neighbors.
This means that the cost to reach the route increases with each hop.
As you can see, the route we redistributed is a type two route.
With that
in mind, let's take this a step further and edit our policy to also redistribute
1921682530 as I type one around.
To do this, we're creating a new term
called Redistribute Static E one.
Remember that terms are evaluated in the order they're entered.
So this will be evaluated.
After the term we've already created
just as before, we're going to match static roots
and use a root filter to match 192168253.3 slash 24.
Just for fun.
We're using all longer this time.
The real difference is with the action.
In fact, we need two actions.
The first being set the external type to one.
The second as before is to accept
moving over to R2.
Now we can see that OPF is loading this route as well.
Digging into the DB,
we can see that this has been learned as a type one route
Think back to the policy that we created for a moment.
We have two terms and they're evaluated
in the order that they're listed in the config.
What if we want to change the order?
Do we have to reconfigure the policy from scratch?
Fortunately, no, although that would work.
There is a better way It's quite simple.
We edit the policy and then we use insert to move our second term
before our first term
You can see now that this has been recorded.
One more trick before we finish up.
If we're redistributing static roots with a policy.
We may find that new study groups that we create
are automatically redistributed to.
It all depends on how we can figure out policy, of course,
but there are times when we definitely don't want this to happen.
One option is to reconfigure a policy to somehow prevent
the static rout from being matched, but that can be a bit tricky.
A better way is to configure a static route with the no advertised keyword.
At the end, there simply prevents the static route from being redistributed
into a dynamic routing protocol.
Over an hour or two.
We can see that this particular route is no longer learned through OPM
For more questions for you to try,
I suggest paying special attention to question number nine.
We should be pretty comfortable with routing concepts now,
but have you looked into the concept of multiple routing tables?
You may have heard of this by the name VRM Flight.
Juniper's version called Routing Instances is a topic of our next video.