Packet Switching

It is point to multi point switching technology based on PVCs (Permanent Virtual Circuits) as
• x.25
• FR (Frame-Relay)
• ATM (Asynchronous Transfer Mode)
ATM (Asynchronous Transfer mode): -
• Speed from up to 40 Gbps.
• Any packet is divided into small cells of fixed size, each cell = 53 bytes (48 bytes payload and 5
bytes header, So ATM is called cell switching technique.
• Advantage of small size:
✓ Fast buffering.
✓ Less propagation delay.
✓ Easier processing.
• Its most famous header is called AAL5 (ATM Adaption Layer 5).
• Its address is called VPI/VCI (Virtual Path Id (8bit)/ Virtual Circuit Id (8bit))
• For priority it uses a bit called CLP (Cell Loss Priority) as DE in FR.
Frame Relay: -
It's a point-to-multi point packet switching technology based on the concept of Virtual Circuit (VC).
Frame Relay Topologies:
b) Star topology (hub and spoke)
b) Point-to-Point ✓ The main problem is if the Hub site went down.
✓ Similar to leased line. ✓ No. of VC = No. of routers -1

d) Partial mesh:
c) Full mesh
✓ We will not connect VCs between all the sites.
✓ Pull redundancy but high Cost.
✓ For example in the below topology we used 7 VCs
✓ No. of VC = n (n-1) / 2 ( n --- No. of routers ).
only, if we made a full mesh we need 10 VCs.
✓ Finally we make redundancy with low cost.

FR was originally invented to work on ISDN interfaces but now mostly used on serial interfaces.
 Frame Relay:
• Initially, open standard LAPF (Link Access Procedure for FR) was introduced as it’s the layer 2
protocol working with the FR.

• As usual, Cisco takes this protocol and adds the type field.

• Then IETF (Internet Engineering Task Force) implemented a similar open standard protocol.

Note: IETF FR and Cisco FR are not compatible.

✓ Solution: configure Cisco router to operate as IETF
Frame Relay terminology:

• PVC (Permanent Virtual Circuit): logical circuit that is created to ensure bidirectional
communication from one router to another, it's the most common type of virtual circuits. As there is
SVC (Switched Packet Switching) which is on demand packet switching, and is rarely used in the ISPs.
• DLCI (Date Link Connection Identifier): A 10-bit address that identifies the VC (Virtual Circuit).
It's locally significant between the router and FR switch.
• LMI (Local Management Interface): A signaling standard between the router and the local FR
switch. Its used to maintain the connection status.
• IARP (Inverse Address Resolution Protocol): Used to get the IP for the remote DLCI.
• DE (Discard Eligible): By setting this bit, the frame will be having less priority and will be more
subjected to be discarded in case of congestion.
Frame Relay operations: -
1. Enable frame relay on router serial interface and configure frame relay switching table on the frame
relay switch.
2. Router will negotiate with the frame relay switch the available PVCs (through LMI protocol).
3. Router will try to discover what is the next hop router for each PVC? and form the frame relay map.
1) Configuring the frame relay on the routers and building the frame relay address mapping on the
FR switch. FR table on the FR switch

2) Negotiation between the router and the FR switch about the available PVCs using LMI protocol.
LMI: (Local Management Interface):
LMI protocol is used between the router (DTE) and the local FR switch (Master DCE) to
negotiate the PVCs between them and their status on the local loop:

When the router receives LMI information, it updates its VC status to one of the following three
states:
➢ Active state: Indicates that the VC connection is active and that routers can exchange data
over frame relay network.
➢ Inactive state: indicates that the local connection to the frame relay switch is working but
the remote is not.
➢ Deleted state: means that the router (DTE) is configured for a DLCI the frame relay
switch does not recognize as valid for that interface.
➢ Router# show frame pvc | include status
DLCI = 57, DLC! usage = Local, PVC status = Deleted, Interface = Serial0/0.1
DLCI = 58, DLC! usage = Local, PVC status = Active, Interface = Serial0/0.2
DLCI = 59, DLC! usage = Local, PVC status = Inactive, Interface = Serial0/0.3

LMI types:
1. Cisco LMI (LMI messages are being sent on DLCI 1023).
2. ANSI (Annex D) (LMI messages are being sent on DLCI 0).
3. ITU-T (Q933-A) OR (Annex A) (LMI messages are being sent on DLCI 0).
• The router will work with the LMI type supported by the FR switch.
• For cisco routers there is also auto LMI discovery.
Note: If we have the below topology, cisco LMI is used from one side and ITU-T LMI is used
from the other side, there is no problem in this because LMI is local significant.

