Posts Tagged ‘technical FAQ’

NTLM Authentication

Tuesday, March 24th, 2009

Introduction:

This BOK details how to get a Java-based web-application to negotiate with a IE web client for username and domain information. This is a common requirement for web-based applications especially ones that do not want to bore users with a login page. IE will negotiate a user’s password hashes with the webserver, which checks their authenticity against a windows domain controller. If valid, the user’s username and domain will be accessible to the webserver servlets.

NTLM Authentication and how we achieve it:

 
The method HttpServletRequest.getRemoteUser() should return the username of the person using the browser which fired a request to this Servlet.
This method, however works correctly only if the user has been authenticated first by a webserver authentication scheme -
which could be BASIC,DIGEST or CLIENT-CERT. This is the kind of setup the the Apache webserver provides, giving a challenge-response, username-password method of authentication.

What we do here is use a Servlet filter provided as part of the open-source jCIFS package, to get an IE user's username and domain. 

This filter will take the trouble of intercepting user requests, asking IE for the user's password hashes,validating them against a windows domain controller and enabling HttpServletRequest.getRemoteUser() to return the windows user id.
 
Please note this method will not work for non-IE clients, simply because this is a proprietary extension by Microsoft. 
 
For other browsers you will have to rely on BASIC or certificate-based authentication.

How to setup your web application:

 First, we need to download a jcifs jar from http://jcifs.samba.org. I have tested this with jcifs version 0.7.14.jCIFS is from the makers of Samba and provides APIs to access Windows shares, networks and the ability to authenticate against a Windows domain controller. Place this jar under WEB-INF/lib of your web application. There is a filter called jcifs.http.NtlmHttpFilter which implements all the wizadry above. You need to register it in your application's web.xml descriptor:
 
<web-app>
...
    <!-- NTLM HTTP Authentication only works with MSIE -->
    
    <filter>
        <filter-name>NTLM HTTP Authentication Filter</filter-name>
        <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

        <!-- CCD will help you with a PDC and WINS server ip at your location. -->
        <init-param>
            <param-name>jcifs.http.domainController</param-name>
            <param-value>192.168.170.5</param-value>
        </init-param>

        <init-param>
            <param-name>jcifs.netbios.wins</param-name>
            <param-value>192.168.166.13</param-value>
        </init-param>
    </filter>

    <!-- This is the url under which we need access to the username and domain. -->

    <filter-mapping>
        <filter-name>NTLM HTTP Authentication Filter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

...

</web-app>
 
That's it. Now all IE requests to your webserver urls as specified in the web.xml entries are negotiated so that you can call a HttpServletRequest.getRemoteUser() to get the remote user's username in the form.

            DOMAIN\username.

Please note at no point will a password dialog pop up for the user, the password hashes are picked from IE and validated with the domain controller.
 
 
Example code for a servlet :
 
 
public void doGet( HttpServletRequest req,
                        HttpServletResponse resp )
throws IOException, ServletException
        
        {

PrintWriter out = resp.getWriter();

resp.setContentType( “text/html” );
out.println( “<HTML><HEAD><TITLE>NTLM HTTP Authentication Example</TITLE></HEAD><BODY>” );
out.println( “<h2>NTLM HTTP Authentication Example</h2>” );

out.println( req.getRemoteUser() + ” logged in” );

 

}

If the filter has not been configured properly, a null will be printed for the above call to req.getRemoteUser().

 

References:

  • Web Link :- http://jcifs.samba.org.

Jsp – Oracle Connectivity

Monday, March 23rd, 2009

Introduction

This document deals with the JSP connectivity with Oracle.This also exemplifies adding,updating, deleting and retrieving records from database(Oracle) through JSP.

Prerequisites

  • Tomcat Server.
  • Oracle Client.
  • Oracle Server.

Target Readers : All

Getting Started

Copy a jar file class12.jar from Oralce_root->jdbc->lib->class12.jar
to Tomcat Server in Tomcat_root->common->lib.

Database Connectivity

<%
try{
Class.forName(”oracle.jdbc.driver.OracleDriver”).newInstance();

//Creating the connection object
Connection con = DriverManager.getConnection(”jdbc:oracle:thin:” + “@172.24.205.62:1521:infosys”,”Uname”,”Pwd”);

con.close();
}
catch (SQLException sqle){
throw new SQLException();
}
%>

Note:

172.24.205.62 -> IP Address of Oracle Server.
1521 -> Port Number.
infosys -> Host String.
Uname -> UserName.
Pwd -> Password.

