Virtually Multiplicity

Last Session, we left off with configuring ISDN as a backup link and talked a bit about DSL...In this lastest installment on our road to Juniper certification, we will explore Multi-link PPP, Generic Routing Encapsulation or GRE, and Virtual Router Redundancy Protocol.(VRRP) We will then move to some common interface troubleshooting techniques.



PPP has a lot going for it in terms of a protocol. In addition to authentication and support for multiple protocol types, individual PPP links can be combined using the Multi-Link Point-to-Point protocol. RFC 1990 details the "software bundling" of multiple PPP links together as one. JUNOS allows for up to eight physical interface links to be assigned to a bundle.



In order to support MLPPP on Juniper equipment, you need a hardware PIC in the case of M/T Series routers or appropriate software support in the J-Series platform. We will discuss configuration steps next:

1. Configure the pseudolink interface appropriate for your routing platform



2. Our new link will have all the properties of a regular PPP interface but will have a multi-link ppp encapsulation. The links will be assigned as multiple unit numbers. In the following configuration, the bundle will be assigned to unit 0:

ls0-0/0/0{

unit 0{

encapsulation multilink-ppp;

family inet{

address 172.8.17.30/30;

}
}

}

Next we will configure the links and link service interface. Interfaces se-1/0/0 and se-1/0/1 are added to the bundle on the ls-0/0/0 interface. (Our link service logical interface.)

se1/0/0{

unit 0{

family mlppp{

bundle ls-0/0/0;

}

}

}

se-0/0/1{

unit 0{

family mlppp{

bundle ls-0/0/0.0;

}

}

}

We can verify the status of our newly created bundle with the show interfaces terse command. The link service interface will remain in the up state as long as one of our physical interfaces is up. This behaviour can be modified with the minimum-links command in the link service interface hierarchy.

While we are on the subject of protocols and their associated encapsulations, let's delve into Generic Routing Encapsulation. GRE is a "stateless" tunneling protocol. Stateless in this context refers to a connection that is created with no monitoring of the endpoint or other tunnel endpoints. It is mostly used in conjunction with Virtual Private networks or VPNs. It can also be used to establish back up links to a location or to carry non IP traffic over an IP network (Frame Relay,ATM, or Ethernet.)

In order to create a GRE tunnel, a Juniper device must be equipped with the Layer 2 services PIC (M and T-Series) or is native in the J-Series platform. When you activate the service, a pseudo interface called 'gr' is created. You need three things in terms of configuration to make our new interface useful:

1. inteface must be configured with the source IP for the GRE packets (where they are originating from)


2. The tunnel's destination


3. Protocols that the GRE will carry (An IP address for the 'gr' interface is not required, but is good to have for management purposes.)

Note: Remember the gre interface is used by the router internally and should not be configured to be a GRE tunnel.

Here is an example of a configured gr interface for GRE:

gr-0/0/0{

unit 0

tunnel{

source 10.20.1.38;

destination 172.66.13.1

}

family inet

}

}

Now all that remains, is to map traffic for use by the GRE tunnel. You can do this with a static route with a destination next-hop address of the gr interface, or using a protocol such as OSPF(Open Shortest Path First.)

My Lines, My Lines!

In the last section we left off with Frame Relay. In this section we will explore even more transport media such as DSL and ISDN, and others.



Acronym of the Moment:



DSLAM: Digital Subscriber Line Access Multiplexer (Concentrates multiple DSL connections together)

ADSL: Asymmetrical Digital Subscriber Line

POTS: Plain Old Telephone Service

SHDSL: Symmetric High speed Digital Subscriber Line

PPPoE: Point to Point Over Ethernet



DSL is one of the most popular connection media for consumers and companies alike. DSL runs over existing POTS wiring with the use of a DSL modem. This connection feeds into a telephone company's DSLAM. Some J-Series routers have support for ADSL using PPPoE over ATM applications. The interfaces will appear to be ATM connections, but do not support native ATM, only ATM over DSL. Let's take a look at the following example:
[edit]
labuser@labrouter#show interfaces
at-6/0/0 {
encapsulation ethernet-over-atm;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0; {
encapsulation ppp-over-ether-over atm-llc;
vci 0.39;
}
}
Our J-Series Lab router has an ADSL Annex A PIM installed on slot 6. (Annex A is DSL over POTS, Annex B is DSL over ISDN respectively.) The lab router will be a client to our phone company's DSL multiplexer so that the Lab router can act as a DSL modem. As shown in the example above, we are using PPPoe over ATM for our DSL. We need configuration for the physical interface at-6/0/0. and a logical interface. You will notice in our configuration that there is a vci and vpi statement.
VPI is Virtual Path Identifier and VCI is a Virtual Channel Identifier and these must be the same as what is configured at the DSLAM. The remainder of the parameters can be learned from the DSLAM with the operating mode auto statement.

