JNCIA STUDY GUIDE

1. Junos OS functionality is compartmentalized into multiple software processes. Each process

handles a portion of the device’s functionality. Each process runs in its own protected memory
space, ensuring that one process cannot directly interfere with another. When a single process
fails, the entire system does not necessarily fail. This modularity also ensures that new features
can be added with less likelihood of breaking current functionality.

2.

The RE maintains the routing tables, bridging table, and primary forwarding table and connects
to the Packet Forwarding Engine (PFE) through an internal link. The PFE receives the
forwarding table (FT) from the RE by means of an internal link.

3. Functions of routing engine:

- maintains routing engine intelligence
- controls and monitors chassis
- manages packet forwarding engine
Functions of packet forwarding engine:
- the PFE is the central processing component of the forwarding plane
- implements advanced services such as policers that provide rate limiting, stateless firewall
filters and class of service

4. Transit traffic consists of all traffic that enters an ingress network port, is compared against the
forwarding table entries, and is finally forwarded out an egress network port toward its
destination.
Unlike transit traffic, exception traffic does not pass through the local device but rather requires
some form of special handling. Examples of exception traffic include the following:
- Packets addressed to the chassis, such as routing protocol updates, Telnet sessions, pings,
traceroutes, and replies to traffic sourced from the RE;
- IP packets with the IP options field (options in the packet’s IP header are rarely seen, but the
PFE was purposely designed not to handle IP options; packets with IP options must be sent to
the RE for processing); and
- Traffic that requires the generation of Internet Control Message Protocol (ICMP) messages.
5. The Junos OS sends all exception traffic destined for the RE over the internal link that connects
the control and forwarding planes. The Junos OS rate limits exception traffic traversing the
internal link to protect the RE from denial-of-service (DoS) attacks. During times of congestion,
the Junos OS gives preference to the local and control traffic destined for the RE. The built-in
rate limiter is not configurable.

6. Platforms running the Junos OS:

- M series Multiservice Routers
For high end enterprise and service provider environments. Used for Internet gateway router,
WAN connectivity router, campus core router and regional backbone and data center routers.
- T series Core Routers
Ideal for service provider environments and is deployed within the core of those networks.
- J series Service Routers
Deployed at branch and remote locations in the network
- MX series Ethernet Services Routers
- EX series Ethernet Switches
Designed for access, aggregation and core deployments and are well suited for low-density to
high-density enterprise and data center environments
- SRX series Services Gateways
Designed to meet the network and security requirements for consolidated data centers, managed
services deployments, and aggregation of security services in both enterprise and service
provider environments.

7. Command help:
- help topic command
gives the description of the command which is asked
- help reference command
gives the syntax of the command
- help apropos command

[edit system archival configuration]

user@host# help apropos archive
set archive-sites
List of archive destinations
set archive-sites <url> password <password>
Password for login into the archive site

The help apropos command only displays contexts that are relevant to the configuration
hierarchy level at which you are currently positioned.

8. The command completion option is on by default, but you can turn it off. To disable command
completion for an individual user’s session, issue the set cli complete-on-space off command as
follows:
user@host> set cli complete-on-space off
Disabling complete-on-space

9. Emacs style control keys: Ctrl+A, Ctrl+E, Ctrl+B, Ctrl+F, Ctrl+U, Ctrl+W, etc

10. Use “configure exclusive” to allow only a single user to edit the configuration and exclude
 other users from editing the configuration. Any uncommitted changes are discarded when users
exit. In contrast, uncommited changes are retained when you use the standard configure
command.

11.

Entering configuration mode using the configure private command allows multiple users to edit
the configuration while committing only their private changes. (You must issue a commit
command from the [edit] hierarchy.) If private users issue a rollback 0 command, the software
discards only their changes.
When a user is in private mode, other users must enter private mode or use configure exclusive
to become the master, or they cannot modify the candidate configuration. Exiting private
configuration without committing changes results in the loss of any modifications made to the
private candidate configuration.
If two users are in private mode and both make the same change (For example, User 1 changes
the system hostname to apples while User 2 sets the hostname to oranges), the second commit
will fail with an error message to avoid configuration conflicts. The software places the second
user’s changes into effect if User 2 issues a second commit command.

12. Consider using the wildcard delete function when deleting individual statements is too arduous
and deleting an entire configuration subhierarchy lacks the granularity that you need. The
following example shows sample syntax for a wildcard delete:

[edit]
user@host# wildcard delete interfaces ge-1/*
matched: ge-1/0/0
matched: ge-1/0/1
Delete 2 objects? [yes,no] (no) yes

13.
14.

15. You can typically perform the commit operation from any hierarchy level. The exception is when users
enter configuration mode using the configure private option, which requires the commit command to be
issued at the top hierarchy level. On devices with redundant Routing Engines, you can perform a commit
synchronize, which activates and synchronizes the configuration on both Routing Engines, as shown in
the following capture:

{master:0}[edit]
user@host# commit s?
Possible completions:
synchronize
Synchronize commit on both Routing Engines

Alternatively, you can configure the system to automatically perform the synchronize operation when a
standard commit is issued through the set system commit synchronize command.

16. Use the commit check command to validate the syntax of a candidate configuration without actually
placing it into effect. Of course, commit check cannot catch logical errors in your configuration. What
happens when you are configuring a device remotely and make a mistake that leaves that device
inaccessible to remote connections? You can solve this scenario by using the commit confirmed
command. When you issue a commit confirmed time-out command, the system starts a timer, during
which time it expects to see another commit. If a second commit does not occur within the time-out
value specified (the software supports a range of 1 to 65,535 minutes, with 10 minutes being the
default), the system performs a rollback 1, commit sequence on your behalf. After the automatic
rollback, you can load the rollback 1 file to look for your mistake.

17.
18.

19. In operational mode, you can control the Junos CLI environment. By default, an individual CLI
session never times out after extended times, unless the idle-timeout statement has been
included in the user’s login class configuration. The timeout can be 0–100,000 minutes. Setting
the timeout to 0 disables the timeout.