Adding a Record

<%
try{
Class.forName(”oracle.jdbc.driver.OracleDriver”).newInstance();

//Creating the connection object
Connection con = DriverManager.getConnection(”jdbc:oracle:thin:” + “@172.24.205.62:1521:infosys”,”Uname”,”Pwd”);

PreparedStatement stmt = con.prepareStatement(”insert into Table_Name values(?,?,?)”);
stmt.setString(1,column1);
stmt.setInt(2,column2);
stmt.setString(3,column3);

stmt.executeUpdate();

con.close();
}
catch (SQLException sqle){
throw new SQLException();
}
%>

Where column1,column2,column3 can be static values or can be taken from the previous page by establishing session.

Deleting a Record

<%
try{
Class.forName(”oracle.jdbc.driver.OracleDriver”).newInstance();

//Creating the connection object
Connection con = DriverManager.getConnection(”jdbc:oracle:thin:” + “@172.24.205.62:1521:infosys”,”Uname”,”Pwd”);

PreparedStatement stmt = con.prepareStatement(”delete from Table_Name where EmpName=’XYZ’”);
stmt.executeUpdate();

con.close();
}
catch (SQLException sqle){
throw new SQLException();
}
%>

Updating a Record

<%
try{
Class.forName(”oracle.jdbc.driver.OracleDriver”).newInstance();

//Creating the connection object
Connection con = DriverManager.getConnection(”jdbc:oracle:thin:” + “@172.24.205.62:1521:infosys”,”Uname”,”Pwd”);

PreparedStatement stmt = con.prepareStatement(”update Table_Name set Designation=’Software Engineer’ where EmpName=’XYZ’”);
stmt.executeUpdate();

con.close();
}
catch (SQLException sqle){
throw new SQLException();
}
%>

Retrieving a Record

<%
String empName=”";
int empNumber=0;
String empDesignation=”";

try{
Class.forName(”oracle.jdbc.driver.OracleDriver”).newInstance();

//Creating the connection object
Connection con = DriverManager.getConnection(”jdbc:oracle:thin:” + “@172.24.205.62:1521:infosys”,”Uname”,”Pwd”);

PreparedStatement stmt = con.prepareStatement(”select * from Table_Name”);
ResultSet rs = stmt.executeQuery();

while(rs.next())
{
empName = rs.getString(”EMPNAME”);
empNumber = rs.getInt(”EMPNO”);
empDesignation = rs.getString(”DESIGNATION”);

out.println(empName);
out.println(empNumber);
out.println(empDesignation);
}

con.close();
}
catch (SQLException sqle){
throw new SQLException();
}
%>

J2EE (FAQs)

Monday, March 23rd, 2009

 

1.        What is an Application Server?. 3

2.        What are different kinds of application servers?. 3

3.        What are the different services provided by the J2EE Application Server?. 3

4.        Which applications need J2EE and what are the characteristics of a Distributed     application?. 3

5.        What is the Java 2 Platform, Enterprise Edition (J2EE)?. 4

6.        Is J2EE a platform?. 4

7.        What are J2SE, J2ME, and J2EE?. 4

8.        What are the components of a J2EE Application Server?. 5

9.        What is a Container?. 5

10.     How the Container interacts with the Application and the user?. 5

11.     What are the different kinds of Containers for different types of J2EE application code?  5

12.     What is an EJB and what are the services provided by the EJB Container?. 5

13.     What are the different tiers in a J2EE application?. 6

14.     What are JavaServer Pages, or JSPs?. 6

15.     What are servlets?. 6

16.     What is the difference between Servlets and JSPs?. 6

17.     What are the different types of Enterprise JavaBeans?. 6

18.     What is an Entity Bean?. 7

19.     What is a Session Bean?. 7

20.     What is a Message-Driven Bean?. 7

21.     What is the difference between JavaBeans and Enterprise JavaBeans?. 7

22.     What is Deployment Descriptor?. 8

23.     What Deployment Descriptors are made of?. 8

24.     What are handles?. 8

25.     How is the Web Container different from the Web server?. 8

 

 

1.                 What is an Application Server?

An application server is a program that handles all application operations between users and an organization’s backend business applications or databases. An application server is software that doesn’t do regular stuff like sell your stocks or let you write documents. A server’s users aren’t people; the server’s users are other applications.  Application servers provide services to distributed applications. These services include security, data integrity, and resource management (making sure there’s enough memory to go around). These services are already written up and ready for you the application developer to take advantage of. All you have to do is write your application to hook up to an application server.

 

