According to Cisco VRF considered to be “lite” without using MPLS. Which means that creating interfaces, and running routing protocols without the use of MPLS will make it VRF-lite.

To configure VRF-lite, follow the steps:

1. Define the VRF instance by using ip vrf name
2. Give the appropriate rd values rd nn:nn
3. If using BGP, then add route-targets {export/import} nn:nn
4. Add the Interface to the VRF by using the command ip vrf forwarding name

ip vrf VPN_A

rd 100:1

!

ip vrf VPN_B

rd 100:2

!

interface FastEthernet0/0.67

encapsulation dot1Q 67

ip vrf forwarding VPN_A

ip address 155.1.67.6 255.255.255.0

!

interface FastEthernet0/0.76

encapsulation dot1Q 76

ip vrf forwarding VPN_B

ip address 155.1.76.6 255.255.255.0

!

ip route vrf VPN_A 172.16.7.0 255.255.255.0 155.1.67.7

ip route vrf VPN_B 192.168.7.0 255.255.255.0 155.1.76.7

!

ip vrf VPN_A

rd 100:1

!

ip vrf VPN_B

rd 100:2

!

!

interface Loopback101

ip vrf forwarding VPN_A

ip address 172.16.7.7 255.255.255.0

!

interface Loopback102

ip vrf forwarding VPN_B

ip address 192.168.7.7 255.255.255.0

!

!

interface Vlan67

ip vrf forwarding VPN_A

ip address 155.1.67.7 255.255.255.0

!

interface Vlan76

ip vrf forwarding VPN_B

ip address 155.1.76.7 255.255.255.0

!

ip route vrf VPN_A 0.0.0.0 0.0.0.0 155.1.67.6

ip route vrf VPN_B 0.0.0.0 0.0.0.0 155.1.76.6

Cisco Catalyst 3550

I find the configuration of 3550 rather easier. First, you would enable QoS. second, when classifying traffic (you of course will use MQC) in the class map you match vlan id. Then you just police that traffic however you want it. Lets see a configuration for that.

mls qos
!
class-map HTTP_VLAN_10
match vlan 10
match protocol http
!
policy-map HIGH_BANDWIDTH
class HTTP_VLAN_10
set dscp af11
policy 12800 1600 exceed-action drop
!
interface fastethernet 0/1
service-policy input HIGH_BANDWIDTH

That is straight forward, and should be done easily without much confusion since that approach is what used in most routers.

Cisco Catalyst 3560

Here where we have rather different way of doing the same task. First, enable mls qos. Second, Match the interesting traffic. Third, enable mls qos on the interface. Fourth, mark the traffic in the First policy. Fifth, Police the rate at the nested policy. lastly, Apply it at the vlan interface.

mls qos
!
interface fa0/2
mls qos vlan-based
!
class-map INT
match input-interface fa0/2
!
policy-map NESTED_POLICE
class INT
policy 12800 1600 exceed-action drop
!
class-map HTTP
match protocol http
!
policy-map PARENT_MARK
class HTTP
set dscp af11
service-policy NESTED_POLICE
!
interface vlan 10
service-policy PARENT_MARK

Please note that you can’t MARK and POLICE the traffic in the same policy. So creating parent policy for marking and nested policy for rate police. We have to enable the interfaces that we want to participate in policing the vlan traffic since a direct match can’t be made. lastly, the service-policy will be applied into the Vlan interface and not the physical interface.

MQC Frame-Relay Traffic shaping

In here, we see the efforts put into introducing the MQC style for traffic shaping. but with this method, you nest the MQC into a map-class. Yes, it doesn’t look pretty, and seems slightly confusing. But let’s have an example, and this will ease our understanding of the topic.

policy-map CBWFQ
class VOICE
priority 64
class class-default
fair-queue
!
policy-map SHAPE
class class-default
shape average 256000 2560 0
shape adaptive 128000
service-policy CBWFQ
!
map-class frame-relay TEST_DLCI
service-policy output SHAPE
!
interface Serial 0/0.1
frame-relay interface-dlci 101
class TEST_DLCI

This example lengthy as it seems, but it is still straight forward. we have defined shaping in MCQ style, then impliemented that into map-class. lastly, this map-class was configured inside the interface-dlci.

Class Based Generic Traffic Shaping

This is the last method out of the four methods that can be used for FRTS. It is similar to the legacy GTS. In this, you have the advantage to match the class based of frame-relay dlci. Lets see an example and that should show us the details.

class-map DLCI
match fr-dlci 123
!
policy-map SHAPE_123
class DLCI
shape average 256000
!
interface s0/1
service-policy output SHAPE_123

One of the main issues of this method is that adaptive shaping can’t be used, nor voice-adaptive fragmentation.

all of the four methods have their advantage and disadvantage to them. from the simplest, to more complicated ones. The situations/requirment will be the deciding factor on which method use for FRTS.

To minimize flapping routes, two separate features can be used. First is the route summary. Second is the route dampening.

Route dampening is to suppress a prefix based on the number of flaps. each flap will have a penalty value (cost). once the route flaps, the route will be added to “history” where it will be tracked. If the suppress limited reached BGP will will suppress the route and mark it as damped. Then every 5 seconds the penalty value will be decreased by exponentially. The decrease value depends on one single parameter which is half-life. half-life = the amount of time required to make the penalty value half of the current state. The penalty for flapped route is 1000 per flap, while penalty for attribute change is 500.

The equation for the decay is

P(t) = P(0) / 2^(t/half-life); Where p(t) = reuse limit, P(0) = suppress limit.

the command syntax to apply this in BGP is

router bgp xxxxx
bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]

The default values are half-life = 15 mins, reuse = 750, suppress = 2000, max-suppress-time=60 mins.