"On to Our Logical Interface...."

Now that we have our ATM interface, we now will configure an internal PPPoE interface and its' mappings. We need to map our physical interface where PPPoE will be running, the access server, and underlying requested services. See Below:

pp0{
unit 0{
pppoe-options{
underlying-interface at-6/0/0.0;
access-concentrator labisp;
service-name pppserv@labisp;
auto-reconnect 5;
}
family inet{
negotiate-address
}
}
}
}
You can verify your new connection with run show pppoe interfaces.

ISDN is a protocol designed to run over the public telephone network. Like Frame Relay, ISDN is seeing less deployment with the emergence of DSL and other broadband technologies. Just like in our previous example, ISDN on a Juniper router requires a logical interface and a physical one. Our physical interface, br which will contain the dialing number and switch type. In our lab router br-0/0/4 will be configured with a switch type of etsi for Europe NET3. Also, a dial pool we create will map our physical interface to a logical unit in our dialer interface. First we configure our physical interface:

[edit interfaces]
br-0/0/4{
isdn-options{
switch-type etsi;
}
dialer-options{
pool labpool1;
}
}
Now on to the dialer interface which contains our number we need a number to dial, an IP address, and our pool mapping our logical interface to br-0/0/4... dl0 will be our dialer interface and we will set up our "dialer filter" to establish a connection only when there is "interesting traffic" (More on this in a moment.)

dl0{
unit 0{
dialer-options{
pool labpool1;
dial-string 5559999;
}
family inet{
filter{
dialer dial_filter;
}
address 12.12.20.1/24;
}
}
}

Here is our simple dialer filter "dial_filter" that brings up our connection any time packets are destined for 12.12.20.2 using the note action. All other destinations are ignored in term b without a corresponding from statement.

[edit]
firewall{
family inet{
dialer-filter dial_filter{
term a{
from{
destination-address{
12.12.20.1/24
}
}
then note;
}
term b{
then ignore;
}
}
}
}

ISDN is commonly used as a backup link for other interfaces if they fail. To configure the ISDN as backup, the dl0 interface can be mapped to our interface requiring backup. The interface we are backing up is fe-0/0/1:

[edit interfaces fe-0/0/1 unit 0]
backup-options{
interface dl0.0;
}
Presumably, the ISDN interface would stay up even if the entire path is not reachable. It is also wise to configure a list of reachable IP networks when interfaces are working normally. In our lab example, a single network of 13.13.20.0/24 is used to verify connectivity with the use of a watch list.

dl0{
unit 0{
dialer-options{
pool labpool1;
dial-string 5559999;
watch-list{
13.13.20.0/24;
}
}
family inet{
address 13.13.20.1/24;
}
}
}
You can make calls between ISDN devices. To accept a call, an incoming dialer map can be configured on dl0:
dl0{
unit 0{
dialer-options{
pool labpool1;
incoming-map;
watch-list{
caller 384030;
}
}
family inet{
address 12.12.20.1/24;
}
}
}
You can use the show isdn and show dialer commands to verify the interface is working. show isdn will verify Layers 1-3 connectivity and switch type. show dialer will indicate per channel status.

VLAN Tagging, You're It!

Let's continue on from the previous post with a discussion of VLAN Tagging. VLAN tagging is a mechanism to denote a way to tell networking devices what virtual network to ship a particular packet to and from. Many times, networking devices can be geographically distant. With VLANs interfaces can "appear" to be part of the same network. To configure vlan tagging for our interface from the last session:

1. root@routername#configure
2. edit interfaces fe-2/0/1
3. set vlan-tagging
4. Next we add a VLAN ID of 100 on our logical unit 0: root@routername#set unit 0 vlan-id 100
5. show our new configuration with the show command

Caution! Juniper routers DO NOT have a default VLAN! Every VLAN must be explicitly configured. Many switches have a default VLAN of 1. Make sure to configure a vlan-id of 1 for connectivity.

It is a common "best practice" to have th einterface unit number be the same as the VLAN ID, so we change the unit number with the rename unit 0 to unit 100 command. Let's activate the change with root@routername#commit To retest for connectivity, issue run ping 10.10.20.121 count 3 When it succeeds, we can view our interface with run show interfaces terse fe-2/0/1