user@host> set cli idle-timeout 60

Idle timeout set to 60 minutes
user@host> set cli idle-timeout 0
Idle timeout disabled

The CLI provides a method to display a login message to users. The login message is displayed
when a user connects to the host using Telnet or SSH.

[edit system]
user@host# set login message “Insert login message here...”

20.

A rescue configuration is a user-defined, known-good configuration that is designed to restore

connectivity in the event of configuration problems. We recommend that the rescue configuration
contain the minimum elements necessary to restore network connectivity. For added security, the rescue
configuration must include a root password. By default, no rescue configuration is defined.
 21. Physical Properties of interfaces
The following list provides details for some physical interface properties.
• Data Link Layer protocol and keepalives: You can change the Data Link Layer protocol for the
particular media type (for example, PPP to Cisco HDLC), and you can turn keepalives on or off.
• Link mode: On Ethernet interfaces you can hardcode the duplex setting to either half-duplex or
full-duplex.
• Speed: You can specify the link speed on certain interface types.
• Maximum transmission unit (MTU): You can vary the size from 256 to 9192 bytes.
• Clocking: Refers to the interface clock source, either internal or external.
• Scrambling: Refers to payload scrambling, which can be on or off.
• Frame check sequence (FCS): You can modify to 32-bit mode (the default is 16-bit mode).
• Diagnostic characteristics: You can enable local or remote loopbacks or set up a BERT test.

Logical Properties of interfaces

The following list provides details for some logical interface properties:
• Protocol family: Refers to the protocol family you want to use, such as family inet, inet6, iso,
mpls, or ethernet-switching.
• Addresses: Refers to the address associated with the particular family (for example, IP address
using family inet).
• Virtual circuits: Refers to the virtual circuit identifier, such as a data-link connection identifier
(DLCI), virtual path identifier (VPI), virtual channel identifier (VCI), or virtual LAN (VLAN)
tag.
• Other characteristics: Some other configurable options include Inverse ARP, traps, and
accounting profiles.

22.

The example on the graphic also highlights the use of the preferred and primary configuration options.
The preferred option is used when you have multiple IP addresses belonging to the same subnet on the
same interface. This option allows you to select which address will be used as the source address for
packets sent by the local system to hosts on the directly connected subnet. By default, the numerically
lowest local address is chosen. In the example on the graphic, the default behavior has been overridden
with the preferred option making 172.19.102.2/24 the preferred address.
The primary address on an interface is the address that is used by default as the local address for
broadcast and multicast packets sourced locally and sent out the interface. The primary address flag
also can be useful for selecting the local address used for packets sent out unnumbered interfaces when
multiple non-127 addresses are configured on the loopback interface, lo0. By default, the primary
address on an interface is selected as the numerically lowest local address configured on the interface.
In the example on the graphic, 172.19.102.1/24 is the primary address for the ge-0/0/2.0 interface,
because it is the numerically lowest address configured on that interface; 192.168.200.1/32 is the
primary address for the lo0.0 interfaces, because it has the primary option.

The following capture verifies the primary state:

user@host> show interfaces ge-0/0/2.0 | find addresses
Addresses, Flags: Is-Primary
Destination: 172.19.102/24, Local: 172.19.102.1,
Broadcast: 172.19.102.255
Addresses, Flags: Preferred Is-Preferred
Destination: 172.19.102/24, Local: 172.19.102.2,
Broadcast: 172.19.102.255
Protocol inet6, MTU: 1500
Flags: Is-Primary
Addresses, Flags: Is-Default Is-Preferred Is-Primary
Destination: 3001::/64, Local: 3001::1
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::217:cbff:fe4e:ab02

user@host> show interfaces lo0.0 | find addresses

Addresses
Local: 192.168.100.1
Addresses, Flags: Primary Is-Default Is-Primary
Local: 192.168.200.1

23. While a single logical unit does support multiple protocol families, such as inet and inet6, you
cannot configure a second protocol family in conjunction with the ethernet-switching protocol
family. The following example illustrates this point:

[edit]
user@host# commit
[edit interfaces ge-0/0/2 unit 0]
'family'
When ethernet-switching family is configured on an interface, no other
family type can be configured on the same interface.
error: configuration check-out failed
24.

[edit system]
user@host# show radius-server
172.18.102.13 secret "$9$9ZKntpBvMX7Nb1RcleW-dbs2gaU"; ## SECRET-DATA

[edit system]
user@host# show tacplus-server
172.17.32.14 secret "$9$m5T31Icyrvn/A0ORlevWLXNb"; ## SECRET-DATA

[edit system]
user@host# show login user lab
class super-user;
authentication {
encrypted-password "$1$dJ3NA9BW$nZGLZAp9kpiG52kru34IT."; ## SECRET-DATA
}

25.

Because only two authentication methods are listed and both of the servers are up, JunOS does not try
to authenticate against the local database. But if both of the servers are down, JunOS will authenticate
against the local database.
26. Four predefined class of users:
• super-user: all permissions
• operator: clear, network, reset, trace and view permissions
• read-only: view permissions
• unauthorized: no permissions

27. Predefined permissions:

