Protocol Independent Routing
Static Routes – [edit routing-options static]
Consists of destination prefix and next-hop IP or egress interface on P-to-P links. Static route is removed from the routing table when marked inactive, eg: next-hop IP no longer available.
Next-hop can also be reject (send ICMP network unreachable) or discard (silently drop).
Beneath the static route stanza the following additional options are available:
- resolve – next-hop must be reachable via a direct route, using the resolve option allows for recursive lookup.
- qualified-next-hop – can be used as floating-static route, when given a higher preference
- no-readvertise – prevents the routing from be advertised via routing policy. Use for management traffic.
- as-path – used for BGP to manually add values to the AS path attribute
- community – used for BGP to manually add community values.
- preference – default value of 5. Increase value to make the same route learnt from other routing sources more preferable.
- metric – use with identical routes with the same preference. Highest metric gets installed in routing table.
Aggregate Routes – [edit routing-options aggregate]
Combine multiple route prefixes (contributing routes) under one larger prefix with shorter netmask. Reduces routing table size. Default preference is 130 and next-hop is reject (can be set to discard). Aggregate route becomes active when at least one contributing route is active in the routing table.
Shares the same additional options as static routes with the addition of:
- policy – used to accept of reject contributing routes to determine whether aggregate route becomes active.
Generated Routes – [edit routing-options generate]
Like aggregate routes except the next-hop is the same next hop as the primary contributing route, ie the lowest route preference. If there is a tie, the route with the lowest prefix number is selected.
If the next-hop is the local device the generated route becomes hidden.
Martian addresses – [edit routing-options martians]
Host or network address which are not installed in the routing table. It is possible to edit the martian address list and accept them for addition into the routing table.
Routing instances – [edit routing-instances]
Act like VRFs permitting separate routing tables to run on a single device. master is the default instance. Non-default routing instance routing tables have the naming format: . , eg:
The following instance types are available:
• forwarding – Used to implement filter-based forwarding for common Access Layer applications;
• l2vpn – Used in Layer 2 VPN implementations;
• no-forwarding – Used to separate large networks into smaller administrative entities;
• virtual-router – Used for non-VPN-related applications such as system virtualization;
• vpls – Used for point-to-multipoint LAN implementations between a set of sites in a VPN
• vrf – Used in Layer 3 VPN implementations.
Routing Information Base (RIB) – [edit routing-options rib-groups]
Rib-groups are used to export routes from one routing-instance route table into another. The routes which are imported are controlled via an import-policy.
Logical interfaces – [edit interfaces lt-*/*/*]
Logical interfaces can be used in pairs to create tunnels between routing instances. this is not supported on all platforms. In these cases you can connect physical interfaces belonging to separate routing instances together.
Load Balancing – [edit policy-options]
Equal-core multipath load-balancing allows for the distribution of traffic destined for the same destination prefix to travel over different equal core Layer 3 links.
- Per-packet load balancing – not implemented in most modern JunOS devices. Packets are distributed between paths via round-robin algorithm. This gives good load balancing, but packets arriving out of order can result in poor performance.
- Per-flow load balancing – Flow (default) = same ingress interface, same source and destination addresses and same protocol. Flow definition can be configured to include other layer3 and layer4 data. Traffic belonging to the same flow always exits via the same egress interface. The relevant next-hop is taken from the routing table and installed in the routing table. In the event of the next-hop becoming unavailable the selection process is repeated.
load-balance per-packet is available on all Junos OS platforms; Internet Processor II platforms actually forward on traffic flow (up to 64 equal-cost paths allowed). Internet Processor I platforms do forward per-packet.
- Link-state interior gateway protocol
- 188.8.131.52 – All OSPF routers
- 184.108.40.206 – All Designated Routers
|Type 2||Database Description||
|Type 3||Link-State Request|
|Type 4||Link-State Update|
|Type 5||Link-State Acknowledgment|