Now let us move on to T1 interfaces...

T1 is a very extensively used signaling method in North America. For point-to-point links on Juniper devices, the default encapsulation is PPP. This differs with many other vendor's equipment whose default encapsulation is Cisco HDLC (There is a standard HDLC protocol, but it did not have multi-protocol support. Cisco's HDLC implementation is "officially" proprietary, but the workings are well known and supported by many vendors.) Here is a configuration example for a T1 interface.

1. edit interfaces t1-0/0/2
2. set encapsulation cisco-hdlc
3. set unit 0 family inet address 10.10.20.122/24
4. commit

Acronyms of the Moment:

DTE: Data Terminal Equipment

DCE: Data-circuit Terminal Equipment

"Serial is not Breakfast!"

Serial interfaces have a variety of physical forms such as, V.35, X.21, and EIA 530. V.35 is most commonly seen in the United States and X.21 is common in Japan. All serial interfaces define their connection in terms of a DCE and a DTE. DCE devices provide clocking signals, encoding, and signal conversion to the DTE. Normally routers will default to DTE mode by default until wired up and a DCE(female cable) is detected.

Let's view our DCE status with the run show interfaces se-1/0/0 extensive find "serial media" command. The DTE/DCE detection can be found in the local mode field.

Note: Proper care must be taken to configure the correct clock mode. Without proper clocking, the link status will be considered "down."

Under the [serial-options] in the [edit interfaces] hierarchy a clocking-mode may be set. The default is internal or loop timed, and the clock rate is 8Mhz

"Serial with Frame Relay"

Frame Relay is a Layer 2 enapsulation method that allows a LAN connection via a Wide Area Network Connection (WAN) to a Frame Relay node. Frame Relay uses Permanent Virtual Circuit (PVC) tunnelling over an Internet Service Provider's infrastructure to provide the LAN's connectivity.

Acronyms of the Moment:

DSL: Digital Subscriber Line

DLCI: Data Link Circuit Identifier

With the widespread emergence of other broadband technologies such as DSL and IP networks, Frame Relay is mostly seen in rural areas as a cheap "always on" service. To establish a Frame Relay connection, the frame-relay encapsualtion is set, along with a local circuit identifier for the PVC in the form of a DLCI.

1. edit interface se-1/0/0
2. set unit 645 family inet address 172.17.24.130/30
3. set encapsulation frame-relay
4. set dlci 645
5. commit

Note: No routers were harmed in the making of this blog ;-)

Logical Versus Physical

All interfaces in JUNOS and most other networking devices have two properties; logical and physical. Physical properties belong to an entire physical port, whereas logical properties correspond to the portion of the interface represented by a unit or channel number. Depending on the type of physical port installed, a large number of properties can be configured. We will detail some of the most common here:

• Clocking: Aligns bits as they are transmitted out of the interface. A clock signal can be supplied by a Service Provider or by the router.



• Encapsulation: Layer 2 encapsulation used on the interface. Examples include Frame Relay, Point to Point Protocol or PPP, and Cisco Highlevel Data Link Control or HDLC



• MTU: Maximum Transmission Unit, which is the maximum size of the frame transmitted from the interface.



• Keepalives: Used to verify the operation of the interface. Most encapsulations enable keepalives by default, but they can be disabled to aid troubleshooting.



• Layer 1/2 Options: Various bit and byte settings for the interface media such as framing, flow control, and source address filters

All router interfaces sending and recieving traffic or packets require a logical unit to be configured. This way, an interface may be divided into multiple logical interfaces (subinterfaces in Cisco) This division then could be used to create multiple Virtual Local Area Networks or VLANs with their own logical unit. Note: Many router vendors do not require a subinterface or logical unit on every physical interface but a Juniper router does. Even point-to-point interfaces and non VLAN tagged interfaces need a logical unit to be configured.

In JUNOS, unit numbers MUST be configured before any other logical configuration is applied. Here are some of the common logical properties that can be configured.

• Protocol Family refers to the Layer 3 protocols that can be sent and recieved on this interface. The most common is family inet. Other protocol amilies include IPv6, Multi Protocol Label Switching or MPLS, and ISO (Intermediate System to Intermediate System IS-IS)



• Protocol Address: Layer 3 family address such as family inet (IP address)



