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.)