L2VPN Over IP/MPLS

Layer 2 circuits are becoming order of the day. Every service provider desires layer 2 circuits from the other service provider to provision its customers. It can be configured by two methods
a) Point to Point
b) Point To Multipoint
Currently ISR , 6500 and 7200 series supports point to point and 7600 supports point to multipoint. Point to multipoint is also known to VPLS (Virtual Private Lan Services). In this post I will explain about point to point circuit and its provisioning. Services offer on two type of cloud
a) IP Cloud
b) MPLS Cloud
If service provider is using IP cloud, L2 services offer by encapsulation l2tpv3 and if cloud is MPLS enabled then encapsulation mpls can be used. So the difference is lucid. In the given scenario customer is having l2 domain and want to use the l2 services across the service provider cloud. A simple l2 session will be created between Delhi PE and HYD PE over ip cloud on the basics of loopbacks. The provisioning is trouble-free and easy to configure.
Steps for Configuring Layer 2 Services across Service Provider IP Backbone
a) Configure basic IGP.
b) Create PSEUDOWIRE name SHIVLU & use the encapsulation L2TPv3 as source loopback of the router.
c) On Physical interface where the client is coming create a xconnect as destination address of loopback HYD PE & vice versa.
Commands For Creating L2 VPN
Pseudowire SHIVLU
Ip local interface loopback 0
Encapsulation l2tpv3

Interface Specific Command
Interface x/y
Xconnect 400 pw-class SHIVLU
Note:- 400 is the Virtual Circuit ID and it should be the same on the remote end also.

Verify L2 Circuit
After “Show l2 session circuit vcid 400” you can see the est state of l2 session. Now ping end to end laptop.

QoS Policing in Cisco IOS

The activity called policing or rate limiting in various Cisco IOS releases is actually a traffic contract conformance measurement that can result in marking (changing QoS attributes of individual packets in the traffic flow) or policing (dropping of packets violating the traffic contract).
This document describes various algorithms used to implement rate limiting on non-distributed software-based router platforms running Cisco IOS. Distributed platforms (Cisco 7600, GSR) might use different algorithms depending on software release and the hardware QoS implementations on Catalyst switches differ significantly from the software ones.

Cisco IOS Implementations

Cisco IOS implements policing/marking functionality with two unrelated mechanisms:

• The rate-limit command implements per-interface input- and output-rate limiting.
• The police command implements the traffic measurement within the scope of the Modular QoS Command Line Interface (MQC).

Rate-limit commands and QoS policy-maps containing the police command can measure inbound or outbound packets on physical or logical interfaces (tunnels, subinterfaces). They introduce no delay (apart from slightly increased CPU load on the router) in the packet forwarding mechanism.

Rate-limit command

The rate-limit interface configuration command can match packets based on IP access lists, IP precedence settings, DSCP settings, QoS groups or source MAC addresses. It can set the IP precedence, DSCP or MPLS QoS bits in the measured packets, or group the packets into QoS groups.
The rate-limit command uses dual token bucket mechanism and drops all packets that exceed the excess burst size.

Police action

The police action specified within a class in a policy-map can use three different measurement mechanisms:

• Single token bucket measurement is used when the police command specifies only the conform and exceed actions.
• Dual token bucket measurement is used to support conform, exceed and violate actions.
• Dual-rate dual token bucket measurement is used when the police command specifies cir and pir rates.

As the traffic measurement takes place within a traffic class defined by a class-map, any criteria supported by the class-map configuration command can be used to define the traffic class.
Each police command can specify three types of actions:

• The conform action is executed for packets within the average rate and burst size.
• The exceed action for a police command specifying traffic rate is executed for packets within the average rate and excess burst size.
• The exceed action for a police command specifying pir rate is executed for packets within the excess rate and excess burst size.
• The violate action is executed for packets that exceed excess rate/burst size.

The actions executed by the police command can pass the packet unmodified, drop it or mark it. The following QoS attributes of a packet can be modified:

• IP precedence;
• IP Differentiated Services Control Point (DSCP);
• Discard class (within the DSCP field);
• ATM Cell Loss Priority (CLP) – used only for packets transmitted over an ATM interface;
• Ethernet 802.1q Class of Services (CoS) marking;
• MPLS QoS (experimental) bits – used only for MPLS-encapsulated packets;
• Frame Relay Discard Eligibility (DE) bit – used only for packets transmitted over an outbound Frame Relay interface;
• QoS group (an extra marker internal to the router).

Measurement Mechanisms

The traffic contracts conformance measurement is usually performed with a token bucket algorithm:

• The token bucket size defines the initial burst size that can exceed the average rate.
• Tokens (conforming-bytes or conforming-packets) are added to the bucket at a constant rate (the average traffic arrival/departure rate). Tokens exceeding the bucket size are dropped.
• Each conforming packet consumes the tokens relative to its size (when measuring packet rate, each packet consumes a single token). Packets exceeding the traffic contract do not consume tokens.

Single Token Bucket Algorithm

The single token bucket algorithm is used for simple traffic contracts that differentiate the measured packets into conforming and non-conforming. The police command using a single token bucket algorithm can specify:

• Average traffic bit rate with the rate speed bps parameter or rate percentage percent parameter.

The rate specified with the percent parameter is calculated based on the bandwidth settings of the interface to which the policy-map is applied.

• Average packet rate with the rate number pps parameter.
• Burst size with the burst size parameter.
• Conform and exceed actions with the conform-action and exceed-action keywords.

IOS release 12.4T supports multiple conform-action and exceed-action commands.

The single token bucket algorithm is illustrated in the following figure:

To optimize the token bucket algorithm, the tokens are added to the bucket that the packet arrival time using the following formula: Bucket_new = Min(BurstSize,Bucket_Old + Interpacket-Time * MeasurementRate)

Example

The following router configuration measures the web traffic received through a serial interface and drops all packets exceeding the 512000 bps average rate:

class-map match-any Web
 match protocol http
 match protocol secure-http
 !
policy-map MeasureWeb
 class Web
   police rate 512000 bps
     conform-action transmit
     exceed-action drop
!
interface Serial1/0
 service-policy input MeasureWeb

Dual Token Bucket Algorithm

Slightly more flexible traffic contracts might allow extra (best-effort) packets beyond the average rate/burst size specification. These packets are usually marked differently from the in-contract packets and transported across the network only if it's not congested. In most scenarios, the extra packets are allowed only in the initial burst (long-term traffic rate cannot exceed the average rate) and are measured with an extra token bucket (exceed bucket) as shown in the following diagram:

Dual token bucket contracts are common in ATM environments (where the excess cells are marked with CLP bits) and Frame Relay environments (where the excess frames are marked with the DE bit).
The dual token bucket algorithm is used by the rate-limit command specifying the exceed option and the police command specifying the exceed-action and violate-action. In both cases, the size of the excess burst (but not the average excess rate) can be set.

Example

The following router configuration allows e-mails to be sent at line speed if the size of the transfer does not exceed 100 kilobytes. However, the packets exceeding the 128kbps average rate and the 16 kilobytes initial burst size will be marked with a different DSCP value.

class-map match-any Mail
 match protocol smtp
 !
policy-map LimitEmails
 class Mail
   police rate 128000 burst 16000 peak-burst 100000
     conform-action transmit
     exceed-action set-dscp-transmit af13
     violate-action drop

Dual Rate Policing

In Frame Relay environment, the traffic contracts commonly specify average rate (Committed Information Rate – CIR) as well as constant excess rate (Excess Information Rate – EIR – or Peak Information Rate – PIR) that the customers can use.

The EIR mechanism is different from the excess burst size; the excess burst prolongs the initial packet burst (marking some packets as exceeding the contract) while the EIR allows long-term transmission of excess packets.

The CIR/EIR or CIR/PIR policing requires two independent token buckets as shown in the following diagram. Each bucket independently measures the traffic conformance to the average or peak/excess rate; there is no overflow from the conforming bucket to the excess bucket.

The dual rate policing is configured with the police command specifying cir and pir' rates or rate and peak-rate parameters. In both cases, you can specify the burst size and the peak-burst size (they could be different). You also have to specify conform-action', exceed-action and violate-action; without the violate-action, the single token bucket measurement will be used.

Example

The following service policy can be used on a Frame Relay interface to set the DE bits on excess packets and drop out-of-contract packets:

policy-map FrameRelay
 class class-default
   police cir 128000 pir 256000
     conform-action transmit
     exceed-action set-frde-transmit
     violate-action drop
!
interface serial 1/0.1
 frame-relay interface-dlci 100
 service-policy output FrameRelay

BGP Attribute Types and Flags Continues

BGP Attributes: Atomic Aggregate Atribute