2.     What are different kinds of application servers?

There are lots of different kinds of application servers. J2EE is one kind of application server. CICS and Tuxedo are other types of application servers. The one that comes in .NET is another.

 

3.     What are the different services provided by the J2EE Application Server?

A J2EE application server gives you three main categories of services:

·         Security – The J2EE application server takes care of security. Security makes sure people who aren’t authorized to get at the application, or to do things that aren’t authorized, can’t do stuff they shouldn’t. It keeps a list around of what each part of the application can and can’t be asked to do, and by whom. And more.

·         Data integrity – The server manages transactions. This capability also helps the application get information in and out of the database without screwing up the data.

·         Resource Management The server takes care of resource management. One aspect of this is ensuring that memory used by one part of the application gets freed up and available for use by other parts. The container can also create ready-made connections to the database to make database access quicker and cheaper.

 

4.     Which applications need J2EE and what are the characteristics of a Distributed application?

Applications that need J2EE are Distributed Enterprise System. Distributed means that the application, including the data, is two or more different computers.

Two basic things create the need to be distributed:

·         Being online means you’re distributed automatically. Not all online applications need to use J2EE, but being online does mean you’re distributed.

·         Having a lot of users means you probably want to be distributed. The more different computers you can use, the more computer power you have to run your application, and you’ll need a lot in order to make the application run fast enough for all those users. The more users you have, the more storage space you’ll need for user data, as well.


 

5.     What is the Java 2 Platform, Enterprise Edition (J2EE)?

J2EE isn’t a specific application server product. It’s a standard, a type, rather than a specific server product.

J2EE is a standard for creating servers. A standard is just a set of rules people follow to make things easier and more consistent. If you try to hook a J2EE application up to a non-J2EE application server, it wouldn’t work because they use different standards.

J2EE is an open standard. Sun gives people instructions for how to write servers, and applications, to the J2EE standard. This is unusual because software companies usually like to keep how to make their applications to themselves, but not in this case. Anyone can download the specification and write themselves a J2EE application server.

That means two things.

·         First, there’s a lot of choice when you’re shopping for a J2EE application server: BEA WebLogic, IBM WebSphere, Sun’s Java enterprise System, and so on. All those companies have downloaded the information for how to build J2EE application servers, and built them.

·         Second, that you’re not stuck. Let’s say you’ve bought a J2EE application server. If you don’t like your first pick – maybe the company doesn’t give good customer service or they’re overpriced – you can go out shopping again for a J2EE application server from a different company.

 

Once you get the new application server, switching your application to it goes relatively easy. All the J2EE application servers work fundamentally the same way.

 

6.     Is J2EE a platform?

Yes, J2EE is a platform. A platform is a large collection of features that can be used by a bunch of different applications. The features are administrative things, not central to what the applications do, but still necessary. And the features provided by platforms are generally difficult enough to write. It’s nice to just be able to hook up to them rather than to write the code for them yourself.

 

7.     What are J2SE, J2ME, and J2EE?

The splitting of Java resulted in what’s explained below.

·         J2SE – Java 2 Standard edition. The basics for writing regular programs that probably aren’t going to stray too far from their home computer. If you wrote a regular text editor application in Java that just runs on one person’s local computer, you’d be using the Standard Edition, J2SE.

·         J2EE – Java 2, Enterprise Edition. These are the big tools that are used to create servers and the applications that work with them. These are the tools for handling applications that have separate bits working together and distributed all over the world.

 

 

·         J2ME – Java 2 Micro Edition. Java that does stuff that’s similar to J2SE, but generally smaller cuter applications and on pagers, PDAs, smart cards, etc.

 

8.     What are the components of a J2EE Application Server?

A J2EE application server is actually one or more pieces of software that together make the application server product. There are usually a couple containers, some deployment tools, and a Web server.

 

9.     What is a Container?

The container program is what gives you the services of Security, data Integrity, and Resource Management. The container does all the smart stuff: takes requests from the clients and relays the appropriate messages to the application, takes care of security and sends data to and from the database.

 

10. How the Container interacts with the Application and the user?

The applications never interact directly with the outside world. Requests that come in from customers go through the container, and the container tells the application what to do. The application does it, tells the container, and the container does what’s necessary to report back to the customer.

 

11. What are the different kinds of Containers for different types of J2EE application code?

Different kinds of Containers are the Web container, the EJB container, and the Web server.

 

12. What is an EJB and what are the services provided by the EJB Container?