• access: Allows the viewing of network access configuration;
• access-control: Allows the modifying of network access configuration;
• admin: Allows the viewing of user accounts;
• admin-control: Allows the modifying of user accounts;
• all: Enables all permission bits to be turned on;
• clear: Allows the clearing of learned network information;
• configure: Allows the entering of configuration mode;
• control: Allows the modifying of any configuration values (must be used in conjunction
with the configure permission);
• field: Is reserved for field (debug) support;
• firewall: Allows the viewing of firewall configuration;
• firewall-control: Allows the modifying of firewall configuration;
• floppy: Allows the reading and writing of information to the floppy drive;
• flow-tap: Allows the viewing of flow-tap configuration;
• flow-tap-control: Allows the modifying of flow-tap configuration;
• flow-tap-operation: Enables the tapping of flows;
• idp-profiler-operation: Enables IDP profiler;
• interface: Allows the viewing of interface configuration;
• interface-control: Allows the modifying of interface configuration;
• maintenance: Allows system maintenance, including starting a local shell on the device
and becoming the superuser in the shell, and can halt and reboot the system;
• network: Allows network access;
• reset: Allows the resetting and restarting of interfaces and processes;
• rollback: Allows the ability to roll back for depth greater than zero;
• routing: Allows the viewing of routing configuration;
• routing-control: Allows the modifying of routing configuration;
• secret: Allows the viewing of secret configuration;
• secret-control: Allows the modifying of secret configuration;
• security: Allows the viewing of security configuration;
• security-control: Allows the modifying of security configuration;
• shell: Allows the starting of a local shell;
• snmp: Allows the viewing of SNMP configuration;
• snmp-control: Allows the modifying of SNMP configuration;
• system: Allows the viewing of system configuration;
• system-control: Allows the modifying of system configuration;
• trace: Allows the viewing of trace file settings;
• trace-control: Allows the modifying of trace file settings;
• view: Allows the viewing of current values and statistics; and
• view-configuration: Allows the viewing of all configuration (not including secrets).
28.

The configuration example shows how the various authorization components are configured:
- User nancy is a member of the noc-admin class;
- The noc-admin class has the clear, network, reset, and view permissions;
- In addition, the noc-admin class can enter configuration mode using the configure private
command and is allowed to alter configuration parameters at the [edit interfaces] and [edit
firewall] hierarchy levels; and
- The noc-admin class is denied the ability to manipulate files using the operational mode’s file
command and is specifically excluded from navigating to or viewing configuration details at the [edit
groups] hierarchy level.

29. The Junos OS places the results of the logging operations in files that are stored in the /var/log
directory. The primary syslog file, which is included in all factory-default configurations, is
the /var/log/messages file. The Junos OS supports a number of facilities and severity levels. The
facility is listed first and defines the class of log messages. The severity level is listed second
and determines the level of detail to be logged. Syslog information can be logged to individual
files, such as the /var/log/messages file, or it can be sent to a remote server.

30. Syslog configuration example:

31. Interpreting system log entries:

32. Tracing is the Junos term for what other vendors sometimes call debug. In most cases, when you
enable tracing (through configuration), you create a trace file that is used to store decoded protocol
information received or sent by the routing engine. The Junos OS sends the tracing results to a
specified file stored in the /var/log directory or to a remote syslog server. To enable remote logging,
specify a syslog server at the [edit system tracing] hierarchy level as shown in the following screen
capture:
[edit system tracing]
user@host# show
destination-override syslog host 1.1.1.1;

33. Traceoptions configuration example:

Use “delete traceoptions” to disable all tracing at a particular hierarchy and commit the change.

34. Viewing logs and trace files

35. Monitoring logs and trace files

 Use “monitor list” to determine which log files are being monitored.

36. What time is it?

Junos OS support client, server and symmetric mode of NTP operations and can also support broadcast
and authentication. Two machines can synchronize only when their current clocks are relatively close.
By default, if the time difference between the local device’s clock and the NTP server’s clock is more
than 128 milliseconds, the clocks are slowly stepped into synchronization. However, if the
difference is more than 1000 seconds, the clocks are not synchronized. A boot server is used to set a
system clock at boot time to ensure that it is close enough to later synchronize to the configured time
server. Issue the operational mode “set date ntp address” command as a substitute for a boot server.

37. Monitoring NTP

38. Automated configuration backup

How it works?

39. IETF provides standard MIBs you can download at http://www.ietf.org. You can download
Juniper Networks enterprise MIBs at http://www.juniper.net/techpubs.

Monitoring SNMP operations:

 40. Monitoring system information:
#show system argument, and the arguments are:
• alarms: This argument displays current system alarms;
• boot-messages: This argument displays the messages seen during the last system boot;
• connections: This argument displays the status of local TCP and UDP connections;
• statistics: This argument provides options for viewing various protocol statistics; and
• storage: This argument displays the status of the file system storage space.

41. Monitoring chassis information:

#show chassis argument, and the arguments are:
• alarms: This argument displays current chassis alarms;
• environment: This argument displays component and environmental status as well as the
operational speeds of the cooling system;
• hardware: This argument displays an inventory of the installed hardware components
along with the serial number of each component; and
• routing-engine: This argument provides operational status and utilization details for the
Routing Engine (RE).

42. Common commands:

> show interfaces
> show interfaces terse
> show interface interface-name extensive
> monitor interface traffic
> ping ip-address count count-number
> monitor traffic layer2-headers, diagnose problems at layer 2 (a kind of tcpdump utilities)
> monitor traffic write-file file-name, save packet captures to be analyzed with analysis tools (such as
wireshark or ethereal)
> monitor traffic interface interface-name layer2-headers no-resolve
> file copy ftp://ftp:ftp@10.210.11.189/junos-jseries-domestic.tgz /var/tmp/junos-jseries-domestic.tgz
/var/tmp//...transferring.file.........Ri4PRe/100% of 41 MB 4071 kBps 00m00s
> show version [detail]

43. The Junos Naming Convention

• package is a description of the software contents. Package descriptions include jinstall, which is used on
M Series, T Series, and MX Series, jinstall-ex, which is used on EX Series, junos-jsr, which is used on J
Series, and junos-srx, which is used on SRX Series.
• release describes the Junos OS Release and includes several subcomponents. The release includes two
integers that represent the major and minor release numbers as well as a capital letter that indicates the
type of software release. The most commonly occurring letter is R, which stands for released software. If
you are involved in testing prereleased software, this letter might be a B (for beta-level software) or I
(for internal, test, or experimental versions of software). In some situations, you might see the letter S,
which is reserved for service releases. The release also includes a build and spin number for the Junos
OS Release. For example, jinstall-10.1R1.8-domestic.tgz indicates aJunos image associated with version
10.1, build 1, spin 8.
 • edition will typically be either domestic or export. Domestic versions support strong encryption, whereas