Atomic aggregate is a Well-known Discretionary attribute; it must be recognized by all BGP implementations and does not have to exist in all BGP updates.
The purpose of the attribute is to alert BGP speakers along the path that some information have been lost due to the route aggregation process and that the aggregate path might not be the best path to the destination.
When some routes are aggregated by an aggregator, the aggregator does attache its Router-ID to the aggregated route into the AGGREGATOR_ID attribute and it sets the ATOMIC_AGGREGATE attribute or not; based on whether the AS_PATH information of the aggregated routes were preserved or not.
AS_PATH information are preserved if you use the AS_SET segment in the AS_PATH attribute. The AS_SET segment is part of the AS_Path attribute and is used to store an unordered list of AS_PATH information of all aggregated routes to prevent possible routing loops. If the AS_SET is not used in the aggregation process the AS_PATH  information of the aggregated routes are not preserved and the ATOMIC_AGGREGATE attribute then must be set. However, if the AS_SET is used then PATH information is preserved and the ATOMIC_AGGREGATE attribute is cleared because no information was lost by the aggregation process.
The default behavior on Cisco routers is that the AS_SET is not used, hence the atomic aggregate must be set in the aggregated route. You must use the as-set argument of the aggregate-address command in order for the router to attach the Path information to the aggregated route by generating an AS_SET segment in the AS_PATH attribute.
JUNOS does the opposite by default, Juniper is attaching all the AS Path information to the aggregated path; this means that the ATOMIC_AGGREGATE attribute is not set by default.

The AS-SET segment is used to prevent BGP routing loops as I mentioned before and I believe it should always be used, unless you have a very specific case to omit it (I’ve only done this in a CCIE study LAB scenario).
The Atomic Aggregate attribute will also be set even when using AS_SET  if one of the aggregated route is an aggregate itself and has its atomic aggregate attribute already set.
And please have a look at Understanding BGP Route Aggregation at Cisco.com

 

BGP Attribute Types and Flags Continues

BGP Attributes: Local Preference Attribute

The local preference attribute is a well-know discretionary attribute. This means local preference must be recognized by all BGP implementations, but will not exist in all BGP update messages; specifically it will not exist in E-BGP update messages.
BGP local preference attribute is one of the most used attributes in BGP real world to influence traffic. Local preference attribute is a four octet field of information that is used to inform internal peers about the autonomous system internal preference for an advertised route.
Local preference will exist in all internal BGP update messages and will never be included in external update messages as I mentioned before, except in the case of BGP confederations.
Local Preference attribute is used to influence traffic in the upload direction; each external route is assigned a preference value based on a configured policy that attaches this preference value to the LOCAL_PREF attribute in the update messages upon sending to internal peers. Local Preference is typically manipulated at the provider edge before sending the route to other internal peers.
When a BGP speaker receives the same route more than once it examines the local preference of the routes and the highest one wins and is considered the best route.
The default value for the LOCAL_PREF attribute is 100 on both Cisco and Juniper routers. This value is changed on IOS routers using a route-map and RPL on IOS-XR while on Juniper routers a policy is used to change the value.
The illustration below makes it more clear, lets check it:

As you can notice in the illustration above , Prefix 192.168.1.0/24 is advertised to AS XYZ from two different upstream providers R1 and R2. The Local Preference attribute value is set using a policy on AS:XYZ edge routers Rx and Ry. Rx sets the value to 200 and Ry sets the value to 150 and both advertise the route to Rz as an iBGP update.
Now, Rz has two routes to the same destination one from Rx and another from Ry but the route through Rx has a higher local preference of 200 and is selected as a best route and moved to the forwarding table.
The very good thing about Local Preference is that it comes first in the best route selection algorithm for BGP providing a clean and easy way to control upload traffic exiting your autonomous system to the internet.

 

BGP Attribute Types and Flags

BGP attributes is an interesting subject of study.  BGP is a very flexible and extensible protocol and I like that, let’s see how flexible is that protocol when it comes to attributes handling. We all know that BGP has four types of attributes as listed:

• Well-known mandatory.
• Well-known discretionary.
• Optional transitive.
• Optional non-transitive.

I am not going to explain them in this post, they are explained everywhere over the internet. However, in short well-known attributes must be recognized by all BGP implementations, some of them are mandatory and must be included in all update messages, others are discretionary and may or may not exist in all BGP updates . Optional attributes do not have to be understood by all BGP implementations. Optional attributes are transited to peers or not,  based on the setting of the transitive bit as we will show below.
I will focus on how BGP signals and handles these attributes in update messages. BGP path attributes are sent in BGP update messages; every attribute is a triple of variable length [attribute type, attribute length, attribute value ].
Attribute type is a two octet piece of information that consists of  an Attribute Flag octet and an Attribute Type code octet. The Attribute type code speaks for itself and it carries the attribute code number for a specific attribute, for example the origin attribute has a type code number of 1 (see the example below).
And because a picture is worth a thousand words, I will start by a wireshark capture and comment on below.

