JNCIS-SP: Protocol Independent Routing.

Static routes.

A static route is a manually configured routing entry. In Junos, a static route is configured at the [edit routing-options] hierarchy.
A basic static route consists, at a minimum, of a destination prefix and a next-hop.
The default preference of a static route in Junos is 5.
An example of a static route:

set routing-options static route next-hop

Static routes offer a lot of flexibility. The flexibility of static routing lies in the next-hop options and the static route options provided by Junos.

The next-hop options provided by Junos:

- IP address:
the IP address of a directly connected device. This is the default option.
- egress interfaces:
the egress interface through which the destination prefix can be reached. This can be used on point-to-point, non-Ethernet interfaces.
- resolve:
this will make the lookup of the next-hop recursive.
- qualified-next-hop:
aka, floating static. Multiple next-hops can be configured with different preferences. The one with the most preferred next-hop will be used.
- next-table:
the lookup will be performed in another table.
- reject:
sent all traffic into the bit-bucket. When a packet is sent to the bit-bucket, the Junos router will send an ICMP-unreachable message to the source IP of the packet.
- discard:
sent all traffic into the bit-bucket without notifying the sender.

The static routing options provided by Junos:

- preference:
the default preference is 5. This can be altered per route or for all the routes.
- no-readvertise:
this will prevent Junos from redistributing the static route via another protocol.
- as-path:
when the static route is redistributed via BGP, it will have the specified AS added.
- community:
when the static route is redistributed via BGP, it will have the specified community added.
- metric:
when the route preference is the same, the best metric will decide what route is used in Junos.

Aggregates and generated routes.

Aggregate and generated routes are rather similar. They both allow you to combine a group of routes into a single entry.
They can be used to decrease the number of routes sent (when redistributing into another protocol) and they can hide internal routing instability.
Both are configured under the [edit routing-options].
Aggregate routes become active when there is at least one contributing route.
The default preference is 130 and the default next-hop is reject. Both of these can be altered.
Aggregate option can be assigned to the aggregate route itself or to the contributors (overruling the option set tot the aggregate).
The options you can assign to an aggregate route are:
- a policy
- AS-path, community, metric & preference

An example of an aggregate route:

set routing-options aggregate route policy EXAMPLE_policy

Generated routes are the same except for their main difference:
the next-hop is received from the primary contributing route (lowest route preference or lowest number prefix).

Martian addresses.

Network or host addresses for which all routing information is ignored. The addresses are not installed into the routing table.
'show route martians' will display all martian routes.
It is possible to add user defined addresses to the default list of martian addresses under [edit routing-options martians].

Routing instances.

Juniper defines a routing-instance as a collection of routing tables, interfaces and routing protocol parameters.
By default, several routing-instances are created. For example, the 'inet.0' and the 'inet6.0' are created for default unicast routing.

You can also add user defined routing instances under the [edit routing-instances] hierarchy.
The available type of routing-instances that can be created are the following:
- l2vpn:
must include route-distinguisher and route target import/export. Enables a layer 2 VPN routing instances.
- vpls:
must include route-distinguisher and route target import/export. Enables a point-to-multipoint layer 2 VPN instance.
- vrf:
must include route-distinguisher and route target import/export. Enables a layer 3 VPN.
- virtual router:
similar to VPN, but used for non-VPN scenario's. No route-distinguisher or route-target import/export is required.
- no-forwarding:
to separate large networks into smaller entities.
- forwarding:
used for filter-based forwarding.

RIB groups.

To place routing information into several tables simultaneously, RIB groups can be used.
They are defined under [edit routing-options rib-groups].
To create a testing.1 table with the direct and interface routes from the master table, use the following;

set routing-options rib-groups example import-rib [inet.0 testing.1]
set routing-options interface-routes rib-group example

In this hierarchy, you can define a single export statement and multiple import statements. The export statement is utterly useless in my opinion.
The import statements are what matters and they define the RIBs you are working with.
According to the JNCIS SP course material, the first table listed is the primary table.

RIB groups can be applied under interfaces, static routes, OSPF, IS-IS, BGP etc. etc. Example:
set protocols ospf rib-group test

RIB groups are something you come to comprehend when working with them.
They are confusing, annoying, hard to explain to others and hard to remember of time. I tend to work around them when I can.

Load balancing.

Junos offers per packet and per flow ECMP load-sharing methods.
Per packet is the 'old' method. Load-balancing is done round-robin. This way, packets can arrive out-of-order, thus decreasing network performance.

Per flow is the modern Junos way of load-balancing. Packets are grouped into a flow based on the following:
- source interface
- destination address
- protocol

Based on these characteristics, traffic will be divided across the links. Through configuration, layer 3 + 4 port data can also be incorporated.

To start load-balancing:
1. create a policy:
match desired traffic and use the 'then load-balance per-packet' (will automatically perform per flow)
2. apply it to the forwarding table:
done under the [edit routing-options forwarding-table]

To incorporate layer 4 port data you have to configure a hash/key for layer 3+4 under [edit forwarding-options].

When configured properly, the 'show route forwarding-table' command will display a 'ulst': list of unicast next hops.

Filter-based forwarding.

Normally, a router takes a forwarding decision based on the destination prefix.
Filter-based forwarding can be used when you want a router to make forwarding decisions on additional criteria.
To configure filter based forwarding, follow these three steps:
1. create a 'forwarding' routing-instance [ edit routing-instance]
2. create a filter [ edit firewall ] with a from statement defining what you want the forwarding decision to be based on (ex, source IP) and a then statement with the next table being the 'forwarding' instance
3. create a RIB group (to share interface routes between the routing-instances in order to resolve the next-hops) [ edit routing-options]