export versions do not. A third, less common, edition called FIPS exists that provides advanced network
security for customers who must comply with and operate in a Federal Information Processing Standards
(FIPS) 140-2 environment.

44. Upgrade JunOS:

You can delete Junos images stored in the /var/tmp directory when you perform the file system cleanup operation
using the request system storage cleanup CLI command. To determine which files are cleanup candidates, you
can issue the request system storage cleanup dry-run command. Although plenty of storage space typically
exists, it is a good practice to check available storage capacity before downloading a new Junos OS image. You
can view compact-flash device storage details with the CLI show system storage command.

45. Unified ISSU

A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different Junos OS
releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is only
supported on dual Routing Engine platforms. In addition, the graceful Routing Engine switchover (GRES) and
nonstop active routing (NSR) must be enabled. Note that NSR is not supported on all the Junos devices. Refer to
the technical publications for platform and protocol support details.
The master RE and backup RE must be running the same software Release before you can perform a unified
ISSU. You cannot take any PICs online or offline during a unified ISSU.
46. Password recovery procedure:

47. Interface configuration hierarchy:

48. If you want remote access using J-Web, you must enable the HTTP or HTTPS service under the [edit
system services] hierarchy level as shown in the following capture:

[edit system]
user@host# show services
ssh;
telnet;
web-management {
http;
}

49. Predefined routing tables:

- inet.0: Used for IPv4 unicast routes;
- inet.1: Used for the multicast forwarding cache;
- inet.2: Used for Multicast Border Gateway Protocol (MBGP) routes to provide reverse path
forwarding (RPF) checks;
- inet.3: Used for MPLS path information;
- inet.4: Used for Multicast Source Discovery Protocol (MSDP) route entries;
- inet6.0: Used for IPv6 unicast routes; and
- mpls.0: Used for MPLS next hops.

50. Default route preferences:

51. The show route command displays a summary of active, holddown, and hidden routes. Active routes are
 the routes the system uses to forward traffic. Holddown routes are routes that are in a pending state
before the system declares them as inactive. Hidden routes are routes that the system cannot use for
reasons such as an invalid next hop and route policy.

52. The forwarding table stores a subset of information from the routing table. Within the forwarding table,
you can find the details used by a device running the Junos OS to forward packets such as the learned
destination prefixes and the outgoing interfaces associated with each destination prefix.
You use the show route forwarding-table CLI command to view the forwarding table contents:

53. Some of common routing instance types:

- 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; and
- vrf: Used in Layer 3 VPN implementations.

54. Configuration examples of routing instances:

> show route table new-instance.inet.0 ← if using Ipv4 routing

> show interfaces terse routing-instance new-instance
> ping ip-address rapid count count-number routing-instance new-instance
> traceroute ip-address routing-instance new-instance

55.

As illustrated on the graphic, you can alter the default next-hop resolution behavior using the resolve CLI option.
In addition to the resolve CLI option, a route to the indirect next hop is also required. Indirect next hops can be
resolved through another static route or through a dynamic routing protocol.

56. Benefits of Dynamic Routing

Dynamic routing resolves many of the limitations and drawbacks of static routing. Some of the general
benefits of dynamic routing include:
- Lower administrative overhead: The device learns routing information automatically, which eliminates
the need for manual route definition;
- Increased network availability: During failure situations, dynamic routing can reroute traffic around the
failure automatically (the ability to react to failures when they occur can provide increased network
uptime); and
- Greater network scalability: The device easily manages network growth by dynamically learning routes
and calculating the best paths through a network.

57. OSPF configuration:

> show route protocol ospf

 58. Routing policy:

59. Default routing policies

BGP’s default import policy is to accept all routes from BGP neighbors and install them in the routing
table. BGP’s default export policy is to advertise all active BGP routes. For BGP, you can configure
import and export policies at the protocol, group, and neighbor levels.
The default OSPF import policy is to import all OSPF routes. As a link-state protocol, OSPF maintains
a consistent link-state database (LSDB) throughout each OSPF area by flooding link-state
advertisements (LSAs). You cannot apply policy to affect the maintenance of the local LSDB or the
flooding of LSAs. Additionally, you cannot apply policy that prevents the software from installing
internal (including interarea) routes in the routing table. (A link-state protocol assumes that all devices
have the same routing information for internal routes, which causes all devices to make consistent
forwarding decisions. If you could block internal routes from entering the routing table, you could
create routing loops or cause certain prefixes to become unreachable.) However, you can apply a policy
that blocks external routes.
The default OSPF export policy (which rejects everything) does not cause the system to stop flooding
LSAs through the area. Rather, the system always floods LSAs throughout the OSPF area, and the
routing policy cannot control that behavior. The default export policy simply blocks the advertising of
additional routes from other sources to OSPF neighbors. If you want to advertise other routes through
OSPF, you must configure an explicit export policy.
Because link-state protocols rely on all participating devices having consistent LSDBs, you can
configure import and export policies only at the protocol level.
The default policy for RIP is to import all routes learned from explicitly configured neighbors. The
software ignores routes learned from neighbors not explicitly defined within the configuration. By
default, the software does not export routes to RIP neighbors, including RIP routes. Thus, to advertise
any routes to RIP neighbors, you must configure an export policy that matches and accepts RIP routes
as shown in the following sample output:

[edit policy-options]
user@host# show
policy-statement export-rip-routes {
term match-rip-routes {
from protocol rip;
then accept;
}
}

For RIP, you can apply import policies at the protocol level and neighbor level, whereas you can
configure export policies only at the group level as shown in the following sample output:

[edit protocols rip]

user@host# show
group my-rip-group {
export export-rip-routes;
neighbor ge-0/0/1.0;
neighbor se-1/0/0.0;
}