The Attribute Flag:

The first high order bit (from the left) is the optional bit, setting this bit to 1 means the attribute is optional and to 0 defines a well-known attribute. Origin is a well-known mandatory attribute so this bit is set to zero as you can see.
The second high order bit is the transitive bit. It defines whether the attribute is transitive (value=1) or non-transitive (value=0). Well-known attributes are always transitive and therefore their transitive bit is always set to one.
The third bit is the partial bit, it defines whether the information in the optional transitive attribute is partial (value= 1) or complete (value = 0). Well-known and optional non-transitive are always set to complete. The partial bit is set to 1 in the following cases:

1. Unrecognized optional transitive attribute that is passed to peers, the sender sets the partial bit.
2. Optional transitive attribute attached by some router other than the originator or the route.

The fourth bit is the extended length bit and it defines whether the attribute length is one octet or more. The last four bits are not currently used.
The sender orders path attributes in an ascending order (according to attribute type code) within the update message as shown in the packet capture above.

PPP Over Frame-Relay

Uses a virtual-template interface interface virtual-template 1 which contains your IP address configuration and other L3 stuff like perhaps PPP authentication
- Physical interface links your virtual-template to the interface with frame-relay interface-dlci <dlci> ppp virtual-template 1
- Remember when doing show ip interface brief or other commands, the virtual-template interface will actually show as down. This is normal.
Well those are pretty much my notes for Frame-Relay. This is getting pretty boring and long, so I won’t even go into my notes on the frame configuration right now. One thing I like about writing this stuff out, is that it really actually helps refresh my memory. Hey even if I am boring, I am at least getting something out of it. Consider this as sort of my personal journal, but viewable to the world. It’s really for my benefit as much as anything else.
When I started the configuration video, I got inspired to lab it up for real in my basement. The first part of the video deals with a pretty straight forward Hub and spoke frame network with 1 Hub and 2 spokes. Easy enough…I used a 2520 for my frame switch, a 2511 for an AS, a 2514 for my hub, and a 2501/2502 for my spokes. Unfortunately, I only have 8MB RAM and Flash in most of them, so the best IOS I can still find for download is like 12.1.27 but oh well. It seemed to work pretty well for the purpose. Then Scott added a 4th router for much of the rest of the video and I was screwed because I ran out of DTE/DCE crossover cables. I ordered some more today. I still should really go over actually DOING the back to back exercises as well as the ones involving back to back with frame-relay multilink. Then, when I get add a 3rd spoke going through the other stuff.
Well I hope this is useful for somebody out there 

IOS Access List numbering scheme

The simple CLI parser implemented in early releases of Cisco IOS recognized only numbered access lists. The protocols supported early in the Cisco IOS history were thus using numbered access lists to filter traffic or routing updates.
Most of the access lists were using common address space. Banyan Vines access lists were an exception, they were always configured with the vines access-list configuration command and used their own independent numbering scheme. Rate-limit access-lists (configured with access-list rate-limit number) also use an independent address space.
The first protocol using named access lists was CLNS. Named standard and extended access lists were later added to IP. As numerous IP features still expected an access-list number in the configuration commands even after the named IP access lists were introduced, the address space of the numbered IP access lists was expanded.
The following table documents the IOS access-list numbering conventions:

Start	End	Description
1	99	IP standard access lists
100	199	IP extended access lists
200	299	Protocol type-code access lists (used in bridging filters)
300	399	DECnet standard access lists
400	499	XNS standard access lists
500	599	XNS extended access lists
600	699	AppleTalk cable range access lists
700	799	MAC address access lists (used in bridging filters)
800	899	Novell IPX standard access lists
900	999	Novell IPX extended access lists
1000	1099	Novell IPX SAP access lists
1100	1199	MAC address access lists (extended range)
1200	1299	Novell IPX NLSP access lists
1300	1999	IP standard access lists (extended range)
2000	2699	IP extended access lists (extended range)

Rate limit access lists configured with the access-list rate-limit global configuration command and used in the rate-limit input|output access-group rate-limit number rate interface configuration command use the following numbers (independent from the access-list numbering scheme):

Start	End	Description
1	99	Precedence ACL
100	199	MAC address ACL
200	299	MPLS EXP bits ACL

Banyan Vines access lists configured with the vines access-list number global configuration commands used the following numbering scheme:

Start	End	Description
1	100	Standard ACL
101	200	Extended ACL
201	300	Simple ACL