Junos Routing Overview
RIP and BGP – both vector routing protocols. Routing by rumour, trusting that the routes it’s getting are good ones.
Same protocol behaviour / standards as cisco and linux.etc – defined by the RFC’s.
Using Juniper you can write import and export routing policies. That way if a route comes in (say though rip) before it is added to the routing table it can be checked against the policy. This policy can check and even modify the route.
Once the import policy has been actioned the route can be added to the routing table. If it’s the best path to a destination in comparison to other routes it’s pushed into the Forwarding Table. From the forwarding table it will be programmed down to the Packet Forwarding Engine (PFC).
If there is no export policy then it would pass the route on as normal. If there is an export policy, before any routes are passed on they must be checked against the policies rules in the same way as the import policy. This process is always top to bottom, and once it has been caught by a rule it will not proceed any further. Export policies can also be used to take one type of protocol and redistrubute it as another (e.g. a device learns a route through ospf, but the next hop doesn’t have ospf enabled so it sends it as a RIP route.)
Policy and Link State Protocols
Link state protocols, such as OSPF, are a little bit different. You can’t write policies in the same way you can with a vector routing protocol because every router must hold an identical copy of the link state database. There can be no variation in the information held in each of those link state databases.
There are some very hacky import policies that won’t be covered in the JNCIA – but they probably shouldn’t be used unless it’s really clever, don’t use in production.
We can still configure export policies for OSPF. We don’t need to do any policy configuration for OSPF to do its thing and send out Link State database updates to its neighbours. If we do configure an export policy that might check the routing table for things like static routes, routes from other non link state protocols. It can then map and inject those routes into its own Link-State database, which will then flood out to other ospf devices as ospf routes.
Routing Policy behaviour and actions
How to actually make a Routing policy.
e.g. Export Policy for OSPF
Apply the policy with: Set export genericName
Each policy contains a set of terms, and multiple policies can be applied to one protocol (but the order in which they are applied is important. – as with most things Juniper the application goes top to bottom and isn’t defined by priority number)
Terms basically work like simple if statements, so:
(if matches) protocol [static ospf]
(then) accept (and the process stops if it accepts or rejects)
(else carry onto the next condition)
Eventually if none of the terms match the route that comes in that accept or reject it, you get to the default behaviour depending on the routing protocol. The default behaviour varies so it’s best to capture as much as you can in the policy. (see below for defaults)
Matching Conditions:
-Protocol (e.g. from protocol static)
-IP Range (e.g. from route-filter 10/8)
-Prefix lists (prefix-lists NAME)
-Other attributes (NH IP, AREA, Community)
Note: Matching conditions can also be combined, but it should always go from most to least specific, since the process stops when a match is made.
Actions that can be taken when a condition is met:
-Accept
-Reject
-modify (Preference, NH IP, AS-PATH)
-next-policy (lets you skip from wherever you are in one policy to the next)
Default Policy Actions
| Protocol | Import Policy | Export Policy |
| BGP | Accept all valid BGP routes and import into inet.0 | Accept and advertise all active BGP routes. |
| OSPF | Accept all OSPF routes into inet.0 from LSDB SPF Calc | Reject All (OSPF interface addresses advertised) |
| IS-IS | Accept all IS-IS SPF routes into inet.0 from LSDB SPF Calc | Reject All (IS-IS itnerface addresses advertised) |
| RIP | Accept all valid RIP routes from explicitly configured nbr’s into inet.0 | Reject everything. |
Syntax example (taken straight from the training material):
user@juniperdevice edit policy options
[edit policy-options]
user@juniperdevice# show
policy-statement EXP_EXAMPLE {
term OSPF_OR_STATIC_RFC1918 {
from {
route filter 172.16.0.0/12 orlonger;
route filter 192.168.0.0/16 orlonger;
route filter 10.0.0.0/8 orlonger;
protocol [static ospf];
}
then reject;
}
term catch-all {
then accept;
}
}
I don’t really understand the logic from the training here, it says the protocol and route filters are a logical and, but as far as I can tell it would be more like logical XOR’s and a logical OR? (below) – Will have to do some labbing and check. (unless criteria with the same type are always or’s and everything else is an and?)
Matching Address Space: Route Filters
I’m getting lazier with these notes, but really this picture from the training on junipers learning portal is better than what I can type up.
Great for when you are advertising out BGP routes, and don’t want to go sharing either too specific routes or ones that are too general.
Key words in prefix lists:
exact: (route-filter 192.168/16 exact) The exact ip address specified (in this example 192.168.0.0/31).
orlonger: (route-filter 192.168/16 orlonger) from the host specified down to and including the last (192.168.0.0/16).
longer: (route-filter 192.168/16 longer) As above, but not including the first host (so everything after and including 192.168.0.0/17 and 192.168.128.0/17 but NOT 192.168.0.0/16).
upto: (route-filter 192.168/16 upto /18) All the ip addresses from a specified address up to an end one (so maybe 192.168/16 upto 192.168/18).
prefix-length-range /x-/y: (route-filter 192.168/16 prefix-length-range /18-/19) Allows you to specify a start and end point for a range.
Policy and Firewall Prefix Lists
You can create a range or prefixes in a list so they can be referenced more easily when configuring things like firewalls and policies.
prefix-list exampleList {
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
}
policy-statement IMPORTANT_POLICY {
term term-1 {
from {
prefix-list exampleList;
}
then reject;
}
}
term whatever {
from {
prefix-list-filter exampleList orlonger;
}
then reject;
}
Configuring policy for OSPF (in this example make specific static route viewable in OSPF, the policy-statement is already configured, but this will show you how to add to it.)
user@juniperdevice#
user@juniperdevice# edit policy-options
[edit policy-options]
user@juniperdevice# show
policy-statement advertiseStaticRoute {
term match_static_default_term {
from protocol static;
then accept;
}
}
To actually apply this to the OSPF routing protocol:
[edit policy-options] user@juniperdevice# top edit protocols ospf [edit protocols ospf] user@juniperdevice# set export advertiseStaticRoute user@juniperdevice# commit
If you then want to modify this configuration, maybe to specify that a specific route shouldn’t be exported in this way. We will add a new term rather than edit the old one
user@juniperdevice# edit policy-statement advertiseStaticRoute [edit policy-options policy-statement advertiseStaticRoute] user@juniperdevice# set term NEW from protocol static user@juniperdevice# set term NEW from route-filter 8.8.8.8/32 exact user@juniperdevice# set term NEW then reject
As this one is more specific than the last we will put it above the term match_static_default_term, and then commit it.
user@juniperdevice# set term NEW before term match_static_default_term user@juniperdevice#
Firewall Filter Overview
Similar to ACL lists on Cisco – We want to be able to apply rules to traffic coming in on an interface and have a chance to catch that traffic, drop it, or otherwise manipulate it.
Each filter is a collection of rules (or terms in juniper terminology).
The structure is similar to that of routing policies, in that the terms follow a From -> Then format and are applied top to bottom.
Unlike in routing policies however, the default behaviour to any traffic not captured by the filter is to discard the traffic.
Matching (from)
-Addresses
-Numeric Ranges
-Bit fields
Actions (then):
-Terminating (Accept, Reject, Discard)
-Flow Control (Next-term)
-Non-terminating (systlog, log, count, policert, forwarding-class, loss-priority)
Non-terminating actions have an implicit accept associated with them, so we have to be very careful when using them. So you would generally include a flow control action in the term as well when using a “non-termiating” term.
[NOTE: This is what they do to CCTV, if it ever comes up. – Needs to be rejigged as it’s stopping the cameras being updated to latest firmwares, will become a bigger issue as time goes on]
The traffic coming from the outside world to the Routing engine goes through the internal interface FXP1. Though it might seem like a good idea to configure a firewall filter on that interface – it should not be done! This is likely to break the system in some way.
Instead you can configure an input firewall filter on the loopback interface lo0.0. Again great care should be taken before implementing this, as if done incorrectly you can cut off your access from the device, or cause all sorts of mayhem with regards to other control traffic as the default for anything not covered in a rule is to discard.
To edit any firewall configuration (for ipv4) you start with the command:
edit firewall family inet
a show command will show you any currently configured firewall, the syntax for which looks like this:
filter junosDeviceOut
term count
from {
source address {
10.0.0.1/32;
}
protocol icmp;
}
then {
count varPingCount;
log;
}
}
term CATCH_ALL {
then {
accept;
}
}
}
You can then apply the filter using this command.
user@juniperDevice# top edit interfaces ge-0/0/1 [edit interfaces ge-0/0/1] user@juniperDevice# set unit 0 family inet filter output junosDeviceOut user@juniperDevice# commit
Routing Tables and the Forwarding Table
The Routing table is built by the control plane. Anything Routing table will be in the Routing Engine if it comes up in the exam.
There are multiple Routing Tables, each protocol will have its own routing table (e.g. inet.0 is ipv4 uncast and inet6.0 is ipv6 unicast)
Each routing instance also has its own Routing Table.
The Routing table stores destination and path information, and can be viewed with the show route command.
The Forwarding Table is derived from the routing table, and is stored and maintained in the Control plane (Routing Engine), and then a copy is passed to the Forwarding Plane, which uses it to handle transient traffic at near wire speed. The rules laid out in the forwarding table are used by the packet forwarding table.
We can see the current forwarding table using the show forwarding-table command.
To view the version of the forwarding table that is stored in the PFE you can run show pfe route ip.