60. Building blocks of routing policy:

 61. Routing policy with prefix list

You can use prefix lists in two ways in the from statement of routing policies. When referenced in a
prefix-list statement, routes match only if they exactly match one of the prefixes in the list. When
referenced in a prefix-list-filter statement, you can specify a match type of exact, longer, or orlonger to
be applied to the listed prefixes. You can also specify an optional action to be taken if the filter
matches. This action is executed immediately after the match occurs, and the then statement is not
evaluated.

62. Routing policy with route filter:

Route filters are lists of prefixes configured within a single routing policy or policy term. Unlike prefix
lists, they are not reusable but rather are specific to the policy or term in which they are configured.
They provide a few more match types for selecting prefixes. The following sections detail the available
match types. Similar to the prefix-list-filter statement, you can specify an optional action to be taken if
the route-filter statement matches. This action is executed immediately after the match occurs, and the
then statement is not evaluated.

63. Routing policy match types (for prefix-list-filter or route-filter):

- exact
- longer
- orlonger
- upto
- prefix-length-range
- through
 64. Routing policy common actions:

- accept
- reject
- default-action accept
- default-action reject
- next term
- next policy

65. Implementing policies require 2 steps:

- Defining routing policy

− Applying routing policy

Depending on the routing protocol, you can apply import and export policies at multiple levels of the
hierarchy. For example, you can apply import policies to BGP sessions at the neighbor, group, or
protocol level of the configuration hierarchy.
Not all protocols allow policy configuration at all these levels. For example, OSPF allows only
protocol-level export and import policies because of the need to maintain a globally consistent LSDB.
(This same requirement also limits the number of changes an OSPF import or export policy can make.)
Junos devices always apply the most specific (and only the most specific) import or export policy.
Therefore, import or export policies applied at higher levels of the configuration hierarchy apply to
lower levels of the configuration if no other policy configuration exists at that level. However, if you
configure a policy at a lower level, the system applies only that policy.

66. The Junos firewall filters are stateless in nature. Stateless firewall filters examine each packet
individually. Thus, unlike a stateful firewall that tracks connections and allows you to specify an
action to take on all packets within a flow, a stateless firewall filter has no concept of connections.
The stateless nature of these filters can impact the way you write your firewall filters. Because the
system does not keep state information on connections, you must explicitly allow traffic in both
directions for each connection that you want to permit. By contrast, stateful firewall filters only
require you to permit the initial connection and then automatically permit bidirectional
communications for this connection.

67. Building blocks of firewall filters:

The Junos firewall filters require at least one term. Firewall filters always include a default term that
discards all packets that the configuration does not explicitly permit through the defined terms. When
implementing firewall filters, keep in mind that the order of the terms is important and can impact the
results.

68. Firewall filter common match criteria:

 69. Firewall filter common actions:

No “next filter” for firewall filters

70. Implementing firewall filter require 2 steps:

- Defining firewall filter

− Applying the filter

You can also apply multiple filters to filter traffic using the input-list or output-list configuration
options in the [edit interfaces interface-name unit unit-number family inet filter] hierarchy.
 71. Filtering local traffic

The limit-ssh-access filter includes three distinct terms. The first term, named ssh-accept, permits all
SSH traffic from a defined prefix list named trusted. The trusted prefix list follows:

[edit policy-options]
user@host# show
prefix-list trusted {
172.27.102.0/24;
}

A second term named ssh-reject discards all other SSH traffic not sourced from the trusted prefix list. A
third term permits all other traffic. Your firewall filters must account for all management and protocol
traffic destined to the control plane. In our example, we have accomplished this accounting through the
use of the else-accept term.
If the else-accept term was not included in the filter, the software would discard all control and
management traffic not specifically allowed in the other terms. This process could cause quite a
disturbance in environments that use dynamic routing protocols, such as OSPF and BGP, as well as
management protocols like SNMP or NTP.
 72. In addition to dropping or accepting packets, firewall filters can also police or rate-limit traffic.
Rate policing enables you to limit the amount of traffic that passes into or out of an interface.
For example, the following firewall filter polices all TCP traffic that exceeds 10 Mbps with a 62500-
byte burst size. It places traffic that exceeds these limits in the best-effort forwarding class, whereas it
places traffic that conforms to these limits in the assured-forwarding forwarding class:

firewall {
policer class-example {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 62500;
}
then forwarding-class best-effort;
}

family inet {
filter example1 {
term policer-example {
from {
protocol tcp;
}
then {
policer class-example;
forwarding-class assured-forwarding;
accept;
}
}
}
}
}

73. Policing example:

The filter rate-limit-subnet polices traffic from the specified subnet. If the traffic sourced from the
specified subnet exceeds the limits, the system discards it. If the traffic does not exceed the specified
limits, the system accepts it.

74.

Defining the output filter:

Defining the input filter:

Applying the filters:

 Monitoring the results:

You can reset counter statistics with clear firewall filter filter-name command. The contents in
the firewall log clear when the system reboots.

75. Automated Antispoofing filters:

The unicast reverse path-forwarding (RPF) checks validate packet receipt on interfaces where the Junos
OS would expect to receive such traffic. By default, the system expects to receive traffic on a given
interface if it has an active route to the packet’s source address and if it received the packet on the
interface that is the next hop for the active route to the packet’s source address.
For example, if a device running the Junos OS receives a packet with a source address of 10.10.10.10
on interface ge-0/0/1.0 and you configured the device to perform the unicast RPF check on that
interface, it examines its routing table for the best route to 10.10.10.10. If this route lookup returns a
route for 10.10.10.0/24 with a next hop of ge-0/0/1.0, the packet passes the unicast RPF check and is
accepted. You can combine both unicast RPF and firewall filters on the same interface.
The Junos OS accomplishes unicast RPF checks by downloading additional information to the PFE.
Therefore, activating this feature increases PFE memory usage.