3) Discovering what is the next hop router for each PVC. Consider the below topology:
Consider the below topology:

• The FR switch deals only with DLCI. RIG Table of Rt

• R1 will check for the next hop IP (22.1.1.1) using its Network O/P int Next hop IP
routing table.
10.0.0.0/24 S0 22.1.1.1
• R1 will check for the DLCI mapped to the next hop IP
using its frame relay map, here it will be (300). 10.0.0.0/24 S0 22.1.1.2
• When the router encapsulates the packet, it adds L2 FR Map for R1
header with that DLCI (300). Next hop IP O/P int
• The frame relay switches have FR table, which mapping 22.1.1.1 300
DLCI 300 to DLCI 200. 22.1.1.2 100
Note:
R1 knows all DLCls using LMI, but it doesn’t know that mapping between those DLCls and the IPs.
So, we have two methods to identify this mapping:
• Dynamically using IARP
• Statically using commands
 I. Dynamically using IARP: (Inverse Address Resolution Protocol):

IARP is used to build FR map where each DLCI is associated

with the next hop IP. Each router sends IARP message to identify
all active DLCls.
Note: Every 10 seconds, routers exchange LMI messages with
FR switch.
Configurations:
➢ Router(config)#interface interface number
➢ Router(config-if}#encapsulation frame-relay {cisco/ietf}
➢ Router(config-if}#frame-relay Imi-type {cisco/ansi/q933a}

II. Statically using the below commands:

➢ Router(config-if}#frame-relay map ip next hop ip dlci broadcast

Broadcast: is used to identify this DLC! in broadcast, because if we configured RIP for example, the
updates should sent broadcast. But broadcast here is replica of unicast.

Frame Relay routing issues with split horizon:

In the topology (Hub & Spokes), there is a routing problem

between the spokes, because split horizon rule prevents the
updates received on Serial 0, to be advertised from S0 also.

Solutions:
1) Static routing on the router in the hub site, and default route
on the router in each spoke.
2) Full Mesh topology: All routers will receive all updates from
each other, but it's a high cost.
3) Disable split horizon, but this will make routing loops.
➢ Router(config-if}#no ip split-horizon.
4) Use point-to-point sub-interface:
• Each sub-interface is a subnet.
• Each sub-interface has DLCI.
• Using these configurations:
➢ Router(config}#interface interface_number
➢ Router(config-if)#no ip address
➢ Router(config-if)#int sub-interface point-to-point
➢ Router (config-subif)#frame-relay interface-dlci dlci_No
 Comparison between point to point FR and point to multi point FR:

Troubleshooting:
➢ Router#show frame-relay pvc
>> Displays the status of PVCs, BECNs, FECNS, ......
➢ Router#show frame-relay LMI

➢ Router#show frame-relay map

>> Display the map
➢ Router#debug frame-relay Imi
>> Displays the Imi requests & replies to the router
PPPoE (PPP over Ethernet):
• The Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for encapsulating PPP
frames inside Ethernet frames.
• PPPoE combines two widely accepted standards, Ethernet and PPP, to provide an authenticated
method of assigning IP addresses to client systems.
• It appeared shortly after the year 2000, in the context of the boom of DSL as the solution for tunneling
packets over the DSL connection to the ISP's IP network, and from there to the rest of the Internet.
• PPPoE has been described in some books as a "layer 2.5" protocol.
PPPoE is composed of two main phases:
Active Discovery Phase: -
• In this phase, the PPPoE client locates a PPPoE server, called an access concentrator.
• Hence before exchanging PPP control packets to establish the connection over Ethernet, the
MAC address of the two end points should be known to each other so that they can be encoded
in these control packets.
• The PPPoE Discovery stage does exactly this.
• In addition it also helps establish a Session ID that can be used for further exchange of packets.
• During this phase, a Session ID is assigned and the PPPoE layer is established.
PPP Session Phase: -
• Once the MAC address of the peer is known and a session has been established, the Session
stage will start.
• In this phase, PPP options are negotiated and authentication is performed.
• Once the link setup is completed, PPPoE functions as a Layer 2 encapsulation method,
allowing data to be transferred over the PPP link within PPPoE headers.
At system initialization, the PPPoE client establishes a session with the access concentrator by
exchanging a series of packets. Once the session is established, a PPP link is set up, which includes
authentication using Password Authentication protocol (PAP). Once the PPP session is established,
each packet is encapsulated in the PPPoE and PPP headers,
PPPoE Discovery (PPPoED)
Although traditional PPP is a peer-to-peer protocol, PPPoE is inherently a client-server relationship
since multiple hosts can connect to a service provider over a single physical connection.
The Discovery stage has 4 steps. The first step consists of the host broadcasting an Initiation
packet, one or more RAS sending Offer packets, the host sending a unicast Session Request packet
and RAS sending a Session Confirmation packet. Once the host receives the Session Confirmation
packet, it proceeds to PPP Session stage.
1) PPPoE Active Discovery Initiation (PADI) Packet
• The client router sends a PADI packet with Destination Address set to broadcast address.
• The Session ID is set to 0x0000.
• The PADI packet indicating the service the host is requesting.
2) PPPoE Active Discovery Offer (PADO) Packet
• When the RAS receives a PADI packet, it replies by sending a PADO packet.
• The Destination Address is set to the Ethernet (MAC) address of the host that sent the PADI
packet.
• The Session ID is set to 0x0000.
• The PADO packet contains the RAS's name.
 3) PPPoE Active Discovery Request (PADR) Packet
