Jul 26 2009
Frame-Relay Local Switching
Consider the topology below.
CE1 and CE2 connect to PE1 using frame-relay. Pe1 switches CE1 traffic to CE2 and vice versa transparently.
Watch the video below or download and watch it on your ipod.
Jul 26 2009
Consider the topology below.
CE1 and CE2 connect to PE1 using frame-relay. Pe1 switches CE1 traffic to CE2 and vice versa transparently.
Watch the video below or download and watch it on your ipod.
By Zarar • CCIE SP, iPod • 2 • Tags: CCIE SP, Frame-Relay
Jul 11 2009
Intro Top
You can configure L2TPv3 in 3 Modes.
Manual Mode
Manual Mode with Keep Alive
Dynamic Mode
Manual Mode is where you manually specify the session characteristics on both sides of the session ie no session negotiation takes place.
Configurable components of L2TPv3 are : Top
xconnect
Pseudowire-class
l2tp-class xconnect
xconnect Top
The xconnect command is configured under the interface to bind the attachment circuit to the pseudowire session. The syntax is as follows:-
xconnect peer-ip vcid pseudowire-paramaters [sequencing {transmit | receive both}]
The peer ip address is usually the loopback address of the remote PE. The vcid is a 32 bit virtual circuit identifier and should match on both sides of the pseudowire. There are two options for the pseudowire-paramaters you can configure define encapsulation or use a pw-class (see examples of both below)
xconnect 3.3.3.3 100 encapsulation l2tpv3
xconnect 3.3.3.3 100 pw-class ZARAR
The pw-class is a mandatory argument when l2tpv3 manual mode is used as the encapsulation method.
sequencing {transmit | receive both}
This is an optional argument that is used primarily when configuring l2tpv3 in manual mode. If sequencing is enabled then out of order packets are dropped.
Pseudowire-class Top
The pseudowire inherits the session characteristics defined in the Pseudowire-class. To define a Pseudowire-class use the commands below:
Pseudowire-class [Pseudowire-class-name]
Once you enter this mode, the CLI drops you into a pw-class configuration mode. In this mode the following configuration options are available.
encapsulation Top – Defines the tunneling method. Initially this is the only command available to the user as the other options listed below depend on the encapsulation type.
ip local interface interface Top name – defines the source of the l2tpv3 control and data packets.
protocol {l2tpv3|none} [l2tp-class-name] Top – defines whether l2tpv3 is used for session negotiation (For manual mode the protocol is none)
sequencing {transmit | receive both} Top – same as described above
ip dfbit set Top – Sets the dfbit for the IP Packet header of the l2tpv3 packets.
ip pmtu Top – enables the discovery of PMTUD
ip tos Top {value value | reflect} – set the ip tos for the IP Packet header of the l2tpv3 packets. reflect copies the TOS of the payload IP packet to the P Packet header of the l2tpv3 packets.
ip ttl value Top – sets the ip ttl for the IP Packet header of the l2tpv3 packets.
ip protocol {l2tp|uti} - Top allows interoperability with UTI.
l2tp-class Top
The l2tp-class defines the session characteriscts for the control channel. The l2tp-class is referenced in the Pseudowire-class. To define a l2tp-class use the commands below:
l2tp-class [l2tp-class name]
Once you enter this mode, the CLI drops you into a l2tp-class configuration mode. In this mode the following configuration options are available.
cookie size [4|8] [size] Top- option is either to send a 4 or 8 byte cookie. by default cookie length is zero.
timeout setup Top – time permitted to setup the control channel
authentication Top – enables CHAP-like authentication between peers
hostname Top – used to identify the local device in chap authentication. By default router hostname name is used.
password Top- preshared secret.
hidden Top – used to hide sensitive AVPs.
hello Top- defines the keepalive interval once control channel is setup. The default is 60Seconds.
By Zarar • CCIE SP, L2TPv3 • 0 • Tags: CCIE, CCIE SP, L2TPv3
Jul 4 2009
There are 4 items you need to understand to tackle any RMON questions.
they are:-
RFC 1213
OLD-CISCO-CPU-MIB
OLD-CISCO-SYS-MIB
CISCO-PROCESS-MIB
Lets begin with RFC1213
Lets take the ifEntry object in RFC1213 as an example. ifEntry contains the following objects.
ifIndex { ifEntry 1 }
ifDescr { ifEntry 2 }
ifType { ifEntry 3 }
ifMtu { ifEntry 4 }
ifSpeed { ifEntry 5 }
ifPhysAddress { ifEntry 6 }
ifAdminStatus { ifEntry 7 }
ifOperStatus { ifEntry 8 }
ifLastChange { ifEntry 9 }
ifInOctets { ifEntry 10 }
ifInUcastPkts { ifEntry 11 }
ifInNUcastPkts { ifEntry 12 }
ifInDiscards { ifEntry 13 }
ifInErrors { ifEntry 14 }
ifInUnknownProtos { ifEntry 15 }
ifOutOctets { ifEntry 16 }
ifOutUcastPkts { ifEntry 17 }
ifOutNUcastPkts { ifEntry 18 }
ifOutDiscards { ifEntry 19 }
ifOutErrors { ifEntry 20 }
ifOutQLen { ifEntry 21 }
ifSpecific { ifEntry 22 }
You can see the above objects in IOS using the command
show snmp mib
If you want to refer to the number of output interface errors you can use either of the following two statements.
ifOutErrors
ifEntry.20
If you want the output interface errors for a specific interface you will need to append the interface index(ifIndex) to the above statement. To obtain the ifIndex use the command below.
show snmp mib ifmib ifindex
GigabitEthernet0/1: Ifindex = 2
Serial0/1/0: Ifindex = 4
Therefore our 2 options for monitoring output interface errors for gig0/1 become.
ifOutErrors.2
ifEntry.20.2
Now lets create a RMON alarm using the above 2 options.
option 1
rmon alarm 5 ifOutErrors.2 10 delta rising-threshold 100 1 falling-threshold 50 owner config
option 2
rmon alarm 6 ifEntry.20.2 10 delta rising-threshold 100 1 falling-threshold 50 owner config
The interesting thing to note if you use option 2 is that IOS changes the syntax to that of option 1 in the running config. See below
show run | in rmon alarm 6
rmon alarm 6 ifOutErrors.2 10 delta rising-threshold 100 1 falling-threshold 50 owner config
now lets monitor the CPU usage on a box.
For this we need to refer to the MIBs below.
OLD-CISCO-CPU-MIB
OLD-CISCO-SYS-MIB
CISCO-PROCESS-MIB
The first two MIBs ie the ones which begin with the word old refer the the CPU usage as follows:
The main object is lcpu which also known as lsystem. This object contains the following objects(I’ve only listed some of the objects below – Please see the links above for more info.
busyPer { lcpu 56 } – Monitors the CPU over a 5 second interval
avgBusy1 { lcpu 57 } – Monitors the CPU over a 1 minute interval
avgBusy5 { lcpu 58 } – Monitors the CPU over a 5 minute interval
Lets suppose we want to use RMON to monitor the cpu utilisation over a 1 minute period.
we could use any of the following to refer to the SNMP 1 minute monitoring object.
lcpu.57.0
lsystem.57.0
However when we enter the rmon alarm commands, both of the above options will show as lsystem.57.0. (If you are wondering where the .0 came from, it refers to the CPU I think, without it the rmon command wont take lsystem.57 alone.)
The SNMP MIB CISCO-PROCESS-MIB contains also contains some MIBs for monitoring the CPU (see below). It also states that it deprecates the avgBusy1 in the OLD-CISCO-SYSTEM-MIB.
cpmCPUTotal1min OBJECT-TYPE
SYNTAX Gauge32 (1..100)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
“The overall CPU busy percentage in the last 1 minute
period. This object obsoletes the avgBusy1 object from
the OLD-CISCO-SYSTEM-MIB. This object is deprecated
by cpmCPUTotal1minRev which has the changed range
of value (0..100).”
::= { cpmCPUTotalEntry 4 }
The tree for this object would be as follows:
cpmCPUTotalTable.1.5.0
however when I punch this into the router it doesn’t seem to like it. If anyone else has any experiences with this please share it.