JNCIA Refresher #4 - Routing Fundamentals
Table of Contents
Packet Forwarding Concepts⌗
Packet forwarding
is the movement of data packets from device to device. This is key for any network, as if the networking devices don’t know how to move a packet outside of its own segment/area, the packet will be dropped and the reason we have networks is to move data/information from one place to another. With that being said, a device doesn’t need to know whole Internet or even a whole network. The most important information; a switch, router or any layer 2/3 device needs to know is the next-hop address. The next-hop provides an exit for the device if the destination of the packet isn’t located on the device, it will pass the packet on to “the next hop” device and that device will do the same thing until the destination of the packet is located. This is basis of packet forwarding.
A Juniper device (or any network device in fact) will have Routing Engine (RE)
and Packet Forwarding Engine (PFE)
. These engines (software or hardware based) are what will used to move packets and ultimately controls the routing on the device.
The Routing Engine is the control plane of the device. The control plane is where all the Routing Information Base (RIB)
will be stored and from the RE the creation of the packet forwarding switching fabric that will be used for the movement of packets. The RE is responsible for providing filtering information, route lookups and determining of what the next-hop address will be. It is important to note, that the RE does not control how the packets are moved, it is where the RIB is stored. The Packet Forwarding Engine uses this information.
The Packet Forwarding Engine
is the where the forwarding of transit traffic is processed. The PFE directly affects the packets. The PFE will use the information from the RE and apply the information to the packets by applying any firewall filters, routing and/or security policies before forwarding the packet onto the next-hop destination.
Routing Tables⌗
With Junos, it is different compared to other vendors when it comes to see information within the Routing Table. Other vendors will have multiple commands that you use will use to see different tables (i.e. the routing table for IPv4 and IPv6). In Junos, we just need to use the show route
command we will see the multiple routing tables under the single command. Each of the tables are populated with routes as and when they are needed, you can say each of table is a database of information for it’s particular routing type.
As you can see, my router only has IPv4 currently configured, so it will only have the inet.0
table
root@Single\_SRX> show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
0.0.0.0/0 \*\[Static/5\] 1d 23:54:16
> to 10.1.0.1 via ge-0/0/7.0
10.1.0.0/24 \*\[Direct/0\] 1d 23:54:16
> via ge-0/0/7.0
10.1.0.207/32 \*\[Local/0\] 1d 23:54:20
Local via ge-0/0/7.0
172.31.100.2/31 \*\[Direct/0\] 1d 23:54:16
> via ge-0/0/1.0
172.31.100.2/32 \*\[Local/0\] 1d 23:54:20
Local via ge-0/0/1.0
It is important to note, that I have 5 routes and they all active. When looking at the routing table ideally you would like to have Active routes. Routes in holddown state are in pending state before declared inactive. Hidden routes are not in the routing table because of a routing policy.
Juniper’s definition on Routing Tables⌗
The table below shows, all the tables that are created by default by Junos. At the JNCIA level you will only need to worry about the inet.0 and inet6.0 tables. However it’s always good to have bit more info to look into later :D
Junos Default Routing Tables⌗
Routing Table | Description |
---|---|
inet.0 | IPv4 unicast routes. This table stores interface local and direct routes, static routes, and dynamically learned routes. |
inet.2 | This table is created when multiprotocol BGP (MBGP) is enabled. This table stores unicast routes that are used for multicast reverse-path-forwarding (RPF) lookup. You can import routes from inet.0 into inet.2 using routing information base (RIB) groups, or install routes directly into inet.2 from a multicast routing protocol. |
inet.3 | IPv4 MPLS routes. This table stores the egress address of an MPLS label-swiched path (LSP), the LSP name, and the outgoing interface name. This routing table is used only when the local device is the ingress node to an LSP. |
inet6.0 | IPv6 unicast routes. This table stores interface local and direct routes, static routes, and dynamically learned routes. |
instance-name.inet.0 | This table is created when you configure a routing instance, Junos OS creates the default unicast routing table. |
instance-name.inet.2 | This table is created when you configure routing-instances instance-name protocols bgp family inet multicast in a routing instance of type VRF, Junos OS creates the instance-name.inet.2 table |
bgp.l2vpn.0 | This table is created for Layer 2 VPN routes learned from BGP. This table stores routes learned from other provider edge (PE) routers. The Layer 2 routing information is copied into Layer 2 VPN routing and forwarding instances (VRFs) based on target communities. |
bgp.l3vpn.0 | IPv4 unicast routes. This table is created for Layer 3 VPN routes learned from BGP. This table stores routes learned from other PE routers. R.stores interface local and direct routes, static routes, and dynamically learned routes. |
mpls.0 | This table is created for MPLS label switching operations. This table is used when the local device is a transit router. |
iso.0 | This table is for IS-IS routes. When you are using IS-IS to support IP routing, this table contains only the local device’s network entity title (NET) |
juniper_private | For Junos OS to communicate internally between the Routing Engine and PIC hardware. |
Routing vs. Forwarding Tables⌗
The Routing Information Base (RIB)
is located within with the Routing Table (RT)
. As stated in the packet forwarding concepts, the RIB are stored in the Control Plane, this would makes the Routing Table is part of the Control Plane within Junos. As such, the RT has information about all available routes that the router could use, but critically doesn’t make forwarding decisions.
The Forwarding Table (FT)
has all the information from the RT, creates the best path for transit traffic and only keeps the best/active paths in compressed or pre-complied format for optimised route lookups. Therefore, the FT is both Control and Forwarding Plane. This makes the relationship between the RT and FT important, as without one, the other will fail.
In essence, the process packet movement would be:
Packet In --> Routing Information Base --> Routing Table --> Forwarding Table --> Packet Out
We can see the different between the Routing and Forwarding Tables. We can view the routing Table by running the show route
command. As we can see from the ‘show route’ tab, there is some detail however not a great deal, when compared to the forwarding table.
To see the forwarding table, we will need to run show route forwarding-table
. We can see from show route forwarding-table
ouput, the level of detail is greater. In addition, from the forwarding-table the key thing you will need to know for the JNCIA exam are the two different types (Destination Types and Next-Hop Types) and what their type variables mean. This is shown below on Destination and Next-Hop Types tabs.
Show route⌗
root@Single\_SRX> show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
0.0.0.0/0 \*\[Static/5\] 3d 20:13:19
> to 10.1.0.1 via ge-0/0/7.0
10.1.0.0/24 \*\[Direct/0\] 3d 20:13:19
> via ge-0/0/7.0
10.1.0.207/32 \*\[Local/0\] 3d 20:13:23
Local via ge-0/0/7.0
172.31.100.2/31 \*\[Direct/0\] 3d 20:13:19
> via ge-0/0/1.0
172.31.100.2/32 \*\[Local/0\] 3d 20:13:23
Local via ge-0/0/1.0
Show route forwarding-table⌗
root@Single\_SRX> show route forwarding-table
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 0 ac:4b:c8:79:41:10 ucst 554 3 ge-0/0/7.0
default perm 0 rjct 36 1
0.0.0.0/32 perm 0 dscd 34 1
10.1.0.0/24 intf 0 rslv 547 1 ge-0/0/7.0
10.1.0.0/32 dest 0 10.1.0.0 recv 545 1 ge-0/0/7.0
10.1.0.1/32 dest 0 ac:4b:c8:79:41:10 ucst 554 3 ge-0/0/7.0
10.1.0.17/32 dest 1 18:a9:5:40:1a:0 ucst 556 2 ge-0/0/7.0
10.1.0.207/32 intf 0 10.1.0.207 locl 546 2
10.1.0.207/32 dest 0 10.1.0.207 locl 546 2
10.1.0.255/32 dest 0 10.1.0.255 bcst 544 1 ge-0/0/7.0
172.31.100.2/31 intf 0 rslv 543 1 ge-0/0/1.0
172.31.100.2/32 intf 0 172.31.100.2 locl 542 2
172.31.100.2/32 dest 0 172.31.100.2 locl 542 2
172.31.100.3/32 dest 1 10:e:7e:4e:f:80 ucst 555 2 ge-0/0/1.0
224.0.0.0/4 perm 0 mdsc 35 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1
255.255.255.255/32 perm 0 bcst 32 1
{omitted output}
Destination Types⌗
Destination Type | Description |
---|---|
intf (Interface) | This is where an interface has been manually configured |
dest (Destination) | The destination of an address that is directly reachable. You would see an IP address (in the next-hop column) if the address is local or a network address. You would see a mac-address if the address isn’t local |
perm (Permanent) | This is installed as part of the Junos Kernel and can’t be removed |
user (Routing) | These are routes learnt via a routing protocol i.e. ISIS, RIP, OSPF, BGP and Static Routes |
Next-Hop Types⌗
Next-Hop Type | Description |
---|---|
ucst (Unicast) | This is where an interface has been manually configured |
dscd (Discard) | The destination of an address that is directly reachable. You would see an IP address (in the next-hop column) if the address is local or a network address. You would see a mac-address if the address isn’t local |
rjct (Reject) | This is installed as part of the Junos Kernel and can’t be removed |
bcst (Broadcast) | These are routes learnt via a routing protocol i.e. ISIS, RIP, OSPF, BGP and Static Routes |
locl (Local Address) | Local Addresses to the device |
mcst (Multicast) | Multicast addresses |
Route Preference⌗
When we look at the routing table, we can see that see that we have some details about the routes we have learnt:
root@Single\_SRX> show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
0.0.0.0/0 **\*\[Static/5\] 3d 20:13:19
> to 10.1.0.1 via ge-0/0/7.0**
{omitted output}
172.31.100.2/31 **\*\[Direct/0\] 3d 20:13:19
> via ge-0/0/1.0**
172.31.100.2/32 **\*\[Local/0\] 3d 20:13:23
Local via ge-0/0/1.0**
As you can see from the output, we are told the how the route is connected to the device and given a value. The value would be the Route Preference
(Known As Administrative Distance). The preference is taken from the RIB to determine, if you receive a route from two different protocols, which route would make the Routing-Table. Its important to note when we have Direct and Local preference, junos uses the most specific route and where in the example above 172.31.100.2 has been assigned as the local interface address it’s given /32 net mask telling the device that this is their address.
The table below has a summary of the default route preference values.
Route Preference Number | Protocol |
---|---|
0 | Direct/Local Address |
5 | Static Route |
10 | OSPF (Internal) |
100 | RIP |
130 | Aggregate Routes (Summary Routes) |
150 | OSPF (External) |
170 | BGP |
You can check the full Default Route Preference Values are on the Juniper Website here
Routing Instances⌗
Routing instances
(VRFs on cisco) are a way of dividing your switch, firewall or router, to allow the device to have multiple independent Routing Tables within the single device. Each routing-instance will need to have its physical (or logical) interface(s) and its instance-type defined. As you can see below when you have routing-instance configured you will have the each routing-instance has its own routing-table and they are shown as instance-name.inet.0
. It important to note, that all configuration for the routing-instance will need to be done under the routing-instance stanza.
Instance Types⌗
root@Single\_SRX# set routing-instances untrust instance-type ?
Possible completions:
forwarding Forwarding instance
l2backhaul-vpn L2Backhaul/L2Wholesale routing instance
l2vpn Layer 2 VPN routing instance
layer2-control Layer 2 control protocols
mpls-internet-multicast Internet Multicast over MPLS routing instance
no-forwarding Nonforwarding instance
virtual-router Virtual routing instance
virtual-switch Virtual switch routing instance
vpls VPLS routing instance
vrf Virtual routing forwarding instance
Routing-Instance Config⌗
{master:0}
root> show configuration routing-instances
trust {
instance-type virtual-router;
interface vlan.20;
routing-options {
static {
route 172.16.0.0/24 next-hop 192.168.0.1;
}
}
}
untrust {
instance-type virtual-router;
interface vlan.10;
routing-options {
static {
route 192.168.0.0/24 next-hop 172.16.0.1;
}
}
}
Global Routing Table⌗
root> show route
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
10.1.0.0/24 \*\[Direct/0\] 2w6d 04:28:28
> via me0.0
10.1.0.200/32 \*\[Local/0\] 2w6d 04:28:28
Local via me0.0
224.0.0.22/32 \*\[IGMP/0\] 2w6d 04:28:29
MultiRecv
Routing-Instance Trust⌗
trust.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
172.16.0.0/24 \*\[Static/5\] 2w2d 01:20:57
> to 192.168.0.1 via vlan.20
192.168.0.0/24 \*\[Direct/0\] 2w2d 01:20:57
> via vlan.20
192.168.0.2/32 \*\[Local/0\] 2w4d 01:10:24
Local via vlan.20
Routing-Instance Untrust⌗
untrust.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, \* = Both
172.16.0.0/24 \*\[Direct/0\] 2w2d 01:26:30
> via vlan.10
172.16.0.2/32 \*\[Local/0\] 2w4d 01:10:24
Local via vlan.10
192.168.0.0/24 \*\[Static/5\] 2w2d 01:26:30
> to 172.16.0.1 via vlan.10
Static Routing⌗
As the name suggests static routing is a route that has been created manually and doesn’t change, unless it’s manually updated. When creating a static route, knowing the next-hop information is key as you are saying I want this IP address/range to go next. For my example below, I have created a static default route on this device. I have used the no-readvertise
option, so that this route IS NOT readvertised into the routing-table and NOT routable
root@Top\_SRX# show routing-options
static {
route 0.0.0.0/0 {
next-hop 10.1.0.1;
no-readvertise;
}
}
When creating static route, there’s a number of different options that are available:
root@Top\_SRX# set routing-options static route 172.31.100.1 ?
Possible completions:
active Remove inactive route from forwarding table
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> as-path Autonomous system path
backup-pe-group Multicast source redundancy group
> bfd-liveness-detection Bidirectional Forwarding Detection (BFD) options
> color Color (preference) value
> color2 Color (preference) value 2
+ community BGP community identifier
discard Drop packets to destination; send no ICMP unreachables
install Install route into forwarding table
> lsp-next-hop LSP next hop
> metric Metric value
> metric2 Metric value 2
> metric3 Metric value 3
> metric4 Metric value 4
+ next-hop Next hop to destination
next-table Next hop to another table
no-install Don't install route into forwarding table
no-readvertise Don't mark route as eligible to be readvertised
no-resolve Don't allow resolution of indirectly connected next hops
no-retain Don't always keep route in forwarding table
> p2mp-lsp-next-hop Point-to-multipoint LSP next hop
passive Retain inactive route in forwarding table
> preference Preference value
> preference2 Preference value 2
> qualified-next-hop Next hop with qualifiers
readvertise Mark route as eligible to be readvertised
receive Install a receive route for the destination
reject Drop packets to destination; send ICMP unreachables
resolve Allow resolution of indirectly connected next hops
retain Always keep route in forwarding table
> static-lsp-next-hop Static LSP next hop
> tag Tag string
> tag2 Tag string 2
The key ones to look into for the JNCIA level would:
next-hop
: This is set the next-hop address for the subnet to use to leave the local devicequalified-next-hop
: This is a secondary next-hop address (Known as a floating IP address). If the first next-hop address is unavailable, the router will use that qualified next-hop address. In addition, you are able to set the route preference for the qualified-next-hop manuallydiscard*
: This will silently drop packets, providing no replyreject
: This will drop packets and provide an ICMP replyno-readvertise
: Self explained
Only using static routing in a network is a lot of manual work and you will have to do this for every device on your network and trying to maintain this would be a ridiculous and is un-scalable. This leads into why the need for Dynamic Routing Protocols in a network is important in conjunction with static routes.
Dynamic Routing Protocols⌗
When talking about dynamic routing, we can break it down into 2 categories Internal Gateway Protocols and External Gateway Protocols.
Internal Gateway Protocols⌗
Internal Gateway Protocols (IGPs) is a type of protocol used for exchanging routing information between gateways within an Autonomous System. With IGPs there two types protocols: Distance-vector routing protocol
and Link-state routing protocol
Distance-vector routing protocol
each router does not possess information about the full network topology. It advertises its distance value (DV) calculated to other routers and receives similar advertisements from other routers unless changes are done in local network or by neighbours (routers). Using these routing advertisements each router populates its routing table. In the next advertisement cycle, a router advertises updated information from its routing table. This process continues until the routing tables of each router converge to stable values.
Distance Vector Protocols include:
- Routing Information Protocol (RIP)
- Routing Information Protocol Version 2 (RIPv2)
- Routing Information Protocol Next Generation (RIPng), an extension of RIP version 2 with support for IPv6
- Interior Gateway Routing Protocol (IGRP)
Whereas, Link-state routing protocols
, each router possesses information about the complete network topology. Each router then independently calculates the best next hop from it for every possible destination in the network using local information of the topology. The collection of best-next-hops forms the routing table.
This contrasts with distance-vector routing protocols, which work by having each node share its routing table with its neighbours. In a link-state protocol, the only information passed between the nodes is information used to construct the connectivity maps.
Link-state routing protocols include:
- Open Shortest Path First (OSPF)
- Intermediate system to intermediate system (IS-IS)
External Gateway Protocols⌗
External Gateway Protocols (EGPs) is a routing protocol used to exchange routing information between autonomous systems. This exchange is crucial for communications across the Internet. Notable exterior gateway protocols include Exterior Gateway Protocol and Border Gateway Protocol.