• Since the PADI is broadcast, the host may receive multiple PADO packets.
• The host chooses one from the received PADO packets.
• The host sends a unicast PADR packet to the RAS it has chosen.
• The Session ID is set to 0x0000.
4) PPPoE Active Discovery Session-confirmation (PADS) Packet
• When the RAS receives a PADR, it generates a unique Session ID for the PPPoE session and
replies to the host with PADS packet.
• The Destination address is set to the unicast Ethernet address of the host.
Summary: -
• A PPPoE session is initiated by the PPPoE client. If the session has a timeout or is disconnected, the
PPPoE client will immediately attempt to reestablish the session.
The following four steps describe the exchange of packets that occurs when a PPPoE client initiates a
PPPoE session:
1. The client broadcasts a PPPoE Active Discovery Initiation (PADI) packet.
2. When the access concentrator receives a PADI that it can serve, it replies by sending a PPPoE
Active Discovery Offer (PADO) packet to the client.
3. Because the PADI was broadcast, the host may receive more than one PADO packet. The host
looks through the PADO packets it receives and chooses one. The choice can be based on the
access concentrator name or on the services offered. The host then sends a single PPPoE Active
Discovery Request (PADR) packet to the access concentrator that it has chosen.
4. The access concentrator responds to the PADR by sending a PPPoE Active Discovery Session-
confirmation (PADS) packet. At this point a virtual access interface is created that will then
negotiate PPP, and the PPPoE session will run on this virtual access.
• If a client does not receive a PADO for a preceding PADI, the client sends out a PADI at
predetermined intervals. That interval is doubled for every successive PADI that does not evoke a
response, until the interval reaches a configured maximum.
• If PPP negotiation fails or the PPP line protocol is brought down for any reason, the PPPoE session
and the virtual access will be brought down. When the PPPoE session is brought down, the client
waits for a predetermined number of seconds before trying again to establish a PPPoE.
After session is established data with PPoE header can move from hop to hop, PPPoE header is 6-8 byte
long, so recommended MTU to be 1492 Byte.

Code field help in PPPoE operation (Discovery Phase)

PPPoE Client Configuration: -
➢ interface Dialer 1
➢ ip address negotiated
➢ encapsulation ppp
➢ Ppp authentication chap
➢ ppp chap password cisco
➢ dialer pool 5
➢ ip mtu 1492
Then assign the dialer interface to a physical interface.
➢ interface fastethernet 0/0
➢ pppoe enable
➢ pppoe-client dial-pool-number 5
On the PPPoE server side VPDN (Virtual Private Dial
up Network) feature should be enabled using :
(config)#vpdn enable
But PPPoE server configuration is out of course scope.
The “vpdn enable” command is used to
enable virtual private dialup networking
(VPDN) on the router and inform the router
to look for tunnel definitions in a local
database and on a remote authorization
server (home gateway)

The “dialer persistent” command (under interface configuration mode) allows a connection to be
brought up without being triggered by interesting traffic. And allow connection stay up even no data is
sent over the link. When configured, the dialer persistent command starts a timer when the dialer
interface starts up and starts the connection when the timer expires. If interesting traffic arrives before the
timer expires, the connection is still brought up and set as persistent. An example of configuring is shown
below:
➢ interface Dialer1
➢ ip address negotiate
➢ dialer pool 1
➢ dialer persistent