Strict Versus Loose

By default, devices running the Junos OS use the strict mode RPF check. You can instead configure it
to use the loose mode RPF check, which checks only to ensure a valid route to the source address exists
in the routing table.
However, in networks with a default route, a valid route to every IP address always exists; so, using a
loose mode check does not make sense in this environment. In general, using the default strict mode
provides the best results.

76. Active versus feasible paths

By default, when a Junos device performs its RPF check, it considers only the active routes to a given
destination. In networks where perfectly symmetric routing exists, the default behavior of considering
only active routes should work. However, in cases where the possibility of asymmetric routing
(different forward and reverse paths) exists, this design can cause legitimate traffic to be dropped. To
alleviate this issue, you can require that the system consider all feasible routes to a destination when it
performs the RPF check. In this mode, the system considers all routes it receives to a given prefix, even
if they are not the active route to the destination. In networks where the possibility of asymmetric
routing exists, you should activate this option.
You do not need to implement RPF checking on all devices within your network. Typically, you
configure only the edge device to perform RPF checking because all inbound and outbound spoofing
passes through that device. In the sample network shown on the graphic, R1 should be configured to
perform RPF checks on all three interfaces.
Unicast RPF configuration options vary between Junos devices. Check your product specific
documentation for detailed support information.

77. Fail filters

When a device running the Junos OS decides that a packet has failed the RPF check, it discards it by
default.
However, if you specify an optional fail filter, the device processes packets that fail the RPF check
through that filter prior to discarding them. In the fail filter, you can perform all the actions and action
modifiers you could in any other firewall filter, including accepting the traffic despite the packet failing
the RPF check. (Notably, if you choose to log packets in an input firewall filter, but the packets then
fail the RPF check, the software does not log them. To log these packets, you must log them in an RPF
fail filter.)
On most devices running the Junos OS, DHCP and Bootstrap Protocol (BOOTP) requests fail the RPF
checks. To allow these requests, you must configure a fail filter that permits traffic with a source
address of 0.0.0.0 and a destination address of 255.255.255.255. The graphic shows a sample fail filter
to include DHCP or BOOTP requests.

RPF examples:

In the example on the graphic, we enabled RPF in strict mode on all interfaces, and a Junos device
considers only the active paths to any prefix. The fail filter named rpf-dhcp applies to the ge-0/0/2 and
ge-0/0/3 interfaces. As you might remember, the configuration defines the rpf-dhcp fail-filter on the
previous graphic and permits DHCP and BOOTP requests. Now that you enabled RPF on all interfaces,
you do not need to include antispoofing terms within the firewall filters.

78.

By default, devices running the Junos operating system treat all transit traffic equally. The software
handles all traffic entering the device on a first-come, first-served basis. The device mixes together all
traffic transiting the system and places it in the same input and output queues, which means the traffic
is subject to the same potential for delays and drops. We refer to this method as best-effort traffic
processing.
The CoS features available to devices running the Junos OS allow differentiated services to network
traffic where best-effort traffic processing is insufficient. Several components to the CoS tool kit exist.
First, tools exist that allow the system to place traffic into different categories (named forwarding
classes) where the system provides the same services. Second, certain components allow the system to
treat traffic for each forwarding class in a unique manner.
Finally, additional tools allow the system to mark packets with their category so that other devices in
the network know how to categorize them.
CoS allows you to treat traffic differently by providing a minimum bandwidth guarantee, low latency,
low packet loss, or a combination of these things for categories of traffic. Consequently, deploying CoS
can make some applications perform better. However, it cannot increase the total bandwidth of a link or
decrease latency beyond the minimum limits imposed by the speed of light. CoS cannot eliminate
congestion within a network. CoS can, however, help you control how this congestion affects different
types of traffic.
Most devices running the Junos OS use the random early detection (RED) algorithm to avoid
congestion. Unlike the tail dropping method, the RED algorithm selectively drops random packets
before congestion becomes critical. Using the RED algorithm causes the affected TCP sessions to go
into slow-start mode, reducing the total amount of traffic clients attempt to transmit through the
congested link. Because of the algorithm used, higher-bandwidth data streams are the most likely to be
affected, whereas lower-bandwidth streams (including most interactive sessions) are the least likely to
be affected. Because the RED algorithm monitors the queue and drops packets based on statistical
probabilities rather than on when the queue is full, TCP global synchronization is avoidable.

79. Forwarding Classes

A forwarding class is an abstract concept devices running the Junos OS use to identify traffic
that should receive common treatment. The device associates traffic with a forwarding class during
the classification process. During output, the system assigns traffic to a particular output queue based
on forwarding class and rewrites behavior aggregate markers based on forwarding class.
Thinking of forwarding classes as output queues is tempting (and sometimes helpful) because a one-to-
one mapping of forwarding classes and output queues usually exists. However, that definition is not
necessarily true, because some platforms support more forwarding classes than queues. In these
cases, combining the concepts of forwarding classes and output queues can be confusing.

80. Loss Priority

You can associate a loss priority with a packet to tell the system which priority it should give to
dropping this packet during congestion. If you choose to configure RED, you can choose different drop
probabilities for traffic with different loss priorities.