EJBs is short for Enterprise Java Beans. Enterprise Java Beans are powerful code that can do business logic for you. And represent your application’s objects like customers, products, and so on.

Business Logic is the guts of your application, and the kind of beans that do that are session beans. The kind of beans that represent the main things in your application like customers are called entity beans.

The EJB container provides all three of the services: Data integrity, security and resource management. The Web container, by way of contrast, only gives security.


 

13. What are the different tiers in a J2EE application?

The different tiers, a J2EE application is generally divided into are:

·         Presentation tier – The presentation tier mainly concerns with presentation logic generally implemented by servlets and jsps.

·         Business tier – Business tier contains business components such as EJBs implementing logic.

·         Database tier – Database tier contains persistent data generally stored in a RDBMS such as Oracle, DB2 and so on.

 

14. What are JavaServer Pages, or JSPs?

JSP is server-side technology, which combines both- application logic (java code) and presentation logic (HTML code), so that HTML designers and java code developers can work in tandem (simultaneously) by providing there max skills on the application.

JSPs are HTML with a little java code inside.

 

15. What are servlets?

A servlet is a Java programming language class used to extend the capabilities of servers that host applications accessed via a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes.

 

16. What is the difference between Servlets and JSPs?

JSP is Java code embedded in HTML. The Java code is compiled (if necessary) and run by the container on the server and the client only sees the results of that code’s execution mixed in appropriately with the html.

Servlets are compiled pure Java class files (not mixed with HTML) where the entire html page can be generated.

 

17. What are the different types of Enterprise JavaBeans?

There are three kinds of EJBs:

·         Entity beans

·         Session beans

·         Message-driven beans

 

 

18. What is an Entity Bean?

The entity bean is used to represent data in the database. Entity beans are the only things that have to deal with the database and all the complexity therein. Entity beans provide a component model that allows bean developers to focus their attention on the business logic of the bean, while the container takes care of managing persistence, transactions, and access control. There are two basic kinds of entity beans: container-managed persistence (CMP) and bean-managed persistence (BMP).

 

19. What is a Session Bean?

Session beans are all about functionality, application logic, and application state. Session beans are usually associated with one client. Each session bean is created and destroyed by the particular EJB client that is associated with it. These beans do not survive after system shutdown. 

There are two types of session beans: stateful session beans and stateless session beans.

·         Stateful session beans maintain conversational state between subsequent calls by a client. 
The statefulness in their name has to do with the state, the data, gathered from the client they are working with. They carry around a lot of data with them which make them useful in that respect, but slower.

·         Stateless session beans are just used to service clients regardless of state. They don’t carry around any state with them from one client request to another, so they are generally zippier than stateful session beans when it comes to performance.

 

20. What is a Message-Driven Bean?

A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It does not have Home and Remote interface as Session or Entity bean. It is called by container when container receives JMS asynchronous message.

 

21. What is the difference between JavaBeans and Enterprise JavaBeans?

Java Beans and EJBs are used for different purposes altogether, though both specifications are provided by Sun micro Systems. Java Beans are mainly meant for building extendable components and typically contain getters and setters for all its data members, along with other required functionality. EJBs are server side programs that typically implement middle layer business functionality, providing 3 – layer architecture for applications. EJBs can be Entity, Session or Message depending on the required functionality. Most of the critical services are provided by EJB containers and thus allowing the programmer to concentrate on the business logic on hand.

 

22. What is Deployment Descriptor?

Some of how a J2EE application runs is controlled by a configuration file called a deployment descriptor. If you want to change any of the settings, you just change the information in the deployment descriptor. No touching the code and risking breaking something else in the code; just a nice neat little configuration file. (You still have to redeploy the application, which is not a trivial task, but at least you don’t have to touch the code.)

 

23. What Deployment Descriptors are made of?

The file is created in XML. XML stands for eXtensible Markup Language. XML is a highly structured, user extensible, data-centric way to represent data. This just means that you can pretty much do whatever you want with it if you set it up right, and it can do a lot.

There’s an XML deployment descriptor for EJBs, and for servlets and JSPs.

One thing that makes XML so popular and an obvious choice for J2EE is that XML is platform independent; any computer can read XML. XML is relatively easy for a computer program to read and do stuff with, and surprisingly at the same time, humans can usually look at it and get the gist, as well.

 

24. What are handles?

When you have got the beans and you want one bean to do something with another bean, you need to get a handle to it.

In regular Java, or in any regular object-oriented application, one object tells another object what to do; might call an invoice object’s print method, for instance. To do that, the object needs a reference to the Invoice object. Just a special kind of code that lets you talk to that object.