The route map can be used to set these values as well. The mentioned equation is important to calculate the half-time values, cause they determine how fast a flapping route can be released from the damped stated.

For that, we have the attribute map a route-map that can be used to set any variable we want to the aggregation. here is the syntax

aggregate-address x.x.x.x x.x.x.x summary-only attribute-map ATTRIB

route-map ATTRIB
set community 200:200
set weight 200

it is very simple and effective. hope this post was informative.

The command for distributing a default route into RIP process is very straight forward.  Lets go with the syntax straight away.

router rip
default-information originate route-map RELIABLE
!
route-map RELIABLE permit 10
match ip address prefix-list DUMMY_TRACKED
set interface Serial 1/0
!
ip prefix-list DUMMY_TRACKED seq 5 permit 10.10.10.10/32
!
ip route 10.10.10.10 255.255.255.255 null0 track 1

Here we have added a route map to the default-information command. This route map will match an ip address. This IP address is the Route. That means, IF that route (10.10.10.10) is in the routing table, then distribute the default route. This can be used with real routes, or as in our case with dummy route. Second is command “set” is telling the router on which interface advertise the default route.

So we have created a dummy route, and tracking it with IP SLA. The interesting twist here, is that the SLA is for real interface.

ip sla 1
icmp-echo 200.1.2.3. source-interface s1/1
frequency 1
timeout 50
!
ip sla schedual 1 start now life forever
!
track 1 ip sla 1

So, if the real route goes down, the dummy route will be out. Once that happened, the default-information command will cease to work.

Although rip is not the best routing protocols, the mechanism of filtering routes can be applied to other routing protocols a well. My personal advice will be to stay away as much as possible from RIP. RIP is a routing loop magnet, you never know when you created a loop by yourself.

In this entry, I would like to mention two methods that i found interesting, cause it will be helpful even in later as we go on. Lets read the syntax below

Router rip
distribute-list 100 in serial 1/0
!
access-list 100 deny ip host 10.254.0.10 host 192.168.1.0
access-list 100 permit ip any any

in the rip process i have included a distribute-list. This list has to statements. The second one to permit all route updates to be installed in the routing table that are coming from Interface Serial 1/0. The first access list deny route to network 192.168.1.0 which is advertised by 10.254.0.10

Keep in mind that distribute-list can be used with BGP and it has different meaning! so lets summarize this

access list 100 deny ip host x.x.x.x (router) host y.y.y.y (Network) ————- IN IGB
access list 100 deny ip host x.x.x.x (network) host y.y.y.y (mask) ————– IN BGP

First, we need to create access-list, lets make the access

access-list 101 dynamic Mydyn permit ip any any

access-list 101 permit ip host x.x.x.x host x.x.x.x eq telnet

After that, we need to configure the vty lines to accept

line vty 0

login local

autocommand  access-enable host

lets not forget to configure the username and password.

username xxxx password xxxxx

lasty, apply the access list into the physical interface.

Interface f0/1

ip access-group 101

with that, the dynamic access list is created. As long as the session is open. when the session times out. the ACL entry will be deleted and a new authentication would be required access the protected networks by the router.

While i was configuring the BGP VPN section i got the following error.

R6(config-router)# neighbor 150.1.4.4 remote-as 100

R6(config-router)# neighbor 150.1.4.4 update-source Loopback0

R6(config-router)# address-family vpnv4

R6(config-router-af)#  neighbor 150.1.4.4 activate

R6(config-router-af)#  neighbor 150.1.4.4 send-community extended

R6(config-router-af)# exit-address-family

*Mar  1 02:08:59.455: %BGP-5-ADJCHANGE: neighbor 150.1.4.4 Up

*Mar  1 02:08:59.463: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.6.6 may not be reachable from neigbor 150.1.4.4 – not /32 mask

Then, i did not mind the error (highlighted in bold) and carried on with configurations. At the end, i had a full working network with proper routing updates in the MPLS-VPN plan. But no traffic is going. I had to troubleshoot many things. Till the end, i decided to re-configure the routers all over. Then i noticed the error. decided to fix it. Changed the loopback address from /24 to /32. The moment i did that, the traffic started passing.

What i learned, is that “Don’t ignore any messages the IOS gives you while configuring”

This is one of the nice features that i just discovered yesterday. It is the ability to make sure an end-to-end frame-relay connectivity between Cisco routers.

In the local router, we can see the PVC status.

Rack1R3#show frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         3            0            0            0

Rack1R3#conf t

Rack1R3(config)#map-class frame-relay END-END

Rack1R3(config-map-class)#frame-relay end-to-end keepalive mode bidirectional

Rack1R3(config-map-class)#exit

Rack1R3(config)#int serial 1/0.1

Rack1R3(config-subint)#frame-relay class END-END

Rack1R3(config-subint)#end

Rack1R3#

Rack1R3#show frame-relay end-to-end keepalive

End-to-end Keepalive Statistics for Interface Serial1/0 (Frame Relay DTE)

DLCI = 305, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK UP)

SEND SIDE STATISTICS

Send Sequence Number: 34,       Receive Sequence Number: 35

Configured Event Window: 3,     Configured Error Threshold: 2

Total Observed Events: 37,      Total Observed Errors: 0

Monitored Events: 3,            Monitored Errors: 0

Successive Successes: 3,        End-to-end VC Status: UP

RECEIVE SIDE STATISTICS

Send Sequence Number: 34,       Receive Sequence Number: 33

Configured Event Window: 3,     Configured Error Threshold: 2

Total Observed Events: 36,      Total Observed Errors: 0

Monitored Events: 3,            Monitored Errors: 0

Successive Successes: 3,        End-to-end VC Status: UP