81.
The chart on the graphic provides an overview of the way that CoS processing occurs in the Junos OS.
The arrowheads indicate the flow of information. Thus, if a process sets the forwarding class and loss
priority, the arrow points towards the forwarding class and loss priority box. If the process uses the
forwarding class and loss priority as input values, the arrow points away from the forwarding class and
loss priority box.The CoS processing chart illustrated on the graphic relates to some packet-based
Junos routing devices. The actual processing flow varies between platforms. Check your product-
specific documentation for details.
You can configure devices running the Junos OS to set the forwarding class and loss priority for a
given packet based on the values of certain header fields, including DiffServ code point (DSCP), IP
precedence, MPLS EXP, and IEEE 802.1p. Edge devices usually set these fields, which indicate th e
category of traffic. In this way, a device in the core does not need to recategorize traffic it receives from
an edge device. Because these fields indicate the category of traffic to which the packet belongs, we
refer to this kind of classification as a behavior aggregate (BA) classifier.
You can also configure Junos devices to set the forwarding class and loss priority with multifield
classifiers on both ingress and egress. You implement multifield classifiers using firewall filters.
Multifield classifiers allow you to select packets using all the selection criteria of a firewall filter and
set the forwarding class and loss priority within the then clause. You can also use ingress and egress
policers to modify the forwarding class and loss priority.
You can use forwarding policy options to implement CoS-based forwarding. When multiple equal-cost
paths to a destination exist, you can use CoS-based forwarding to specify which of the equal-cost paths
to use for different classes of traffic. Additionally, you can use forwarding policy options to reset the
forwarding class and loss priority for packets destined for particular prefixes.
Devices running the Junos OS use the forwarding class and loss priority on egress to assign traffic to
queues, implement the RED algorithm, and rewrite BA headers.
Note that CoS support varies between platforms running the Junos OS. For detailed support
information, consult the documentation for your specific platform.

82.

Two models for CoS deployment exist. In some networks, the only use for CoS is to provide
differentiated forwarding services through a single device. In other networks, the CoS deployment
provides differentiated services across multiple devices within a network.
With a deployment limited to a single device, the system typically classifies packets as they pass
through using a multifield classifier, then uses the classification to provide the configured service level,
and forwards the packets without any BA markings (DSCP, IP precedence, and so forth). However,
when the deployment crosses multiple devices, the classification usually occurs differently.
When you configure multiple devices in a network to use CoS to provide differentiated services, it is
usually beneficial to initially perform the classification on the edge device and then transmit that
classification within the network using a BA. In this model, the edge device classifies traffic using a
multifield classifier as traffic enters the network. When the edge device transmits the packet into the
network, it marks the packets with a BA. The remainder of the devices in the network read the BA and
automatically set the correct forwarding class and loss priority without a multifield classifier.
The use of BAs in network-wide CoS applications provides se veral advantages. First, it ensures
consistent CoS treatment of the traffic throughout the network. Second, it simplifies the task of creating
and maintaining accurate multifield classifiers on each system. Without BAs, each device must have a
multifield classifier capable of classifying all traffic entering the network, and you would need to
replicate any classification change on all other devices. Third, in the case of Ethernet, setting the
802.1p bits as a BA allows CoS-aware Ethernet switches to also provide differentiated services to the
traffic.
Packets are marked with BAs by setting bits that already exist within the Layer 3 header. Therefore,
you do not add additional overhead by setting a Layer 3 BA.

83. Multifield Classifier

You configure multifield classifiers just like regular firewall filters. You place the forwarding class and
loss priority in the then clause of each term. The default is to not change the forwarding class (from the
forwarding class assigned by the BA classifier or, if the packet was not classified by a BA classifier, the
default forwarding class).
Because Junos devices apply multifield classifiers after BA classifiers, multifield classifiers always
override the forwarding class and loss priority assigned by the BA.
84. Behavior Aggregate
You configure Junos devices to apply BA markers to packets leaving an interface by applying a rewrite
rule to the outbound interface. By default, the Junos OS does not modify a packet’s Layer 3 BA header
fields as it is sent through the device, so setting these fields is necessary only once, usually on the
device at the edge of the network.
However, the software does not preserve Layer 2 fields (such as the MPLS EXP and IEEE 802.1p
fields), so you must configure the system to reapply Layer 2 BA header fields on every appropriate
interface as a packet traverses the network.
You apply rewrite rules under the [edit class-of-service interfaces] hierarchy. For example, to apply
the default IP precedence markings, type set interface-name unit logical-unit-number rewrite-rules
inet-precedence default. You can apply rewrite rules at both Layer 2 and Layer 3; however, you cannot
apply both IP precedence and DSCP rules to the same packets, because they use the same bits in the IP
header.
Once a packet is marked with a BA, you can have downstream devices read those markers and
automatically assign packets the correct forwarding class and loss priority. To initiate this process, you
apply a BA classifier to the inbound interface. You apply BA classifiers to interfaces under the [edit
class-of-service interfaces] hierarchy.
For example, to apply the default IP precedence BA classifier, type “set interface-name unit logical-
unit-number classifiers inet-precedence default”. You can apply BA classifiers at both Layer 2 and
Layer 3; however, many platform-specific limitations govern the valid combinations of classifiers. See
the Junos Class of Service Configuration Guide for detailed information.
Using the default BA classifiers and rewrite rules ensures that traffic from Queues 0–3 maps correctly
to the corresponding forwarding classes throughout the network. You must use a custom classifier and
rewrite rule if you want to consistently map traffic across the network to more than Queues 0–3 or if
you want to use nondefault bit patterns for the CoS header fields. If you apply custom classifiers and
rewrite rules, you must apply these rules to all devices within the network to ensure consistent
classification.

85. Forwarding class definition

86. Scheduling overview

Priority
You can configure a transmission rate for each forwarding class. The transmission rate controls how
much bandwidth the tr affic associated with a given forwarding class can consume. By default, the
software assigns 95 percent of the bandwidth to the queue associated with the best-effort forwarding
class (typically Queue 0) and 5 percent of the bandwidth to the queue associated with the network-
control forwarding class (typically Queue 3).
The so ftware assigns all other queues a 0 transmission rate. By default, all queues can exceed their
assigned transmission rate if other queues are not fully utilizing their assigned rates, unless you
configure the transmission rate with the exact option.
The configured buffer size determines the size of each queue. By default, the software assigns 95
percent of the available buffer space to the queue associated with the best-effort forwarding class
(typically Queue 0), and it assigns 5 percent of the available buffer space to the queue associated with
the network-control forwarding class (typically Queue 3). By default, all other queues have 0 percent
of the available buffer space; therefore, if you use queues other than those associated with the best-
effort and network-control forwarding classes, you should assign buffers to those queues. As the buffer
fills, the likelihood that the RED algorithm will drop packets increases.

