1. INTRODUCTION TO JUNIPER
ROUTERS
Juniper Networks Router Design
The central design principle of the Juniper Networks platform centers on a separation of the control and forwarding planes within the router. The Routing Engine and the Packet Forwarding Engine, respectively, represent these planes.
Routing Engine Overview
The Routing Engine in a Juniper Networks router is the central location for control of the system responsible for:
• Storing the JUNOS software & Performing software upgrades
• Monitoring and configuring the router.
• Troubleshooting tools like Telnet, ping, or traceroute
• Operating all routing protocols and making all routing table decisions, building a master routing table with the best path to each destination selected.
• Placing the best paths into the forwarding table on the Routing Engine and copying that same data into the forwarding table on the Packet Forwarding Engine.
Packet Forwarding Engine Overview
The Packet Forwarding Engine is the central location
responsible for:
• Data packet forwarding through the router.
• Controlling the router’s throughput speed and capacity by the specially designed hardware.
• Forwarding of data packets across any interface in the router.
The main portions of the Packet Forwarding Engine are the Physical Interface Card (PIC), the Flexible PIC Concentrator (FPIC), and a switching control board.
Physical Interface Card
The physical media in your network connects to the
Physical Interface Card (PIC) in the router.
Up to four individual PICs are contained on an FPC. A media-specific ASIC is located on each PIC.
Flexible PIC Concentrator
The Flexible PIC Concentrator (FPC) connects to both the switching control board and the router’s interfaces within the Packet Forwarding Engine.
Command-Line Interface
The JUNOS software CLI contains two main modes:
1. Operational and
2. Configuration.
Operational Mode
Operational mode displays the current router status, and used for verifying and troubleshooting the router. We enter operational mode on the router after a successful login attempt.
user@Juniper>
The default prompt for the JUNOS software is a combination of our username and the router hostname.
In addition, the > character tells that we are in operational mode.
As with most router operating systems, the JUNOS software uses a command hierarchy paradigm within operational mode.
Configuration Mode
Configuration mode provides with a method for altering the current environment.
We access the router’s configuration mode hierarchy with either the configure or edit command:
user@Juniper> edit or configure
Entering configuration mode
[edit]
user@Juniper#
The # character tells that we are in operational mode.
and our current level in the hierarchy is displayed above the router’s hostname. The [edit] portion of the output on Juniper tells us that we are at the top of the configuration hierarchy.
Context-Sensitive Help
The question mark (?) character gives context-sensitive help to navigate the command hierarchy.
We often use the help function at a specific hierarchy level, but it also provides assistance in locating specific options within a particular level.
For example, let’s locate the possible commands starting with the letter i within the show hierarchy:
user@Junieper> show i?
Possible completions:
igmp Show information about IGMP
ike Show IKE information
ilmi Show ILMI information
interfaces Show interface information
Command Completion
The JUNOS software CLI provides with a command completion function. Each unique combination of characters at a particular hierarchy level expands into the full command when we use either the spacebar or the Tab key.
user@Juniper> sh<space>ow
user@Juniper> sh<space>ow c<tab>
^
‘c’ is ambiguous.
Possible completions:
chassis Show chassis information
user@Juniper> show c
The router returns an error message telling us that there are multiple commands in the show hierarchy that start with the letter c. The output informs that ‘c’ is ambiguous and displays the possible commands that begin with the requested letter.
Getting Help from the Router
The jdocs Software Component package contains the entire JUNOS software documentation set on the router and is accessed through the user CLI.
We can find conceptual information on network topics by using the help topic command.
user@Juniper>help topic ospf area-backbone
Configure the Backbone Area
You must create a backbone area if your network consists of multiple areas. An ABR must have at least one interface in the backbone area, or it must have a virtual link to a router in the backbone area. The backbone comprises all area border routers and all routers that are not included in any other area. You configure all these routers by including the following area statement at the [edit protocolsospf] hierarchy level (for routing instances, include the statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level):
[edit protocols ospf]
area 0.0.0.0;
Getting Help from the Router
When we are ready to configure our router to support an OSPF area, we can view specific configuration information using the help reference command:
user@Juniper> help reference ospf area
area
Syntax
area area-id;
Hierarchy Level
[edit protocols ospf],
[edit routing-instances routing-instance-name protocols ospf]
Description
Specify the area identifier for this router to use when participating in OSPF routing. All routers in an area must use the same area identifier to establish adjacencies.
Specify multiple area statements to configure the router as an area border router. An area border router automatically summarizes routes between areas; use the area-range statement to configure route summarization. By definition, an area border router must be connected to the backbone area either through a physical link or through a virtual link. To create a virtual link, use the virtual-link statement.
Using the run Command
One very useful command that exists in configuration mode is run. When we use this command, the router allows us access to operational mode commands from within the configuration mode.
This flexibility enables us to easily verify information on the router.
user@Juniper# run show interfaces
Physical interface: so-0/0/0, Enabled, Physical link is Up
Interface index: 11, SNMP ifIndex: 13
Description: Sydney to Sao Paulo
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode,
Speed: OC3, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Using the Pipe through a command
display This option allows the router to show you additional data associated with the command.
except This option allows you to omit any line in the output containing the text string we provide.
find This option prompts the router to begin the output at the first occurrence of the text string we provide.
match This option prompts the router to display only lines in the output containing the text string we provide.
user@Juniper> show interfaces terse | match inet
fe-0/0/1.0 up up inet 10.0.31.1/24
set This option used in conjunction with display through two consecutive pipe through to display only lines in output containing text string which have been configured using set command
user@Juniper> show interfaces terse | match at-0/2/0 | display set
set interfaces at-0/2/0 unit 100 family inet address 10.0.1.1/24
Altering the Configuration
We enter new information into the configuration with the set command:
edit]
user@router# edit system
[edit system]
user@router# set host-name Juniper
The router now has a hostname of Juniper instead of router. The host-name variable is actually in the [edit system] hierarchy directory. We used the edit command to move into that directory and then configured the hostname. We can enter multiple directory names between the variable and use the set command as long as the directories are in a direct downward line. We move back to the top of the hierarchy using top command and change the hostname to Shiraz:
[edit system]
user@router# top
[edit]
user@router# set system host-name Shiraz
Using the set Command
If we begin configuring the router in the [edit system] directory. The possible options at that hierarchy level are:
[edit system]
user@router# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ authentication-order Order in which authentication methods are invoked
> backup-router IPv4 router to use while booting
Compress-configuration-files compress the router configuration files
When we examine the output closely, we might notice that some command options are preceded with a character—either an angle bracket (>) or a plus sign (+). The angle bracket is used to designate lower-level directories. The plus sign shows command variables you can configure that may have multiple values assigned.
Finally, some options do not have any characters preceding
them. These are configurable variables that may contain only a single possible value.
Altering the Configuration
We can view the changes we’ve made to the configuration by issuing the show command. This command displays any configuration in your current directory and all subdirectories below our current location. Using this command at the top of the hierarchy displays the entire configuration:
[edit]
user@router# show
version 5.3R1.2;
system {
host-name Shiraz;
To view the configuration just within the [edit system] directory, we may either move to that level with the edit command or add the hierarchy name to the show command from the top of the configuration:
[edit]
user@router# show system
host-name Shiraz;
Using the delete Command
We remove variables from the configuration with the delete command.
[edit]
user@router# delete system radius-server 172.30.10.1
[edit]
user@router# show system
host-name Shiraz;
root-authentication {
The Candidate Configuration
We’ve been changing the hostname of the router but that the router’s prompt hasn’t changed. This is because when we enter configuration mode, we are actually viewing (and changing) a file called the candidate configuration. The candidate configuration allows us to make configuration changes without causing operational changes to the current operating configuration, called the active configuration.
The router implements the changes in the candidate configuration when we use the commit command.
Using the compare Command
We may enter or exit configuration mode as many times as we wish without implementing our changes. If we do this several times, we may forget the exact changes we’ve made. In this situation, you can utilize a pipe command called compare in conjunction with the show command.
This prompts the router to compare the current candidate configuration to the active configuration running on the router. Differences between the two files are displayed with either a plus (+) or a minus (-) sign. The plus sign represents variables in the candidate configuration that are not present in the active configuration; we’ve added them to the file. The minus sign shows the opposite; we’ve deleted variables from the file. Let’s use this command on our router to see the difference between the candidate and active configurations:
[edit]
user@router# show | compare
[edit system]
- host-name router;
+ host-name Shiraz;
Using the commit Command
No changes we make to the router become effective until we use this command, Each time we commit our configuration, the router performs several tasks. The candidate configuration is examined for syntax and semantic problems and if any single problem exists,the candidate is not implemented.
If the candidate configuration possesses no errors, the router then implements the new configuration and makes changes to the operating environment as needed. Finally, the existing active configuration is saved on the router for future use.
[edit]
user@router# commit
commit complete
[edit]
user@Shiraz#
The commit complete message tells us that the process was successful. The commit process always implements the entire configuration at once. Any errors encountered during
a commit procedure result in no portion of the configuration changing.
Using the commit Command
Suppose that there was an error in the configuration the router does not implement the changes we made and supplies an error message informing us of the problem:
[edit]
user@router# commit
Policy error: Policy Advertise-Routes referenced but not defined
error: configuration check-out failed
[edit]
user@router#
In addition to the configuration check-out failed message, we see that the router’s hostname did not change. It appears that a policy called Advertise-Routes was referenced in configuration without ever being created in the first place.
[edit]
user@router# delete protocols ospf export Advertise-Routes
[edit]
user@router# commit
commit complete
[edit]
user@Shiraz#
Using the commit Command
The commit command has several options we may use to alter its operation.
[edit]
user@Shiraz# commit ?
Possible completions:
<[Enter]> Execute this command
and-quit Quit configuration mode if commit succeeds
at Time at which to activate the configuration
changes
check Check only, do not apply changes
confirmed Automatically rollback if not confirmed
synchronize Synchronize commit on both routing engines
| Pipe through a command
[edit]
user@Shiraz# commit
The router always remains in configuration mode, by default, after committing the configuration. We may exit back to operational mode with the addition of the and-quit option.
Using the commit Command
We can have the router verify the validity of the configuration without implementing the changes by using the check option. We might use this option after making a number of changes to the router and we want to be sure you have all of the required portions of the configuration in place. After running the syntax and semantic checks, the router does not implement the changes. We’re either notified of a successful check or your errors are reported to you:
[edit]
user@Shiraz# commit check
configuration check succeeds
[edit]
user@Shiraz#
The syntax and semantic checks the router performs verify only that information is present in the configuration that allows the router to implement the candidate file. No verification is ever completed to see if the configuration actually does what you wanted it to do in the network; that is our job.
Restoring an Old Configuration
When the router commits a configuration, it also saves the existing configuration to a file. This single file is not the only old configuration file saved, however. The JUNOS software saves up to nine previous configuration files for our use. The current active configuration is named junper.conf and is file number 0. The most recent active configuration is called juniper.conf.1.gz and is file number 1.
We place one of these files into the candidate configuration with the rollback command. To actually implement the old configuration file, we must still issue the commit command to make the candidate configuration
the new active configuration.
[edit]
user@Shiraz# rollback 1
load complete
[edit]
user@Shiraz# commit
commit complete
[edit]
user@Shiraz#
JUNOS Software Routing Tables
The JUNOS software provides multiple routing tables that are used to store routes for our network. Each table is represented within the output of the show route command. The software provides default tables that the operating system builds on an as-needed basis.
These tables include the following:
inet.0
inet.1
inet.2
inet.3
inet.4
inet6.0
mpls.0
bgp.l3vpn.0
bgp.l2vpn.0
routing-instance.inet.0
Each of the default tables contains separate route information.
JUNOS Software Routing Table
Table inet.0
Used to store IPv4 unicast routes.
Table inet.1
Used to store IPv4 multicast routes.
Table inet.2
Used to store IPv4 unicast routes used by multicast routing protocols to prevent routing loops. This process is called the Reverse Path Forwarding
Table inet.3
Contains the egress IP address of a MPLS label switched path (LSP).
Table inet.4
Stores information learned using the Multicast Source Discovery Protocol
JUNOS Software Routing Table
Table mpls.0
Actually not routing but is instead a switching table storing MPLS label
Table routing-instance.inet.0
Used to store MPLS VPN routes.
Table bgp.l3vpn.0
Stores routing information in a Layer 3 virtual private network
Table bgp.l2vpn.0
Stores routing information in a Layer 2 VPN environment.
Table inet6.0
Routing table contains IPv6 unicast routes.
JUNOS Software Preference Values
Each route in the routing table is assigned a protocol preference value. These values assist the table in selecting the active route when an individual prefix is installed from multiple sources. The preference value informs the routing table which protocols are more believable, with a lower value preferred. The valid value range is between 0 and 4,294,967,295 (2^32 -1).
JUNOS Software Preference Values
6. JUNIPER ROUTER PHYSICAL
INTERFACS
Types of Interfaces
A Juniper Networks platform contains two types of
interfaces. Permanent interfaces are always present in each router, while Transient interfaces are inserted in or removed from the router by a user.
Permanent Interfaces
The permanent interfaces on a Juniper Networks platform perform two vital roles—management and operation. The management functionality is performed primarily by theFxp0 interface. This Management Ethernet interface provides us with an out-of-band method for connecting to the router.
The fxp0 interface on a Juniper Networks router does not provide forwarding capabilities for transit data packets.
The fxp1 interface connects the Routing Engine to the Packet Forwarding Engine. This communications link is how routing protocol packets reach the Routing Engine to update the routing table. The forwarding table updates reach the Packet Forwarding Engine across this interface as well.
Types of Interfaces
Transient Interfaces
Transient interfaces receive a user’s data packet and then transmit that packet toward the final destination.
These interfaces are physically located on a Physical Interface Card (PIC) and can be inserted and removed from the router at any time. This property gives them their transient nature.
We must configure each transient interface before using it for operational purposes. In addition, the JUNOS software allows to configure transient interfaces that are not currently in the physical chassis. As the software activates the router’s configuration, it detects which interfaces are actually present and activates only those transient interfaces.
Should we install new physical interfaces in the router (for which some configuration exists), the JUNOS software activates the parameters for that transient interface.
Interface Naming
A router’s interfaces are located on a PIC. The PIC is located on a particular Flexible PIC Concentrator (FPC), which is inserted in a router’s chassis.
Interface Naming Structure
The JUNOS software follows a consistent naming structure of
media_type-fpc/pic/port.unit
The portions of the interface names include the following:
media_type
A two-character designator that uniquely identifies the type of physical interface
fpc
The physical slot in the chassis where the interface is located
pic
The slot on the FPC that contains the interface
port
The location on the PIC where the interface port is located
unit
The logical portion of the interface that contains properties, such as an IP address
Media Types
The media type portion of the interface name allows the JUNOS software to identify each physical interface. The two-letter representation relates closely to the actual type of interface used.
ae
Aggregated Ethernet interface
as
Aggregated SONET/SDH interface
at
Asynchronous Transfer Mode (ATM) interface
ds
DS0 interface (including Multichannelized DS-3 interfaces)
e1
E1 interface (including Channelized STM-1 to E1 interfaces)
e3
E3 interface
es
Encryption interface
fe
Fast Ethernet interface
Media Types
fxp
Management and Internal Ethernet interfaces
ge
Gigabit Ethernet interface
gr
Generic Route Encapsulation tunnel interface
ip
IP-over-IP encapsulation tunnel interface
lo
Loopback interface
so
SONET/SDH interface
t1
T1 interface (including Channelized DS-3)
t3
T3 interface (including Channelized OC-12 interfaces)
FPC Slot Numbers
The FPC slots in a Juniper Networks router begin at 0. Each router model contains a specific number of slots that range from 1 to 8. The slot number is printed directly on the router chassis. Figure below shows the FPC slots on the M40, M40e, M160, T320, and T640 platforms. These are numbered 0 through 7 in a left-to-right fashion.
FPC Slot Numbers
Four-slot chassis
FPC Slot Numbers
The remaining router platforms, M5 and M10, share the same chassis platform, with each model supporting a different number of slots. The M5 has a single slot, numbered 0, while theM10 has two slots, numbered 0 and 1.
M5 and M10 chassis platforms
PIC Slot Numbers
PIC slot numbers also begin at 0 and have a maximum value of 3. They are physically printed on the FPC and represent the location of the PIC on the FPC module. The numbering schemefollows the physical layout of the Juniper Networks platforms. The vertical FPC slots use the same numbering, while the horizontal slots use a different one.
PIC slot numbering
PIC Port Numbers
The physical media cable in your network (for example, Ethernet or SONET) actually connects to a port on the PIC. These ports are also numbered and represent a portion of the interface naming structure. The number of ports on a PIC varies, as does the numbering pattern on the PIC itself.
PIC port numbering
Logical Unit and Channel Numbers
The logical unit portion of the interface name corresponds to unit number assigned within the interface configuration hierarchy. This value is a number in the range of 0 to 16384. Interfaces within the JUNOS software always contain a logical configuration, so some value is always present in the naming scheme.
Some physical interfaces use a channel number instead of a unit number to represent their logical configuration. For example, a nonconcatenated (that is, channelized) SONET/SDH OC-48interface has four OC-12 channels, numbered 0 through 3. A channelized OC-12 interface has 12 DS-3 channels, numbered 0 through 11.
Interface Naming Examples
Suppose a router has two OC-3 PICs in slots 0 and 1 on an FPC in slot 1. Each of the PICs contains two ports. The names of these interfaces are:
so-1/0/0.0
so-1/0/1.0
so-1/1/0.0
so-1/1/1.0
Interface Properties
Interfaces in the JUNOS software contain both physical and logical properties. The actual media type (such as Ethernet or SONET) often determines the physical properties of the interface. An interface’s logical properties represent the Layer 3 routing and Layer 2 transmission parameters needed to operate the interface in a network.
Physical Properties
Each interface in the router inherits certain default values for its physical properties. When the JUNOS software activates an interface, it assigns these values.
Interface Properties
Connecting to another Vendor’s Router
The physical interface defaults do not always match
the operational parameters of another vendor. The default encapsulation type for a SONET link within the JUNOS software is the Point to- Point Protocol (PPP). A Cisco Systems router, on the other hand, uses a Cisco proprietary format of the High-Level Data Link Control (HDLC) protocol. The JUNOS software supports this HDLC format on point-to-point interfaces using the keyword cisco-hdlc.
Logical Properties
Each and every interface within the JUNOS software requires at least one logical interface, called a unit. This is where all addressing and protocol information is configured. Some physical encapsulations allow only a single logical unit. PPP and Cisco-HDLC fall into this category.
Logical interfaces, such as the loopback, and non-VLAN Ethernet also provide for only one logical unit. In both situations, the logical interface is assigned a unit value of 0.
Multiple logical interface units are often used in ATM, Frame Relay, and VLAN tagged Ethernet networks. In these cases, each logical unit is assigned a Virtual Circuit Identifier (VCI), Data-Link Connection Identifier (DLCI), or Virtual Local Area Network (VLAN) number, respectively.
Common logical interface properties include a protocol family, logical Layer 3 addressing, MTU, and virtual circuit (Layer 2) addressing information.
Logical Properties
Protocol MTU
An MTU value can be configured for each logical unit in the router. The default values vary for each physical media type as well as for the protocol family configured.
Point-to-point interfaces When you’re using an encapsulation type of PPP, Cisco-HDLC, ATM, or Frame Relay, the default MTU for the inet and iso protocols is 4470 bytes. The mpls protocol family uses a value of 4458 bytes.
Broadcast interfaces Both a Gigabit Ethernet and a Fast Ethernet interface share the same properties for protocol MTU sizes. The inet family uses 1500 bytes, the iso family uses 1497 bytes, and the mpls family uses 1488 bytes.
The interface MTU is the largest size packet able to be sent on the physical media. This value includes all Layer 2 overhead information, such as the destination MAC address on Ethernet, or the labels in an MPLS environment. The Cyclic Redundancy Check (CRC) information is not included in this value, however.
Protocol Families
Each logical interface in the JUNOS software has the ability to support one or more protocol families. These families enable the logical interface to accept and process data packets for therouter. Without their configuration, the interface drops any unknown transmissions.
Currently four possible protocol families are available for use:
inet Supports IP version 4 (IPv4) packets.
inet6 Supports IP version 6 (IPv6) data packets
iso The Intermediate System to Intermediate System (IS-IS) routing protocol uses a data link encapsulation defined by the International Standards Organization (ISO). The iso protocol family allows the processing of these packet types.
mpls Support for processing packets encoded with a Multiprotocol Label Switching (MPLS) label. This label information allows the router to forward the data packet.
Protocol Addresses
A protocol address is a logical Layer 3 value used to route user packets in a network. For example, an IPv4 address of 192.168.1.1 /24 is a protocol address. The JUNOS software allows addressing for the inet, inet6, and iso protocol families.
The inet family provides the capability to assign multiple addresses to each logical unit, with each address equally represented on the interface.
primary address and the preferred address
A single primary address is assigned to each interface. By default, it is the lowest numerical IP address configured.Primary address is used as the source address of a packet when the destination address is not local to a configured subnet.
Unlike the primary address, a logical unit may have multiple preferred addresses at the same time. The preferred address is used when an interface has two addresses configured within thesame subnet. The default selection of the preferred address is similar to the primary address in that the lowest numerical prefix is selected.
Disabling/Deactivating Interface
Interfaces within the JUNOS software are automatically enabled for operation when configured in the router. To stop the operation of a particular interface, we may use one of two CLI commands—disable or deactivate. Both halt an interface without removing the current configuration in the router. This allows us to easily restart the interface when needed.
The difference between the commands is how the JUNOS software uses the configuration when the commit command is issued.
Using the disable command at the [edit interfaces
interface-name] hierarchy level allows the router to use the interface configuration. Operationally, the interface is viewed as down, or administratively disabled.
The deactivate command places an inactive tag next to the configuration in the router. As the commit command is issued, the JUNOS software completely ignores the configuration. Operationally, the interface has no configuration
7. CLI COMMANDS FOR INTERFACES
Useful Interface Commands
show interfaces int_name extensive
The show interfaces extensive command displays L1,L2 & L3 information about an interface
show interfaces int_name terse
The show interfaces terse command displays Admin & Link Status information about an interface
monitor interface int_name
The monitor interface interface-name command displays per-second real-time statistics for a physical interface. The output of this command shows how often each field has changed since the command was executed. We can also view common interface failures, such as alarms, errors, or loopback settings.
clear interfaces statistics int_name
Clears the counters on the interface
Configuration Examples
All interface configurations are completed at the [edit interfaces] hierarchy level. A generic interface configuration looks like this:
interfaces {
interface-name {
physical-properties;
unit unit-number {
logical-properties;
}
}
}
The Logical properties of the connections will be configured under the Family Unit
Adding IP Address for ATM Connection at-0/2/0.100
[edit interfaces at-0/2/0.100]
user@Juniper# set unit 100 family inet address 10.0.1.1/24
Deleting IP Address for ATM Connection at-0/2/0.100
[edit interfaces at-0/2/0.100]
user@Juniper# deletes unit 100 family inet address 10.0.1.1/24
Operational Changes
Deactivating an interface
user@Juniper> show interfaces so-2/0/0 terse
Interface Admin Link Proto Local Remote
so-2/0/0 up up
so-2/0/0.0 up up inet 10.0.2.1/30
[edit interfaces]
user@Juniper# deactivate so-2/0/0
[edit interfaces]
user@Juniper# show
inactive: so-2/0/0 {
[edit interfaces]
user@Juniper# activate so-2/0/0
[edit interfaces]
user@Juniper# show
so-2/0/0 {
Operational Changes
Disabling an interface
[edit interfaces]
user@Juniper# set fxp0 disable
[edit interfaces]
user@Juniper> show interfaces fxp0 terse
Interface Admin Link Proto Local Remote
fxp0 down up
fxp0.0 down down inet 172.16.1.1/24
[edit interfaces]
user@Juniper# delete fxp0 disable
user@Juniper> show interfaces fxp0 terse
Interface Admin Link Proto Local Remote
fxp0 down up
fxp0.0 down up inet 172.16.1.1/24
8. CLI COMMANDS FOR STATIC ROUTES
Configuration Examples
Adding Static Route for 192.168.16.0 /24 network 1.1.1.1
[edit routing-options]
user@Juniper# set static route 192.168.16/24 next-hop 1.1.1.1
[edit routing-options]
user@Juniper# show
static {
route 192.168.16.0/24 next-hop 1.1.1.1;
}
user@Juniper> show route protocol static | match 192.168.16.0
inet.0: 10 destinations, 15 routes (10 active, 0 holddown,
+ = Active Route, – = Last Active, * = Both
192.168.16.0/24 *[Static/5] 00:02:28
to 1.1.1.1 via fe-0/0/0.0
Configuration Examples
Deleting Static Route for 192.168.16.0 /24 network 1.1.1.1
[edit routing-options]
user@Juniper# delete static route 192.168.16/24 next-hop 1.1.1.1
[edit routing-options]
Adding Static Null Route for 192.168.16.1 /32
user@Juniper# set static route 192.168.16.1/32 discard / reject
[edit routing-options]
A reject next hop will prompt the local router to send an ICMP message of “Destination Host Unreachable” to the source of the IP packet. This message notifies the remote router that the data packet was dropped from the network. A discard next hop does not send an ICMP message back to the source; it silently drops the packet from the network.
9. CLI COMMANDS FOR BGP
Configuration Examples
Configuration of the BGP Peer on Juniper Router for the below listed parameters:
Neighbor IP: 192.168.1.2
Neighbor AS::65000
Peer Type: External (EBGP)
Peer Description: Customer
Peer Import:: Peer-Neighbor IP—Standard Syntax
(peer-192.168.1.2)
remove-private—Standard (Removes Private AS
Information in
the BGP Advertisements)
Configuration Examples
User@Juniper # set protocols bgp group peer-192.168.1.2 neighbor 192.168.1.2
User@Juniper # set protocols bgp group peer-192.168.1.2 peer-as 65000
User@Juniper# set protocols bgp group peer-192.168.1.2 type external
User@Juniper# set protocols bgp group peer-192.168.1.2 description Customer
User@Juniper# set protocols bgp group peer-192.168.1.2 import peer-192.168.1.2
User@Juniper# set protocols bgp group peer-192.168.1.2 remove-private
Mandatory to add BGP Peer IP in the Juniper Firewall Filter to protect BGP routing Engine in case of attack
[edit]
User@Juniper#
User@Juniper # set firewall filter internet term bgp from source-address 192.168.1.2 /32
Configuration Examples
Verifying BGP Peer Config
user@Juiper> show configuration protocols bgp group peer-192.168.1.2
type external;
import [ peer-192.168.1.2 customer bb2 ];
family inet {
any {
prefix-limit {
maximum 116;
teardown 90;
}
}
}
export [ send-default none ];
remove-private;
peer-as 65000;
neighbor 192.168.1.2;
[edit]
Cheat Sheet
FOR VERIFYING BGP STATE & RECEIVED PREFIXES STATS
user@Juniper> show bgp neighbor 172.16.1.1
Peer: 172.16.1.1+179 AS 10 Local: 172.16.1.2+1028 AS 20
Type: External State: Established Flags: <>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference HoldTime PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.2.2 Local ID: 192.168.5.5 Active Holdtime: 90
Keepalive Interval: 30
Local Interface: so-0/0/1.0
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
Send state: in sync
Active prefixes: 4
Received prefixes: 4
Suppressed due to damping: 0
Last traffic (seconds): Received 13 Sent 13 Checked 13
Input messages: Total 438 Updates 4 Refreshes 0 Octets 8473
Output messages: Total 440 Updates 4 Refreshes 0 Octets 8526
Output Queue[0]: 0
If Active Prefixes not equal to Received Prefixes then need to check Route Filter for why few prefixes dropped
Cheat Sheet
FOR VERIFYING ROUTES PLACED IN ROUTING TABLE ADVERTISED FROM A PEER
user@Juniper> show route receive-protocol bgp 192.168.7.7
inet.0: 26 destinations, 27 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.20.3.0/24
192.168.7.7 0 100 I
10.20.4.0/24
192.168.7.7 0 100 I
FOR VERIFYING ROUTES RECEIVED FROM A PEER BUT NOT PLACED IN ROUTING TABLE
user@Juniper> show route receive-protocol bgp 192.168.5.5
inet.0: 21 destinations, 22 routes (13 active, 0 holddown, 8 hidden)
user@Juniper>
user@Juniper> show route hidden | match 192.168.5.5
inet.0: 21 destinations, 22 routes (13 active, 0 holddown, 8 hidden)
+ = Active Route, – = Last Active, * = Both
10.10.1.0/24 [BGP/170] 01:04:41, MED 0, localpref 100, from 192.168.5.5
AS path: 10 I
Unusable
user@Juniper> show route inactive-prefixes | match 192.168.5.5
Cheat Sheet
FOR VERIFYING ROUTES ADVERTISED TO A PEER
user@Juniper> show route advertising-protocol bgp 192.168.5.5
inet.0: 21 destinations, 22 routes (13 active, 0 holddown, 8 hidden)
+ = Active Route, – = Last Active, * = Both
10.20.3.0/24
Self 0 100 I
10.20.4.0/24
Self 0 100 I
FOR VERIFYING ROUTE-FILTER FOR A PEER
user@Juniper> show policy peer-192.168.5.5
FOR VERIFYING ROUTES IN THE ROUTING TABLE WITH A PARTICULAR AS-NO IN THE AS-PATH FOR A PEER
user@Juniper> show route aspath-regex “.*AS-NO.*” | match 192.168.5.5
FOR VERIFYING ROUTES IN THE ROUTING TABLE FOR A PARTICULAR ROUTING-INSTANCE
user@Juniper>show route table instance_name.inet.0
Cheat Sheet
FOR CLEARING BGP PEER SESSION
Hard Clear: Restarting BGP Peer Session
user@Juniper> clear bgp neighbor 192.168.5.5
Soft Clear: Refreshing Inbound & Outbound Routes
user@Juniper> clear bgp neighbor 192.168.5.5 soft
Verifying CLI Commands History
user@Juniper> show log cli-commands | match interface_name / interface_IP