J2EE is a little different since you don’t get to have a reference to the object itself; you get a reference to a bean’s remote interface which is kind of like the bean’s personal manager. You can’t get to the bean itself. And so since the mechanics are a little different, the EJB folks called the reference something different: a handle. A handle is just an EJB-style reference.

 

25. How is the Web Container different from the Web server?

Basically, the Web container is different from the Web server because it manages dynamic content. Dynamic content is a file that does not exist already and is created on the fly by some programming logic.

Some content needs to be very up to date, and to ensure this content is up to date, you create it dynamically.

You can write a servlet that would query the database and create the HTML page for you right there, on the fly. That created information would be dynamic content. And instead of saving it to a file you can have that same servlet send its output directly to the Web server, which in turn displays it to the user. The Web container is responsible for starting the servlet and directing the servlet’s output to the Web server.

Intro to Juniper Routers

Monday, March 23rd, 2009

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

 

Searching for a pattern as a string or regular expression

Monday, March 23rd, 2009

searchPatternInColumn pl.Ver1p1

 

1.  Introduction

          

          Searching for a pattern as a string or regular expression ( perl syntax ) in a file in the  specified column.

 

 

2.        Uses and Guidelines (Optional)

 

          usage: ./searchPatternInColumn.pl.Ver1p1 <Input file> <delimiter> <Pattern file>  <columnNumber>

 

 

·         Operating System                                   UNIX

·         Language/Tools used for development        Shell

 

3.    Code

 

#!/usr/bin/perl

#$Id: test.pl,v 2.0 2004/10/08 13:00:03 kumap Exp $

 

 

# Performs the same feature of “cut” in shell scripts.

sub splitValue()

{

  my $target    = $_[0];

  my $delimiter = $_[1];

  my $fieldNum  = $_[2];

 

  my @tempArray = split(/$delimiter/, $target);

 

  return $tempArray[$fieldNum - 1];

}

 

if ( @ARGV != 4 )

{

    print “usage: $0 <Input file> <delimiter> <Pattern file> <columnNumber>\n”;

    exit (1);

}

 

my $inputFile     = $ARGV[0];

my $delimiter     = $ARGV[1];

my $patternFile   = $ARGV[2];

my $columnNum     = $ARGV[3];

 

print ” Arguments = ” ;

print “@ARGV” ;

print “\n” ;

 

$columnNum = $columnNum – 1;

print ” *) Converting column number to index : $columnNum”;

 

if ( $columnNum < 0 )

{

   print “\n *) Invalid column number\n”;

   exit (1);

}

 

open (PATTERN_FILE, “<$patternFile”) || die “Error: Could not open $patternFile for reading”;

open (INPUT_FILE, “<$inputFile”) || die “Error: Could not open $inputFile for reading”;

open (OUTPUT_FILE, “>${inputFile}.out”) || die “Error: Could not open ${inputFile}.out for writing”;

 

$index = 0;

 

while ($line = <PATTERN_FILE>)

{

        chomp($line);

        $patternArray [ $index ] = $line;

        $patternArrayHash { “$line” } = 0;

        $index++;

}

 

$maxIndex=$index-1;

$index = 0;

 

while ( $line = <INPUT_FILE>)

{

        chomp($line);        

 

  print ” \n *) Input: $line \n”;

        @lineArray = split(/$delimiter/,$line);

        

        #for ( $i=0; $i <= $maxIndex; $i++)

        #{

        #   $pattern=$patternArray [ $i ];

        #   print ” *) Pattern : $pattern \n”;

        #   print ” *) Column : $lineArray[$columnNum] \n”;

        #   #if ( $lineArray [ $columnNum ] eq $pattern )

        #   if ( $lineArray [ $columnNum ] =~  /^$pattern$/ )

        #   {

        #     print OUTPUT_FILE “$line\n”;

        #     print  “$line\n”;

  #   }

        #}

        for $pattern ( keys %patternArrayHash )

        {

            print ” *) Pattern : $pattern \n”;

            print ” *) Column : $lineArray[$columnNum] \n”;

            if ( $lineArray [ $columnNum ] =~  /^$pattern$/ )

            {

                print OUTPUT_FILE “$line\n”;

                print  “$line\n”;

            }

        }

 

}

close(DISPLAY_DETAILS_FILE);

close(INPUT_FILE);

close(PATTERN_FILE);

 

4.    Limitation of the component

 

     Within Shell/Unix environment