• Virtual Circuit Address: Circuit identifier use when an interface is divided logically. Logical interfaces include VLAN IDs, Frame Relay Data Link Connection Identifier or DLCI, or ATM virtual path/Virtual Connection Identifiers (VP/VCI)



• Logical unit numbers can range from 0-16,385



• The best practice is to keep circuit address the same as the unit number for ease of toubleshooting.



• Note: If you are configuring a point to point interface the unit number MUST be zero!

"More Interface Configuration Examples"

Let's demonstrate configuring a Fast Ethernet interface in JUNOS:

Note: Remember interfaces in JUNOS are 'automatically enabled' when the physical connection is wired. So, after cabling up, we check the status of our Fast Ethernet Interface:

1. root@routername> show interfaces terse fe-2/0/1


2. Once we determine that the interface is up, we enter configuration mode: root@routername#configure
   
3. We are brought to the [edit] hierarchy and now, to edit our interface: root@routername# edit interfaces fe-2/0/1


4. Establish the unit: root@routername#set unit 0 family inet address 10.10.20.122/24


5. JUNOS software requires a mask for every IP address in the classless CIDR notation (Classless Inter Domain Routing). This is denoted by the / (slash)


6. Execute a show command: root@routername#show to verify our newly created interface


7. Activate our new changes with commit: root@routername# commit-and-quit


8. Let's verify our newly created interface with ping: root@routername#ping 10.10.20.121 count 3

The reason for the count command with ping is, a Juniper router will send an endless number of pings unless a number of packets is specified or you use Ctrl-C

We will all become white rappers and call ourselves "config t"

Hi everyone! Welcome again to another thrilling installment of my Juniper blog! In the last session we talked mainly about operational mode commands and moving about the CLI. In this installment, we will focus on configuration mode and the JUNOS hierarchy. To enter configuration mode in JUNOS you issue the configure command from within the CLI. The router prompt will change:


Eg:

user@routername#


"It's all about multiplicity"


The default operation of configuration mode is that multiple users can edit the router's configuration at the same time.

• configure private command allows only one user to configure the router


• configure exclusive will allow multiple users to edit different portions of the configuration

Use set commands to add configuration to the router.

Eg: user@routername# set system services telnet

In JUNOS, the top level directory is edit with several sub directories below it. View them with the set ? command. The opposite of placing configuration into the router with the set command is the delete command.

Note: Do not use the delete command carelessly as it may delete a whole directory if you do not specify a particular command!

You can use the up command followed by a number to traverse a specified number of levels under the edit hierarchy. The top command will take you to the root directory, edit.
With such a plethora of commands in this section and previous sections, it has now become time to activate our new configuration statements!

This is accomplished with the commit command. The commit command activates the configuration we were just editing, called the candidate configuration.

"More on active configuration versus candidate configuration..."

In a Juniper router there are two configurations always present:

• Active configuration Current configuration running on the router (running-config in Cisco)
• Candidate configuration (The configuration we edit until we issue a commit.)

In the next session we will talk more about syntax "sanity checking" and rolling back...

CLI or Not to CLI...That is our question!

Jweb is the graphical configuration tool for J-Series routers. I am going to mainly focus on the CLI commands. The CLI is multi-modal. The two modes are operational and configuration mode.

Mode differences and the run command:

• Operational Mode is for troubleshooting and monitoring the status of the router, network, and software
• Configuration Mode is where interfaces, routing protocols, and other statements are located.
• Any command you can do in operational mode, you can do in configuration mode with the run command

Eg: user@routername# run show route

"Gaining Access to the Router"

Access to the router can be accomplished in a number of ways:

• Direct physical console access
• Secure Shell or SSH
• Telnet

Upon gaining access to the router, you will see a login: prompt. After supplying a valid username and password you will be in operational mode (similar to user-exec mode in Cisco.)

Note: The only user where the above mentioned scenario is not the case is for the user root. The root user is placed into a shell and MUST issue the cli command.

EG: root@routername% cli

Commands in Operational Mode:

• ping
• traceroute
• ssh
• telnet
• request (JUNOS specific) request commands are systemwide for rebooting, upgrade, and router shutdown
• restart (JUNOS specific) like kill commands, used to restart or halt processes
• test (JUNOS specific) used to test config files, interfaces, and policies similar to Access Control Lists (ACLs) in Cisco.

You can perform unix-like command completion using the SPACE or TAB keys (TAB completes commands and variables, like interface names, SPACE will only complete commands. When a command is ambiguous, JUNOS will list possible completions.

Note about software processes and the CLI:

The mgd daemon is the software process that controls the CLI.