87. Creating scheduler maps

 88. Applying a scheduler map to an interface

89. See statistics:

#show class-of-service interface ge-0/0/3
#show interfaces ge-0/0/3 detail | find “Egress queues”
#show interfaces queue ge-0/0/3

Catatan JNCIA

1. Which two commands would you use to view OSPF routes? (Choose two)
- show route
- show route protocol ospf

2. Which two statements are true about the forwarding table? (Choose two)
- the forwarding table contains only active routes
- the forwarding table is used to process transit packets

3. A network administrator wants to verify the active alarms on interface so-0/0/0. Which command
displays this information?
- show interfaces detail

4. Which J-web tab do you use to add licenses to the devices?

- maintain

5. Referring to the exhibit, which command would you use to add an additional address to the ge-0/0/9
unit 0 interface?
[edit interfaces ge-0/0/9 unit 0]
 user@router#set family inet secondary-address 192.168.100.1/24

6. Which login class permission will allow a user to use the telnet utility?
- Network permission

7. Random Early Detection (RED) is associated with which component of the class of service?
- Scheduling

8. What is valid multicast MAC address?

- 01:00:5e:00:00:00 s/d 01:00:5e:7f:ff:ff (Ipv4, insert the low 23 bits of multicast
Ipv4 address to ethernet address)
- 33:33:xx:xx:xx:xx (Ipv6, insert the low 32 bits of multicast
Ipv6 address to ethernet address)

9. When configuring more than one archival sites, which statements are true?
- The system will not transfer to a secondary site unless the previous site fails

10. Which two fields are found in an ethernet frame header? (Choose two)
- Checksum
- Type

11. Which command will display only direct routes?

- show route inet.0 direct
3. You issue the ping interface t1-1/1/0 1.1.1.1 bypass-routing count 1000 rapid command, which
statement is correct?
- the bypass-routing parameter allow you to ping a host through an interface that has no route through it
4. Which command is used to display all output at once?
- show interfaces | no-more
5. Which three functions are available under the “maintain” tab of J-web? (Choose three):
- Reboot the system
- View and add licenses
- Download and delete log files
6. You have been asked to configure your router to send SNMP trap notification to the NMS
located at address 172.16.17.1. Which two commands are required?
- Set snmp trap-group my-trap-group targets 172.16.17.1
7. Which statements are true regarding the NTP on Junos devices?
- The Junos OS can provide a primary time reference
8. - Show system commit
- Clear system commit
9. To change the default number of configuration files:
- set system max-configurations-on-flash
10. If routing protocol daemon fails to start properly, the system has no default or static routes. To
reach other subnets, use command 'backup-router':
- set system backup router 10.0.1.129 destination 10.0.1.0/24
11. When using class-of-service, what is the benefit of configuring loss priority?
- It can be used by other CoS components to drop certain traffic on egress
12. What is the purpose of a network mask?
- It is used to define which parts of the IP address are allocated to host addresses and network prefixes
13. Which two protocols use UDP as a transport protocol by default?
- DHCP & RIP
14. You issue the command telnet interface ge-1/1/0 10.10.10.1 source 192.168.100.1 bypass-
routing. Which statement is correct?
- Return traffic for the telnet session might not arrive at interface ge-1/1/0
15. Which three statements are true about terms in a policy?
- The action is specified in a then statement
- Terms are optional in a policy
- The match condition can be identified with a from statement
16. Which two statements are true about terms in a routing policy?
- If a term does not contain a from statement, all routes match
A then statement is not mandatory in a term
20. Junos OS processes:
• Routing Protocol Daemon (rpd): The router’s protocols are controlled by the Routing Protocol
Daemon. Its functionality includes all protocol messages, routing table updates, and
implementation of routing policies.
• Device Control Daemon (dcd): The router’s interfaces are configured and maintained by the
Device Control Daemon. This process controls both the physical and logical properties of the
interfaces.
• Management Daemon (mgd): The Management Daemon process controls all user access to the
router. For example, the user’s CLI is a client of mgd.
• Chassis Daemon (chassisd): The Chassis Daemon process controls the properties of the router
itself, including the interaction of the passive midplane, the FPCs, and the control boards.
• Packet Forwarding Engine Daemon (pfed): The Packet Forwarding Engine Daemon process
controls the communication between the Packet Forwarding Engine and the Routing Engine.
For example, one of its functions is retrieving the interface input/output statistics from the
Packet Forwarding Engine.
21. JunOS software components:
 jkernel: The jkernel package contains the basic components of the JUNOS software operating
system.
 jbase: The jbase package contains additions to the JUNOS software since the last revision of
the jkernel package.
 jroute: The jroute package contains the software that operates on the Routing Engine. This
controls the Unicast routing protocols, the multicast routing protocols, and the Multiprotocol
Label Switching (MPLS) signaling protocols. The package also contains the software for some
daemons, such as mgd.
 jpfe: The jpfe package contains the Embedded OS software that controls the components of
the Packet Forwarding Engine.
 jdocs: The jdocs package contains the complete JUNOS software documentation set.
 jcrypto: The jcrypto package contains software that controls various security functions, such as
IP Security (IPSec) and Secure Shell (SSH). This package is available only in U.S. and
Canadian versions of the software.
 jbundle: The jbundle package is a single file that contains all of the other packages we discussed
previously.
22. JunOS software boot sequence:
 23. Packet forwarding engine (PFE) components:
− Embedded OS software operating the circuit boards themselves
− ASICs that are actually participating in packet forwarding, such as:
* PIC I/O Manager ASIC which performs error checking/detection =>
* I/O Manager which removes layer 2 headers, segments packets into 64-byte J-cells and sends them to
=>
* Inbound Distributed Buffer Manager which sends notification cell to =>
* Internet Processor which perfom forwarding table lookup