Layer 2 Technologies - Implement Frame Relay (Part 2)

1.60   Implement Frame Relay

(l) Multilink Frame Relay

(m) PPP over Frame-Relay

(n) Dynamic Mappings to 0.0.0.0

(o) Troubleshooting Hub and Spoke

(p) Frame Relay Switch Configuration

(q) Subinterfaces


Multilink Frame-Relay

This sounds awfully a lot like PPP over Frame (and it is) the idea of encapsulating PPP on top of frame was to support service interworking between Frame-Relay and ATM and granting the capability for link fragmentation (thanks to ML-PPP) ML-PPP works fine over a single physical interface (or PVC in this case)

Multi-link PPP allows you to specify a fragment size, where packets smaller than the fragment size are transported as is (in a priority queue), while larger packets are chopped into fragments and given the ML-PPP header in order to be re-assembled on the other size - smaller packets can be interleaved between fragments of larger packets allowing realtime packets such as voip packets to be delivered without requiring a large de-jitter buffer (however by default a FIFO queue is used but it is certainly possible to use an alternate queueing method such as LLQ, WFQ, CBWFQ to achieve this)

Configuration involves:

• Frame-Relay Traffic Shaping has to be enabled on the interface at hand
• A Frame-Relay class-map needs to be defined with the appropriate traffic shaping which will be bound to the PVC
• A ClassBased QoS Policy Map which will be bound to the virtual-template to handle the classification and queueing of egress traffic
• Defining a virtual-template interface that uses PPP encapsulation and has an unnumbered interface (bound to a loopback) in particular the below commands are required:
  
  
  • bandwidth  [xxx] (Where [xxx] is the PVC CIR)
  • ppp multilink
  • ppp multilink interleave
  • ppp multilink fragment delay [yyy] (Where in [yyy] ms is used to determine the fragment size and is based on both the physical port and PVC CIR with typically no more than 10ms serialisation delay  [yyy]  = [phys_interfacebandwidth] / [PVC_CIR] * [Max_serialisation_delay] the size in bytes could be calculated as [PVC_CIR_bps] * ([yyy] / 1000) / 8
  • service-policy output [marked, limited and queued traffic]
• The Frame-Relay sub-interface would have:
• frame-relay interface-dlci [dlci] ppp virtual-Template [n] (Where [dlci] is the PVC id and [n] identifies the particular virtual-template)
• class[fr-shapingclass]

More Reading: INE Blog Cisco QoS Config Guide

PPP over Frame-Relay

The majority of how this is done (using a virtual-template) is described up above.  The only extra information that can be described is that you can add other PPP related things such as authentication which may be useful rather than blindly trusting the service provider has given you the correct PVC between your devices without necessarily needing the overhead of IPSec.

The other good thing is that there is no L3 information configured on the Frame-Relay interface, no Inverse-ARP and no static mapping required since L3 information is contained in the virtual template.

Another INE Blog Post gives an example here, however I think this area is really a subset of the above.

Understanding Dynamic Mappings to 0.0.0.0

Those guys at INE have another post talking about this but the long and the short is, this is a carry over from AutoInstall where a router which does not have a saved configuration but has WAN connections to a FR network autodetects that it's on a FR network, uses LMI to determine active PVCs and since it has no configuration but is attempting to find a BOOTP server (since there is no configured L3 information, the mechanism binds 0.0.0.0 to the active PVCs hoping to find a config server which will send down a config)

If you have since applied a config - it's possible that these bindings may not disappear (visible if you do a show frame-relay map) unless you write mem and reload, however changing the interface encapsulation from frame-relay and back may fix this.

Troubleshooting Hub and Spoke

Shamelessly ripped from Brian Dennis

1. Use point-to-point subinterfaces on the spokes.  This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
2. Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
3. Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
4. Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
5. Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.

 I have a feeling I will re-visit and expand upon this area when I get into OSPF NBMA configuration.

Frame-Relay Switch Configuration

Frame-Relay switches can be implemented by regular routers.  A few conventions exist at Layer 1 and Layer 2 which are not mandatory but best mimic what a service provider frame-switch does and makes is somewhat more normal for the non Frame-Switch

Layer 1:
On the serial interface, there are two types of interfaces, DTE and DCE, typically the non-service provider device would appear as the DTE and the frame-switch as the DCE (it doesn't have to be this way but it is usually the convention) one of the reasons why the SP is the DCE is that the physical interface clock-rate is specified by the DCE

Layer 2:
Once you specify the interface encapsulation type i.e. encapsulation frame-relay your interface type is DTE by default (Layer 1 and Layer 2 DTE/DCE configurations are independant of each other) The Frame-Relay DCE provides the LMI status messages, while the DTE makes the LMI enquiries.  This is configurable using the frame-relay intf-type [type] command where [type] can be dce, dte (default) or nni (for frame-switch to frame-switch connections) actually if you disable LMI on both interfaces by configuring no keepalive this area of the configuration is not required, however you miss out on the OAM features that LMI brings to the party (such as allowing you to know that a PVC is down either because the SP network doesn't know of its existance, or possibly the far end device is off the air)

Frame-Switch Configuration:


hostname FR-SW
!
frame-relay switching
!
interface Serial0/0
  description To R1
  no ip address
  encapsulation frame-relay
  clock rate 64000
  frame-relay intf-type dce
  frame-relay route 102 interface Serial0/1 201
!
interface Serial0/1
  description To R2
  no ip address
  encapsulation frame-relay
  clock rate 64000
  frame-relay intf-type dce
  frame-relay route 201 interface Serial0/0 102
!


frame-relay switching enables the router to perform "routing" or cross-connecting Frame-Relay PVCs
frame-relay route [SRC_PVC] interface [DST_Interface] [DST_PVC]  provides the layer 2 mapping to switch frames from the source interface/pvc to the destination interface/pvc - since this is a unidirectional mapping, it requires a corresponding entry in the reverse direction.

Subinterfaces

I don't know what to say here - these things are a somewhat fundamental construct.  It's certainly possible to configure multiple PVCs under the main interface configuration, however it can cause some problems with routing protocols due to the split-horizon rule.  One way around this is to use logically interfaces which are children of the main physical interface which are attached to a logical circuit (PVC).  In Frame-relay you can have either point-to-point or multipoint sub-interfaces and they can logically coexist.  A Multipoint interface would support multiple PVCs in the same L3 domain, while a point-to-point interface supports only a single PVC in the L3 domain.

My Home lab

I know its been awhile since my last update but I haven't had a great deal of time up my sleeve for Cisco studies lately - a couple of other network related things have been keeping my occupied for the last month.

Firstly, I needed to renew my JNCIS-M, which was actually fun because I was able to play with some Olives and re-affirm my understanding on Juniper policy and configuration as it had been awhile since I had played with Junos (yes I passed that exam)

Also for the last few weeks I have been heavily work on IP/MPLS architecture and systems for SROS which has been a lot of fun and quite educational in building a reasonably sized demonstration network to support a number of current and legacy services.

I guess the take home message here is that while protocol operation is pretty much the same throughout, the way things are implemented and named can be different though and certainly each has a different paradigm in how things are achieved that depending on your particular context can be a bonus or a hindrance.

Anyhow, while I am planning to extend my studies further into the Service Routing Certification Program as certain units have immediate benefits in my workplace - my overall focus is still targeted on reaching CCIE status.

I think that many candidates working towards their R&S and Voice CCIEs are breathing a sigh of relief in that the open ended questions in those tracks are being retired in a couple of days.  It's just that little bit of extra stress that can be avoided while focusing on the main game of troubleshooting and configuration.

Anyhow - the topic of this post is my home lab environment. As I mentioned previously I decided that I would be going the virtualised router and physical switch path.

With the virtualised routers there were still some connectivity related issues to the physical switches that needed to be resolved.  Initially I figured the lowish cost of purchasing a number of Linksys USB200M ethernet NICs may do the job, and to be honest when I had about 4 of these things, they appeared to be fairly reliable even if it was quite messy and were natively supported with Ubuntu.  Once I went up to 12-14 of these things, they would seem to randomly decide to go out of service.

An alternate option is to use quad port ethernet NICs - however the motherboard in my server didn't support that many NICs, though I understand it is quite a good method to use.

In the end, I ended up purchasing a third 3550 to act as a breakout switch thanks to it's dot1q tunnelling and l2protocol tunneling support.  I wont go into detail on how to set up the breakout switch as there are good explanations on how to achieve this already.

My home lab is set up in my garage so that the fan noise does not drive the household crazy.  I have a Baytech RPC3 which enables me to remotely power on the kit to save on power costs - enabling me to work from my home office without having to walk in and turn things on.  Coupled with the VPN capability I previously set up, I can be pretty much anywhere on the internet and still work on my lab.

It's probably easiest for me to show the pictures and then describe if a bit more.

My home lab equipment lives in a Dell Rack which I picked up from Ebay last year, as you can see its only about half populated - plenty of room for more toys in the future.

Removing the doors and side panels, Looking at the front and going from top to bottom:

• 3550-24PWR acting as a Breakout Switch between the PC and the rest of the switches
• Cable Management
• 3750-24TS
• 3750-24TS
• 3550-24
• 3550-24
• Cable Management
• Dynamips PC in a Coolermaster Elite 360 case (Powered by an AMD 630 quad core processor with 4 Gig of RAM and running Ubuntu 10.04 a second NIC is installed to provide connectivity to the Breakout Switch)

Hidden under the tray that the PC is residing on is a management switch - it connects my home network to the RPC-3, The Dynamips PC and the 2610 Terminal Server (It's just a little Dlink 10/100 device I had lying around)

Looking from behind we can see:

• The Baytech RPC-3A which provides remote power control to everything else in the rack (except for the Dlink switch)
• The 2610 with NM-4A/S acting as a Terminal Server for the 3x3550s and 2x3750s
• The other gear is the front mounted 3750s, 3550s and Dynamips PC

To give an idea on the depth of the rack, here is a side view shot:

Right now I haven't selected a training vendor for the lab, so I have been really only playing around with things for my own learnings rather than following a structured plan - the cabling is basically:
Green for breakout switch to switch (representing router to switch connectivity)
Red for Switch-Switch connectivity
Yellow - out of band management

Layer 2 Technologies - Implement Frame Relay (Part 1)

1.60   Implement Frame Relay

(a) Local Management Interface (LMI)

(b) Traffic shaping

(c) Topologies

(e) Discard eligible (DE)

(f) Static versus Dynamic L2 to L3 Resolution

(g) Frame-Relay Interface-DLCI

(h) Broadcast Queue

(i) Frame End to End Keepalives

(j) Load Interval

(k) PING Local Interface


LMI

So, once upon a time, Cisco, Stratacom (who got bought out by Cisco), Northern Telecom (Nortel) and Digital Equipment Corporation (HP) got together to come up with a standard for signalling things like PVC status, addressing and multicast.  Frame Relay was proving a popular technology in the WAN space, so ANSI and the ITU also came up with their take on how to make LMI behave which is each slightly different and incompatible (not really an issue as such as routers can autosense the appropriate LMI type)

A Frame Relay router (DTE) can send an LMI Status Enquiry message to a Frame Relay switch (DCE) and the switch will reply with a LMI status message to get information about the VCs configured on the interface, with their DLCIs and status.   LMI messages are sent every 10 seconds, with every sixth message containing a full Status message (more detailed VC info)

The LMI Status Enquiry/LMI Status messages act as a keep alive function, if there is no activity on LMI after the typical 3 intervals (30 seconds), the interface is considered down at layer 2.

LMI is enabled/disabled with "keepalive/no keepalive" interface commands on the FR interface. It is possible to have back to back routers using FR with both interfaces with a Frame-relay interface-type DTE (default) and keepalive turned off to allow communications to occur at Layer 2.

LMI Type	Standards Reference	frame-relay lmi-type	Valid DLCI Range	LMI DLCI
Cisco	Proprietary	cisco	16-1007	1023
ANSI	ANSI T1.617 Annex D	ansi	16-991	0
ITU	ITU Q.933 Annex A	q933a	16-991	0

Traffic Shaping

Although traffic shaping is QoS topic and will be documented further in that topic area;FR has mechanisms that require mentioning on their own.

Traffic shaping is used on router to control the traffic flow towards the WAN to ensure that the outgoing traffic is within the purchased traffic contract (a 128kbps circuit

may be bought on an interface that is physically capable of delivering 1984kbps traffic)  Traffic shaping allows the user to take action on the traffic, for example smooth

some of the burstiness of the traffic at the cost of slightly delaying it, since the WAN provider will most likely drop out of contract traffic immediately on ingress into

their network or mark out of contract traffic as eligible to be dropped if their is network congestion further downstream.

Traffic shaping works on the concept of credits.  Each packet to be sent requires a credit for each bit to be transmitted.  If there is enough credit for the packet, it is

deducted from the interface credit balance and the packet enters the queue for transmission.

Cisco Terminology for Traffic Shaping

Abbreviation	Term	Definition
AR	Available Rate	This is the port speed defined by the DCE clock (for example 1984kbps)
CIR	Committed Information Rate	This is the target traffic rate - this is the traffic rate the route will attempt to send traffic out at
MinCIR	Minimum CIR	This is the guaranteed data rate the WAN provider will support, with all excess traffic being marked as DE (discard eligible)
Bc	Committed Burst	This is number of committed bits (credits) that can be sent during an interval
Be	Excess Burst	This is the number of excess burst bits (credits) above Bc a router can use in an interval (Tc) Be credits accumulate from unused Bc credits in previous intervals
Tc	Committed Rate Measurement Interval	This is the time interval for which Bc or Bc + Be can be transmitted.  Min 10ms, Max 25ms

Traffic Shaping Commands:

frame-relay traffic-shaping

This interface level command enables traffic shaping to occur for PVCs on the interface.  Note: All PVCs will receive a default CIR of 56kbps requiring specific configuration to change this.

map-class frame-relay

This global level command defines various FR parameters related to QoS and keepalives.
 
frame-relay cir

Map-class configuration command used to define the target transmit rate.

frame-relay mincir

Map-class configuration command used to define the guaranteed transmit rate - the default value is half cir and is only used for adaptive shaping

frame-relay bc

Map-class configuration command used to define the committed burst size.  Tc is indirectly defined and calculated from Bc/CIR

frame-relay be

Map-class configuration command used to define the excess burst size.

frame-relay adaptive-shaping

Map-class configuration used to enable adaptive traffic shaping.  The method can be becn (described below), foresight (Stratacom proprietary), or interface-congestion with a listed queue depth (allow egress limiting based on available output queue)

frame-relay fecn-adapt

Map-class configuration used to enable a router to reflect FECNs (Forward congestion notification is detected by the WAN switches and attached to Frames destined to the router, which then replies with frames that have BECN (Backward congestion notification) which informs the transmitting router that it needs to reduce its transmission rate

frame-relay class

Interface/sub-interface configuration used to bind the map-class to the interface.

class

frame-relay interface-dlci sub configuation used to bind a map-class to a particular PVC.  When a class is bound to both the interface and the PVC, the interface specific configuration details will be ignored and the PVC parameters used.

FR Topologies

Frame Relay enables a rich variety of logical topologies enabling direct connection, mesh and partial mesh configurations using point-to-point and point-to-multipoint configurations.  FR sub-interface configurations enable the possibility to have multiple point-to-point configurations enabling a L3 subnet per link, as opposted to the point-to-multipoint configurations where multiple links share the same L3 domain.  It is possible to combine these configuration types on the same physical interface.

Configuring Discard Eligiblity

The Router itself to mark time-sensitive traffic with the DE bit enabling an extra level of QoS at layer 2.  Refer to this note on CCO


Static versus Dynamic L2 to L3 Resolution

Dynamic Mapping occurs using Inverse ARP and is enabled by default. Inverse ARP matches looks at each active PVC and looks for the Layer 3 address associated with it (which is the reverse of ARP on ethernet).
Static mapping bypasses the use of Inverse ARP where a specific PVC is assigned reachability for one (or more) PVCs  (make sure to include the broadcast capability if you need to support multicast/broadcast protocols).

To disable inverse arp use the "no frame-relay inverse-arp" interface level command. Why might you want to not use dynamic mapping? The WAN SP may be advertising more PVCs than you are currently interested in (for example during a network migration) static mapping will ensure the right next hop is used.

show frame-relay map is used to show static or dynamic L2/L3 mappings

Frame-relay interface-dlci

The paragraph below is summarised from http://blog.ine.com/2008/08/14/that-pesky-frame-relay-interface-dlci-command/

This command is used:

• On point-to-point subinterfaces specifying the DLCI  (the remote side does not have to have an IP mapped to the DLCI since it is implied that non-local traffic on the subnet goes down the PVC)
• On multipoint subinterfaces when Inverse ARP is active
• Not used on physical interfaces because all DLCIs appear there by default (until a subinterface claims it)

When subinterfaces have map-classes associated with them, all PVCs inherit those parameters, however to attach a specific map-class to a PVC, sub commands of frame-relay interface-dlci is used to attach it.


Broadcast Queue

For large frame-relay hub and spoke networks, performance issues can manifest themselves particularly if there is a lot of broadcast traffic generated that requires replication across the PVCs such as routing protocol updates.  Cisco supports a dedicated interface level broadcast queue with its own traffic parameters limiting the maximum rate and is prioritised ahead of regular traffic when the throughput is below the limited rated.

frame-relay broadcast-queue 

Where is the byte size of the queue and and is the maximum transfer rate are specified for emptying the broadcast-queue onto the wire.

Frame-Relay End to End Keepalives

Using LMI, keepalives are used to determine remote host availability and logical circuit continuity .

Four methods are possible:

Bidirectonal mode - where each side sends out and waits for keepalive requests
Request mode - where only one side sends out and waits for keepalive responses
Reply mode - where only waits for and replies to keepalive requests
Passive-reply mode - which is like reply mode but doesn't use timers nor maintain event state

These are configurable per PVC using the frame-relay map-class configurations

frame-relay end-to-end keepalive event-window - this is the size of the event window (default send and recieve is 3)
frame-relay end-to-end keepalive mode - this is the mode of operation (bidirectional, request, reply, passive-reply)
frame-relay end-to-end success-events - how many keepalive success events must occur to bring a down interface up (default 2)
frame-relay end-to-end timer - configures the timers (default send 10s, default receive 15s)

Load-Interval

When you use the "show interface " command, the interface statistics are updated based on the load-interval which by default is 300 seconds.  When testing aspects of traffic shaping, waiting 5 minutes can be annoying, setting the load-interval to the lowest value (30 seconds) can be closer to realtime for viewing behaviour.  

The configuration can be applied directly to the physical interface, or in the frame-relay interface-dlci sub configuration.

Ping Local Interface

Blog post http://blog.ine.com/2009/12/02/ping-thyself-in-frame-relay/

Summary: By default you cannot ping your local frame-relay IP address unless you include a frame-relay map ip for the local interface address

Still about!

Study has slowed down a bit lately but not completely halted.  For the last few weeks my workload has increased and I have had to do a little interstate travel for work related activities as well.

I've been working on MPLS related services on non-Cisco platforms which has been good to view how different members of industry implement similar things.

On the homelab front - I believe that I have secured my final ethernet switch.  Joining my existing 3550-24PWR and 3750-24s is a 3350-24.

The break over Easter hasn't really been open for study but I think I'll get in now while I can and put together some Frame Relay notes.

Layer 2 Technologies - SPAN, RSPAN and 802.3x Flow Control

This should be the last blueprint topic specifically covering ethernet, and it is a relatively short one... (That's not to say that I wont need to come back and clarify or elaborate on this or the previously documented topics)

1.50    Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control
(a) SPAN and RSPAN
(b) Flow Control


SPAN and RSPAN

The Switch Port Analyser (SPAN) and Remote SPAN (RSPAN) functions are Well documented on CCO. SPAN is particularly handy for troubleshooting with packet analysis tools like Wireshark or for use with security appliances like an IDS to determine if your network is under attack.

A SPAN port is contained locally on a switch, while RSPAN is configured across multiple switches and delivered over a dedicated VLAN (intermediate transport switches do not have to be RSPAN capable unless they are interacting with the RSPAN VLAN)


While it is possible to have multiple sessions in operation, these are the basic rules around SPAN/RSPAN ports:

•     For SPAN sources, you can monitor traffic for a single port or VLAN or a series or range of ports or VLANs for each session. You cannot mix source ports and source VLANs within a single SPAN session.
•     The destination port cannot be a source port; a source port cannot be a destination port.
•     You cannot have two SPAN sessions using the same destination port.
•     When you configure a switch port as a SPAN destination port, it is no longer a normal switch port; only monitored traffic passes through the SPAN destination port

SPAN ports have the capability to include the source interface encapsulation headers if the "encapsulation replicate" configuration setting is included.  RSPAN transports monitored frames without the encapsulation headers

Flow Control

There is a very good article about Ethernet Flow Control by Petr Lapukhov The main take away is that Cisco switches do not generate PAUSE Frames (though they can receive them) the issue is in QoS enabled networks, the pausing frames is an indiscriminate action that can impact priority traffic as well as best effort.  Flow control is disabled by default and is not recommended for QoS enabled networks.

These are the impacts on flow control settings for an interface:

flowcontrol receive on (or flowcontrol receive desired) - The interface cannot send pause frames but can operate with an attached device that is required to or can send pause frames; the interface can receive pause frames.

flowcontrol receive off - Flow control does not operate in either direction. In case of congestion, no indication is given to the link partner, and no pause frames are sent or received by either device.

Layer 2 Technologies - Implement Ethernet

So far all of the Layer 2 technologies have been related to Ethernet and it's implementation of some kind (well I guess things like IRB and CRB can use alternate technologies)

1.40    Implement Ethernet technologies

(a) Speed and duplex

(b) Ethernet, Fast Ethernet, and Gigabit Ethernet

(c) PPP over Ethernet  (PPPoE)


Speed and Duplex

I guess this goes back to CSMA/CD roots with garden hose size coaxial cable (ThickNet) and vampire taps towards the more typical full-duplex things we see today.

The bus based network had everyone sitting on the same transmission medium (the MA part is multiple access).  When a station wanted to talk it needed to be sure no one else was talking before it tried to talk (CS as in carrier sense) since it is possible that someone started talking at the same time as you, you needed to listen and be sure you didn't hear something on the wire that was different to what you were transmitting (the something different was a collision - the CD is collision detect) if you detected that a collision occured, you would send out a Jam signal to ensure that the other transmitting station knew that there was a problem and you would both wait a random amount of time before trying to transmit again.  It wasnt the most efficient means, I think peak efficiency is somewhere around 50% of the link bandwidth but it was relatively cheap and allowed you to "easily" add hosts onto the network.  This kind of duplexing (capability for both transmit and recieving) is called half-duplex since only one station can talk at a time.

A full-duplex connection is a dedicated point-to-point connection with a dedicated line for transmission and reception meaning that collisions don't occur and you could potentially max the link in the transmit and receive directions.

Ethernet, Fast Ethernet, and Gigabit Ethernet

"Ethernet" interfaces can support 10Mbps and usually support full-duplex (some really old interfaces only do half-duplex)

"FastEthernet" interfaces can be configured to be 10Mbps or 100Mbps with either half or full duplex.

"GigabitEthernet" interfaces can be usually configured to be 10, 100 or 1000Mbps with either half or full duplex (however some GBIC or SFPs are capable of a single speed only)

Autonegotiation

The IEEE 802.3u standard which introduced FastEthernet allowed automatic negotiation of speed and duplex between endpoints.  If one side was hard set, with the other set for auto negotiate, it is possible to get a duplex mismatch if the hard set side was set for full-duplex (although auto negotiate can correctly select the speed for a hard set interface, it will assume half-duplex on the auto negotiate side)

Common practice used to be to not to use autonegotiation and hard set interface options, however recommendations these days are to have both sides be auto negotiate as items such as flow control can be appropriately negotiated and other keep alive mechanisms be used that would not otherwise be available.

PPPoE

A PPPoE configuration is relatively common in a situation where you have an Ethernet WAN device that is connected to an ADSL modem that is in a bridge configuration (the DSL mode bridges Ethernet Frames on to an ATM PVC which terminates on a BRAS/BNG of the ISP)

PPPoE has an 8 byte overhead so a typical 1500 Byte MTU interface will actually be 1492 bytes when using PPPoE (this may need to be considered if using a protocol such as OSPF)


PPPoE Client configuration example (CHAP Authentication of client, Obtain IP address from Server)

interface FastEthernet0/0
 description Ethernet WAN to PPPoE Server Fa0/0
 pppoe enable
 pppoe-client dial-pool-number 1
!
interface Dialer1
 ip address negotiated previous
 encapsulation ppp
 dialer pool 1
 dialer persistent
 ppp chap hostname client ppp chap password 0 pppoe
!

PPPoE Server configuration (CHAP Authentication of Client against the local database and address allocation using IPCP) Note: PPPoE no longer uses VPDN configuration, and while IOS will convert to PPPoE VPDN config to a bba-group config once, it's best to know how to do it correctly.

aaa new-model
aaa authentication ppp default local
username client password 0 pppoe

ip dhcp excluded-address 192.168.200.254
ip dhcp pool PPPoE
 network 192.168.200.0 255.255.255.0
!
bba-group pppoe global
 virtual-template 1
!
interface Virtual-Template1
 ip unnumbered FastEthernet0/0
 peer default ip address dhcp-pool PPPoE
 ppp authentication chap
!
interface FastEthernet0/0
 description Ethernet WAN to PPPoE Client Fa0/0
 ip address 192.168.200.254 255.255.255.0
 pppoe enable
!

Below is a debug ppp negotation and debug ppp authentication on the PPPoEServer as the client connects (interestingly, we see that CDP is not enabled across the connection)

*Mar  1 00:54:37.103: ppp7 PPP: Send Message[Dynamic Bind Response]
*Mar  1 00:54:37.103: ppp7 PPP: Using vpn set call direction
*Mar  1 00:54:37.107: ppp7 PPP: Treating connection as a callin
*Mar  1 00:54:37.107: ppp7 PPP: Session handle[3A000009] Session id[7]
*Mar  1 00:54:37.107: ppp7 PPP: Phase is ESTABLISHING, Passive Open
*Mar  1 00:54:37.107: ppp7 LCP: State is Listen
*Mar  1 00:54:37.187: ppp7 LCP: I CONFREQ [Listen] id 1 len 10
*Mar  1 00:54:37.191: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.191: ppp7 PPP: Authorization NOT required
*Mar  1 00:54:37.195: ppp7 LCP: O CONFREQ [Listen] id 1 len 19
*Mar  1 00:54:37.199: ppp7 LCP:    MRU 1492 (0x010405D4)
*Mar  1 00:54:37.199: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.199: ppp7 LCP: O CONFACK [Listen] id 1 len 10
*Mar  1 00:54:37.199: ppp7 LCP:    MagicNumber 0x01448040 (0x050601448040)
*Mar  1 00:54:37.211: ppp7 LCP: I CONFNAK [ACKsent] id 1 len 8
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP: O CONFREQ [ACKsent] id 2 len 19
*Mar  1 00:54:37.215: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.215: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.215: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: I CONFACK [ACKsent] id 2 len 19
*Mar  1 00:54:37.227: ppp7 LCP:    MRU 1500 (0x010405DC)
*Mar  1 00:54:37.227: ppp7 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:54:37.227: ppp7 LCP:    MagicNumber 0x0044CEAE (0x05060044CEAE)
*Mar  1 00:54:37.227: ppp7 LCP: State is Open
*Mar  1 00:54:37.227: ppp7 PPP: Phase is AUTHENTICATING, by this end
*Mar  1 00:54:37.231: ppp7 CHAP: O CHALLENGE id 1 len 23 from "R1"
*Mar  1 00:54:37.239: ppp7 CHAP: I RESPONSE id 1 len 27 from "client"
*Mar  1 00:54:37.243: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.247: ppp7 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar  1 00:54:37.251: ppp7 PPP: Sent CHAP LOGIN Request
*Mar  1 00:54:37.255: ppp7 PPP: Received LOGIN Response PASS
*Mar  1 00:54:37.255: ppp7 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:54:37.259: ppp7 PPP: Send Message[Connect Local]
*Mar  1 00:54:37.279: ppp7 PPP: Bind to [Virtual-Access1.1]
*Mar  1 00:54:37.283: Vi1.1 PPP: Send Message[Static Bind Response]
*Mar  1 00:54:37.299: Vi1.1 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar  1 00:54:37.299: Vi1.1 CHAP: O SUCCESS id 1 len 4
*Mar  1 00:54:37.307: Vi1.1 PPP: Phase is UP
*Mar  1 00:54:37.311: Vi1.1 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 00:54:37.315: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:37.319: Vi1.1 PPP: Process pending ncp packets
*Mar  1 00:54:37.371: Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 00:54:37.371: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:37.383: Vi1.1 CDPCP: I CONFREQ [Not negotiated] id 1 len 4
*Mar  1 00:54:37.383: Vi1.1 LCP: O PROTREJ [Open] id 3 len 10 protocol CDPCP (0x820701010004)
*Mar  1 00:54:39.275: Vi1.1 IPCP: Timeout: State REQsent
*Mar  1 00:54:39.279: Vi1.1 IPCP: O CONFREQ [REQsent] id 2 len 10
*Mar  1 00:54:39.283: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.375: Vi1.1 IPCP: Pool returned 192.168.200.20
*Mar  1 00:54:39.379: Vi1.1 IPCP: O CONFNAK [REQsent] id 1 len 10
*Mar  1 00:54:39.379: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.383: Vi1.1 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 00:54:39.387: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.387: Vi1.1 IPCP: ID 1 didn't match 2, discarding packet
*Mar  1 00:54:39.391: Vi1.1 IPCP: I CONFACK [REQsent] id 2 len 10
*Mar  1 00:54:39.395: Vi1.1 IPCP:    Address 192.168.200.254 (0x0306C0A8C8FE)
*Mar  1 00:54:39.399: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 00:54:39.399: Vi1.1 IPCP: O CONFNAK [ACKrcvd] id 2 len 10
*Mar  1 00:54:39.399: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.407: Vi1.1 IPCP: O CONFACK [ACKrcvd] id 3 len 10
*Mar  1 00:54:39.407: Vi1.1 IPCP:    Address 192.168.200.20 (0x0306C0A8C814)
*Mar  1 00:54:39.411: Vi1.1 IPCP: State is Open
*Mar  1 00:54:39.431: Vi1.1 IPCP: Install route to 192.168.200.20

On the server, if we execute a show users, we can see the client is connected based on the CHAP user name, the VirtualAccess Interface it is terminated on and the assigned IP address

Server#sh users
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface    User               Mode         Idle     Peer Address
  Vi1.1        client             PPPoE        -        192.168.200.20

Client# sh ip route connected
C    192.168.10.0/24 is directly connected, FastEthernet0/1

     192.168.200.0/32 is subnetted, 2 subnets
C       192.168.200.254 is directly connected, Dialer1
C       192.168.200.20 is directly connected, Dialer1

Layer 2 Technologies - Trunking and Etherchannels

1.00    Implement Layer 2 Technologies

1.30    Implement trunk and trunk protocols, EtherChannel, and load-balancing
a) DTP (Dynamic Trunking Protocol)

b) Etherchannels

c) Allowed VLAN

d) Router on a Stick

e) Native VLAN

DTP

Dynamic Trunking Protocol (DTP) is a Cisco switch only (not supported on routers) protocol where a switch will attempt to automatically negotiate the capability to support VLAN trunking on an interface.  If DTP fails, the interface will remain in access rather than trunking mode.

For DTP negotiation to occur, both switches need to be in the same VTP domain.  By default interfaces are set for DTP operation (by an implied no switchport nonegotiate).  To disable DTP on an interface "switchport nonegotiate" must be configured

Interface Configs for working trunks

Configuration Side A	Short Name	Description	For Trunking Configure Side B with
switchport mode trunk	Trunk	Always Trunking Side A and sends DTP Frames to Side B to help determing Trunking Mode	switchport mode trunk switchport mode trunk + switchport nonegotiate, switchport mode dynamic desirable, switchport mode dynamic auto
switchport mode trunk switchport nonegotiate	Nonegotiate	Always Trunking Side A no DTP Frames sent to Side B	switchport mode trunk, switchport mode trunk + switchport nonegotiate
switchport mode dynamic desirable	desirable	Sends DTP Frames sent to Side B, trunks if negotiation succeeds	switchport mode trunk, switchport mode dynamic desirable, switchport mode dynamic auto
switchport mode dynamic auto	auto	Replies to DTP Frames sent from Side B, trunks if negotiation succeeds	switchport mode trunk, switchport mode dynamic desirable
switchport mode access	access	Sends DTP Frames sent to Side B, but never trunks	No config results in a working trunk
switchport mode access switchport nonegotiate	access nonegotiate	No DTP Frames sent to Side B never trunks	No config results in a working trunk

Trunk Encapsulation

Cisco propietary ISL encapsulate ethernet frames within an ISL frame that has 26 byte header and 4 byte CRC (encapsulated frames are sent with the switch src MAC to a multicast destination)

IEEE 802.1Q trunks insert a 4 byte tag into the existing ethernet frame.  The 4 bytes are inserted where the Type/Len field would be.  the Ethertype is 0x8100 to identify the frame as being an 802.1Q frame, and the other two bytes include a 12 bit VLAN ID and 3 bit Priority Tag (802.1p)

If the trunk encapsulation is not specified, and switches support both ISL and 802.1q, DTP will negotiated an ISL trunk in preference to an 802.1q trunk.  However if one side of a link specifies a particular encapsulation type, DTP will negotiate only for that type.

Link Aggregation (Etherchannels)

If we recall the point about STP, it was introduced to allow for redundant links in a network but since Ethernet can only work in a loop free topology, STP has to break the loops by placing a looping port into a blocking state.  This means that simply adding parallel ethernet links to increase bandwidth doesn't work on its own.  To get around this, we can logically bundle multiple physical interfaces into a PortChannel/EtherChannel bundle.  STP then uses the Portchannel interface for its topology information rather than the underlying physical interfaces.

There are three methods to enable link aggregation, hard coding, the Cisco propietary Port Aggregation Protocol (PAgP) or the IEE 802.1AD standard Link Aggregation Control Protocol (LACP)


Interface LACP/PAgP Configuration (channel-group mode xxx)

LACP	PaGP	Result
on	on	Disables LACP/PAgP and forces port into becoming part of the PortChannel (No negotation)
off	off	Disables LACP/PAgP and prevents the port for becoming part of the PortChannel (No negotation)
passive	auto	This interface waits for the other side to send LACP/PAgP frames before responding and negotiate joining the Portchannel (If both sides set to this mode, they will not negotiate a port channel)
active	desirable	This interface actively sends LACP/PAgP frames to negotiate joining the Portchannel

In order for a Portchannel to be correctly configured, the physical interfaces have to be of the same type (FastEthernet, GigabitEthernet etc) and the underlying physical (e.g. speed, duplex, no SPAN) and logical configurations (e.g. VLAN or trunk configuration including Native VLAN and STP costs) also need to match.  Portchannels can be L2 (switchport) which can support VLAN trunking or L3 (no switch port) interfaces just like single physical interfaces.

Load Balancing across Etherchannels

In order to support load balancing across multiple links, a hashing algorithm is used. The data that is inputted into the algorithm can be selected to best match the particular traffic type that is traversing the Portchannel.  For example, most of the traffic heading from an access switch to a distribution switch is most likely heading towards the default router (Many source MAC addresses but a single destination MAC address) which may suggest an optimal configuration of  using source-mac from the egress of the access switch to the distribution switch while using destination-mac on the other side of link.  "port-channel load-balance " is the command, where can be used to select source/destination MAC, IP or UDP/TCP ports as the input.

Allowed VLANs

By default, all VLANs can traverse all trunk ports on a switch (assuming that VTP pruning isn't operational) to provide security or control where switch traffic can go it is possible to specifically list which VLANs can traverse a trunk port (switchport trunk allowed vlan xxx)  Router Trunk ports implicitly have this capability since subinterfaces created with "encapsulation dot1q xxx" are created as the configuration demands it and the router silently discards traffic for unconfigured VLAN ids.

Router on a Stick

A router on a stick is simply a router that connects to a switch with a VLAN trunk interface and routes between the VLANs, each VLAN is associated with a separate subnet and has to traverse the router to reach a host on the other subnet.


Native VLAN

The Native VLAN is a VLAN that on a VLAN trunk interface which does not have a VLAN tag.  By default VLAN 1 is the native VLAN but can be configured (switchport trunk native vlan xxx)

On a router, the main interface (untagged) is normally the native VLAN

interface FastEthernet0/0
 ip address 1.0.0.1 255.255.255.0
!
interface FastEthernet0/0.10
 encapsulation dot1q 10
 ip address 1.0.10.1 255.255.255.0
 
It is possible to specify an untagged frame to to be associated with a vlan interface on the router using the native statement as seen below:

interface FastEthernet0/1.22
 encapsulation dot1q 22 native
 ip address 1.1.22.1 255.255.255.0

Note: CDP can complain if there is a native VLAN mismatch between devices if they are not the same, while this will not break operation is can fill the logs with annoying warnings if the configuration is correct for the environment.  CDP v2 messages include the Native VLAN information, so if an interface is configured for v1 "no cdp advertise-v2" these warnings will stop, giving an alternative to disabling CDP on that interface (CDP can be seen as a security risk to some, however for the purposes of labbing, I think it's fine)