router ric

Optimised Edge Routing / Performance Routing

2012-02-01T12:32:00.000-08:00

Here is a simple OER/PFR configuration example. R1 is the master controller with R4 and R5 the border routers.

Border router 1

key chain OER

key 1

key-string CISCO

oer border

local Loopback0
master 1.1.1.1key-chain OER

Border router 2

key chain OER

key 1

key-string CISCO

oer border

local Loopback0
master 1.1.1.1key-chain OER

Master router

oer master

border 4.4.4.4key-chain OER

interfaceFastEthernet0/1 external
interfaceFastEthernet0/0 internal

border 5.5.5.5key-chain OER

interfaceFastEthernet0/1 external
interfaceFastEthernet0/0 internal

Verification Commands

R1#s oer master border
Border          Status   UP/DOWN             AuthFail Version
5.5.5.5         ACTIVE   UP       00:13:00          0 2.1
4.4.4.4         ACTIVE   UP       00:13:32          0 2.1

R1#show oer border
OER BR 5.5.5.5 ACTIVE, MC 1.1.1.1 UP/DOWN: UP 00:22:18,
Auth Failures: 0
Conn Status:SUCCESS, PORT: 3949
Version: 2.1 MC Version: 2.1
Fa0/0 INTERNAL
Fa0/1 EXTERNAL

Deleting BGP Communities

2011-10-02T12:38:00.000-07:00

BGP communities are passed between bgp peers when the 'send community' attribute is set with the neighbor. However what if there is a requirement to delete one of the communities from a list associated with a route!?

Consider the topology below. The route 1.1.1.0/24 is advertised by R1 to R2 and the route has community attributes 'no-advertise' and 'internet'. R2 has an iBGP peering with R3 and the send-community attribute is set. Initially by default R3 does not receive the route as a direct result of the no-advertise community. The requirement is for R3 to have the BGP route 1.1.1.0/24 with only the internet attribute.

The solution relies on the 'set comm-list' command. This enables communities matched by the community-list to be removed. Below i attach the working config from R2.

R2

ip community-list standard RIC permit no-advertise

route-map RIC permit 10
set comm-list RIC delete

router bgp 1
neighbor 192.168.12.1 remote-as 2
neighbor 192.168.12.1 route-map RIC in

OSPF Distance command

2011-09-27T13:23:00.000-07:00

The OSPF distance command can be used in a number of different ways. I found the first one is well documented on the doc cd in the ospf routing section. However the next three are strangely absent therein. There is some info under the general distance command but this does not detail its use in OSPF.

I) distance ospf {external/inter-area/intra-area} AD

II) distance AD - this sets the distance for all routes

III) distance AD {ip-address wild-card-mask} - this sets the distance for all routes learned from a specific source-router. The source router is the RID of the link-state router that origininated the route!!!

IV) distance AD (ip-address wild-card0mask} ACL identical to the previous command but it is applied to only a subset of routes that match the ACL.

IPV6 Multicast

2011-09-08T22:51:00.000-07:00

IPv6 multicast rears its head on V4 of the CCIE blueprint. If you know the basics of IPv4 multicast then the basics of IPv6 multicast should be pretty straightforward. In fact with IPv6 its not even necessary to define interfaces as multicast capable! Once ipv6 multicast routing is enabled on the router the interfaces become multicast enabled as well.

Here is a config example between just 2 routers connected via an ethernet interface: R1---R2. The basic steps are
i) enable ipv6 multicast routing
ii) define the rp
iii) join an interface with a multicast group

Ipv6 multicast-routing

ipv6 pim rp-address 2002::2

Ipv6 multicast-routing

Int lo0

ipv6 mld join-group FF04::2

ipv6 pim rp-address 2002::2

With the above configuration an IPV6 PIM neighbourship forms between R1 and R2

The show ipv6 pim group-map command can be used to see a that a multicast address is associated with the RP.

Finally i test the multicast group with a ping

BGP adjacency problem

2011-09-04T11:10:00.000-07:00

In this post i detail a recent problem encountered with a flapping BGP adjacency and a number of ways to resolve.

R1 has a BGP adjacency with R2. However this is continually flapping (see below).

The routers are peering using Loopback 0s that are reachable via OSPF. The issue arises because as the BGP peering comes up the Loopback prefixes are advertised over the BGP adjacency. OSPF AD is 110 whereas the eBGP route AD is 20. Hence the Loopback routes becomes preferred over the BGP adjacency. This is a type of recursive loop and not allowed (Just as learning the destination of the tunnel over the tunnel itself). The adjacency is dropped and the whole process starts again.

I have detailed three solutions to the problem here

1) Block the Loopback prefixes from being received

On R2

ip prefix-list ric seq 5 deny 1.1.1.1/32
ip prefix-list ric seq 10 permit 0.0.0.0/0 le 32

router bgp 2
neighbor 1.1.1.1 prefix-list ric in

2) Modify the distance of OSPF to be preferred over an eBGP route

router ospf 1
distance ospf intra-area 19

3) Make use of the BGP backdoor command to raise the AD of the BGP route to 200.

router bgp 1
net 2.2.2.2 mask 255.255.255.255 backdoor

Once the command is used the route to 2.2.2.2 shows up in the BGP table as a RIB failure. Use of the show ip bgp rib command completes the verification.

PPPOE

2011-08-29T23:17:00.000-07:00

Point To Point Protocol Over Ethernet. Enables use of PPP over an ethernet connection. Here i lay out a working solution between client and server.

The many configuration options are under the 'Cisco IOS Broadband Access Aggregation and DSL Configuration Guide' under the Configuration Guide section of the Cisco Doc.
http://www.cisco.com/en/US/products/ps6441/products_installation_and_configuration_guides_list.html

In this example i have R2 and R3 connected via an ethernet connection. R2 is the client and R3 is the server.

username R3 password 0 RICH

interface Ethernet0/1

ip address 2.2.2.2 255.255.255.248

half-duplex

pppoe enable group global

pppoe-client dial-pool-number 1

interface Dialer1

mtu 1492

ip address 10.10.10.2 255.255.255.0

encapsulation ppp

dialer pool 1

dialer idle-timeout 0

dialer persistent

ppp authentication chap

username R2 password 0 RICH

bba-group pppoe global

virtual-template 1

interface Ethernet0/0

ip address 2.2.2.3 255.255.255.248

half-duplex

pppoe enable group global

interface Virtual-Template1

ip address 10.10.10.3 255.255.255.0

ppp authentication chap

Netflow

2011-08-24T07:10:00.000-07:00

Netflow is a Cisco developed network protocol that has become an industry standard for monitoring traffic (RFC 3954). Once configured, on a per interface basis, the router builds a NetFlow record for each unique traffic stream. Amongst other details the record includes the number of bytes and packets. The record is output once the flow has finished or at preconfigured time interval via a UDP or STCP flow.

CEF is a prerequisite for Netflow to work. To configure on an interface

Config-if#ip flow {ingress|egress}

Verification

Show ip flow interface
Show ip cache flow

To configure data export

Ip flow-export destination {ip address} {udp port}

Verification

Show ip flow export

OER

2011-08-23T02:59:00.000-07:00

OER or Optimised Edge Routing. Also known as PFR or Performance Routing is now part of the v4 blueprint. In summary it is a feature that enables selection of a route based on its dynamic performance metrics. Something lacking with traditional routing protocols that assign a metric to a route. This assigned metric is in effect the static expected performance of the route that can be used when comparing with any route alternates.

OER is a step towards route selection based on true dynamic performance e.g. in terms of real round trip times of packets. There’s quite a bit of configuring required. CISCO lays out five phases

• Profiling
• Measuring
• Policy Application
• Control
• Verification

The components of OER include a Master Controller (MC) and the Border Routers (BR). The BR’s send performance statistics to the MC. The MC sends routing policy decisions to the BR’s. It’s the BRs that sit on the edge of the network and implement the policies to control the traffic leaving on the external links.

Here i lay out the basic config between MC and Borders. Authentication via a key chain between MC and BR is not optional.

Master Configuration

R1
key chain RIC
key 1
key-string ROUTERRIC

oer master
keepalive 10
logging
!
border 2.2.2.2 key-chain RIC
interface Serial1/0 external
interface Ethernet0/0 internal
!
border 3.3.3.3 key-chain RIC
interface Serial1/0 external
interface Ethernet0/0 internal

Border Config on R2 and R3

key chain RIC
key 1
key-string ROUTERRIC
!
oer border
local Loopback0
master 1.1.1.1 key-chain RIC

Verification On R1

R1#show oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Number of Border routers: 2
Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0

Border Status UP/DOWN AuthFail
3.3.3.3 ACTIVE UP 00:01:57 0
2.2.2.2 ACTIVE UP 00:02:14 0

Verification on R2 and R3
R2#show oer border
OER BR 2.2.2.2 ACTIVE, MC 1.1.1.1 UP/DOWN: UP 00:45:16,
Auth Failures: 0
Conn Status: SUCCESS, PORT: 3949
Exits
Et0/0 INTERNAL
Se1/0 EXTERNAL

EIGRP V6

2011-08-22T03:24:00.000-07:00

New in V4 CCIE R and S. EIGRP V6 is found in the configuration guide under the IPV6 EIGRP section and not under EIGRP.

Below is a sample config

ipv6 unicast-routing
ipv6 router eigrp 1
no shut

int e0/0
ipv6 enable
ipv6 eigrp 1

Of note is the fact that the EIGRPV6 router process is shutdown until it is manually enabled with ‘no shut’.
R4(config-rtr)#do show ipv6 eigrp ne
IPv6-EIGRP neighbors for process 1
% EIGRP 1 is in SHUTDOWN

Once the ipv6 router eigrp process is started then the neighbour relationship comes up!

R4(config-rtr)#ipv6 router eigrp 1
R4(config-rtr)#no shut
*Mar 1 00:05:32.727: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 1: Neighbor FE80::C003:13FF:FE7C:0 (FastEthernet0/0) is up: new adjacency

R4#s ipv6 eigrp ne
IPv6-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num
0 Link-local address: Fa0/0 013 00:01:38 1980 5000 0 1
FE80::C003:13FF:FE7C:0

Reviewing the V4 Blueprint

2011-08-22T02:20:00.000-07:00

I have listed the CCIE Lab v4 R and S blueprint below. The following topics look like additions over and above the V3 lab content. So far I have reviewed and blogged on RITE and MPLS, so hope to cover the other topics over the coming weeks and months.

New V4 topics
PPPoE
OER (Optimised Edge Routing)
MPLS
EIGRP v6
Ipv6 Multicast
AUTOQOS
NETFLOW
RITE (Router IP Traffic-Export)
EEM (Embedded Event Manager)
Zone Based Firewall
IPS (intrusion Prevention System)

Complete V4 blueprint
1.10 Implement Spanning Tree Protocol (STP)
(a) 802.1d
(b) 802.1w
(c) 801.1s
(d) Loop guard
(e) Root guard
(f) Bridge protocol data unit (BPDU) guard
(g) Storm control
(h) Unicast flooding
(i) Port roles, failure propagation, and loop guard operation
1.20 Implement VLAN and VLAN Trunking Protocol (VTP)
1.30 Implement trunk and trunk protocols, EtherChannel, and load-balance
1.40 Implement Ethernet technologies
(a) Speed and duplex
(b) Ethernet, Fast Ethernet, and Gigabit Ethernet
(c) PPP over Ethernet (PPPoE)
1.50 Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control
1.60 Implement Frame Relay
(a) Local Management Interface (LMI)
(b) Traffic shaping
(c) Full mesh
(d) Hub and spoke
(e) Discard eligible (DE)
1.70 Implement High-Level Data Link Control (HDLC) and PPP

2.00 Implement IPv4
2.10 Implement IP version 4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM)
2.20 Implement IPv4 tunneling and Generic Routing Encapsulation (GRE)
2.30 Implement IPv4 RIP version 2 (RIPv2)
2.40 Implement IPv4 Open Shortest Path First (OSPF)
(a) Standard OSPF areas
(b) Stub area
(c) Totally stubby area
(d) Not-so-stubby-area (NSSA)
(e) Totally NSSA
(f) Link-state advertisement (LSA) types
(g) Adjacency on a point-to-point and on a multi-access network
(h) OSPF graceful restart
2.50 Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP)
(a) Best path
(b) Loop-free paths
(c) EIGRP operations when alternate loop-free paths are available, and when they are not available
(d) EIGRP queries
(e) Manual summarization and autosummarization
(f) EIGRP stubs
2.60 Implement IPv4 Border Gateway Protocol (BGP)
(a) Next hop
(b) Peering
(c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP)
2.70 Implement policy routing
2.80 Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER)
2.90 Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features

3.00 Implement IPv6
3.10 Implement IP version 6 (IPv6) addressing and different addressing types
3.20 Implement IPv6 neighbor discovery
3.30 Implement basic IPv6 functionality protocols
3.40 Implement tunneling techniques
3.50 Implement OSPF version 3 (OSPFv3)
3.60 Implement EIGRP version 6 (EIGRPv6)
3.70 Implement filtering and route redistribution

4.00 Implement MPLS Layer 3 VPNs
4.10 Implement Multiprotocol Label Switching (MPLS)
4.20 Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers
4.30 Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite)

5.00 Implement IP Multicast
5.10 Implement Protocol Independent Multicast (PIM) sparse mode
5.20 Implement Multicast Source Discovery Protocol (MSDP)
5.30 Implement interdomain multicast routing
5.40 Implement PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and bootstrap router (BSR)
5.50 Implement multicast tools, features, and source-specific multicast
5.60 Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast Listener Discovery (MLD)

6.00 Implement Network Security
6.01 Implement access lists
6.02 Implement Zone Based Firewall
6.03 Implement Unicast Reverse Path Forwarding (uRPF)
6.04 Implement IP Source Guard
6.05 Implement authentication, authorization, and accounting (AAA) (configuring the AAA server is not required, only the client-side (IOS) is configured)
6.06 Implement Control Plane Policing (CoPP)
6.07 Implement Cisco IOS Firewall
6.08 Implement Cisco IOS Intrusion Prevention System (IPS)
6.09 Implement Secure Shell (SSH)
6.10 Implement 802.1x
6.11 Implement NAT
6.12 Implement routing protocol authentication
6.13 Implement device access control
6.14 Implement security features

7.00 Implement Network Services
7.10 Implement Hot Standby Router Protocol (HSRP)
7.20 Implement Gateway Load Balancing Protocol (GLBP)
7.30 Implement Virtual Router Redundancy Protocol (VRRP)
7.40 Implement Network Time Protocol (NTP)
7.50 Implement DHCP
7.60 Implement Web Cache Communication Protocol (WCCP)

8.00 Implement Quality of Service (QoS)
8.10 Implement Modular QoS CLI (MQC)
(a) Network-Based Application Recognition (NBAR)
(b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ)
(c) Classification
(d) Policing
(e) Shaping
(f) Marking
(g) Weighted random early detection (WRED) and random early detection (RED)
(h) Compression
8.20 Implement Layer 2 QoS: weighted round robin (WRR), shaped round robin (SRR), and policies
8.30 Implement link fragmentation and interleaving (LFI) for Frame Relay
8.40 Implement generic traffic shaping
8.50 Implement Resource Reservation Protocol (RSVP)
8.60 Implement Cisco AutoQoS

9.00 Troubleshoot a Network
9.10 Troubleshoot complex Layer 2 network issues
9.20 Troubleshoot complex Layer 3 network issues
9.30 Troubleshoot a network in response to application problems
9.40 Troubleshoot network services
9.50 Troubleshoot network security

10.00 Optimize the Network
10.01 Implement syslog and local logging
10.02 Implement IP Service Level Agreement SLA
10.03 Implement NetFlow
10.04 Implement SPAN, RSPAN, and router IP traffic export (RITE)
10.05 Implement Simple Network Management Protocol (SNMP)
10.06 Implement Cisco IOS Embedded Event Manager (EEM)
10.07 Implement Remote Monitoring (RMON)
10.08 Implement FTP
10.09 Implement TFTP
10.10 Implement TFTP server on router
10.11 Implement Secure Copy Protocol (SCP)
10.12 Implement HTTP and HTTPS
10.13 Implement Telnet

Router Sniffer Capture

2011-08-20T11:11:00.000-07:00

Ever wondered if you can run a sniffer from a router? I have only ever used monitor sessions on switches so Router IP Traffic Export or RITE was an interesting discovery for me. This can be used to achieve the same as a monitor session on a switch. Also this is on the V4 blueprint so a useful command to have come across. Its not that difficult either!

There are just two configuration steps. Define the outgoing sniffer port along with the mac address of the device attached and then define the capture traffic flows on the ingress port.

Heres an example
interface Ethernet0/1
ip traffic-export profile RICH
mac-address 1111.2222.3333

interface Ethernet0/0
ip traffic-export apply RICH

R1#show ip traffic-exp
Router IP Traffic Export Parameters
Monitored Interface Ethernet0/0
Export Interface Ethernet0/1
Destination MAC address 1111.2222.3333
bi-directional traffic export is off
Input IP Traffic Export Information Packets/Bytes Exported 0/0
Packets Dropped 0
Sampling Rate one-in-every 1 packets
No Access List configured
Profile RICH is Active

There are a number of extra options i'venot detailed here. The above shows the basic configuration that’s needed to get the feature operational.

SHAM LINKS

2011-08-20T00:07:00.000-07:00

A customer has 2 entry points into an MPLS VPN. It is a requirement for the customer to traverse the MPLS VPN for intersite traffic. When the customer is running OSPF between its sites by default the backdoor, slower, serial connection will always be preferred by OSPF. This is because links injected into the OSPF domain by the PE routers will be external routes and hence always less preferred than OSPF internal routes.

Sham links get around this problem. Effectively they are a vehicle to enable the OSPF links traversing the provider backbone to appear as internal OSPF routes.

Sham links appear analogous to virtual links. They have tunnel start and end points and traverse a routing domain. The following are required

1) A /32 loopback address on each PE router. This has to be in the customer VRF and NOT be directly advertised into OSPF.

2) Advertise these loopbacks into MP-BGP as vpnv4 routes. This is how the PE routers will learn about the endpoints of the sham-link.

3) Configure the sham-link under the OSPF process on the PE routers

1)
PE1
Int lo0
Ip vrf forwarding CUST1
Ip address 192.168.0.1

PE2
Int lo0
Ip vrf forwarding CUST1
Ip address 192.168.0.2

2)
PE1
Router bgp 1
Address-family ipv4 vrf CUST1
Network 192.168.0.1 255.255.255.255

PE2
Router bgp 1
Address-family ipv4 vrf CUST1
Network 192.168.0.1 255.255.255.255

3)
PE1
Router ospf 1 vrf CUST1
Area 0 sham-link 192.168.0.1 192.168.0.2

PE1
Router ospf 1 vrf CUST1
Area 0 sham-link 192.168.0.2 192.168.0.1

Using the PING TOS field

2010-05-14T21:50:00.000-07:00

The extended ping command can be useful when testing MQC policies. The IP header TOS value of packets can be explicitly set, and hence MQC configuration can subsequently be tested.

The extended ping command expects the TOS value to be set using a decimal value (see below).

R1#ping
Protocol [ip]:
Target IP address: 10.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 184
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/68 ms

If you only know or are given the DSCP marking the question then arises 'How to i derive the TOS value from the DSCP marking?

This can easily be calculated when remembering the DSCP marking denotes the decimal value of the first 6 bits of the IP TOS header field. The last 2 bits of the TOS field are not used, so will always be zero.

As an example DSCP 46 equates to 101110 binary. To convert to a TOS value simply append the last two zero bits and convert back to decimal. Therefore 101110 becomes10111000 and when converted back to decimal this becomes 184. This is the decimal TOS representation of DSCP 46.

BGP transit AS's and how to avoid

2010-03-18T12:10:00.000-07:00

How can you prevent your own BGP AS becoming a transit path? This can be achieved by making use of a distribute-list or a prefix-list. However these methods do not scale well as future ip addressing changes or additions require access lists to be revisited.

BB1 ------ R1 (AS 101) ------- R2 (AS 101) ------- BB2

Here are 2 options that scale and do not require revisiting when ip addresses change.

OPTION 1 - Make use of the no-export community.
-------------------------------------------------------------

Here i apply the community no-export to ALL incoming bgp routes.

R1
route-map NOEXPORT
set community no-export

router bgp 101
neigh {ip addr BB1} route-map NOEXPORT in
neigh {ip addr r2} send-community

OPTION 2 – Make use of the filter-list command
-----------------------------------------------------------

Here i create an as-path access list and only allow bgp routes originated in the routers own as (AS 101) to be advertised out.

R2
ip as-path access-list 1 permit ^$

router bgp 101
neigh {ip addrBB2} filter-list 1 out

With both commands i use show ip bgp {ip address} advertise for verification of advertised routes.

MPLS - BGP L3 VPN

2009-07-23T21:43:00.000-07:00

With CCIE version 4 coming round the corner in October i thought i would turn my attention to some of the new topics on the syllabus. Here i look at MPLS VPNS and in the post i configure an MPLS L3 VPN.

There are 3 customers: A, B and C. These are connected across the shared MPLS infrastructure. The goal is to allow each customer to see their partner sites routes, and their routes only, across the MPLS cloud.

In this post i do not plan to look at the detailed workings of MPLS VPNS but rather just detail the steps necessary to build and configure.

In the MPLS cloud, BGP peering to the customer sites is implemented. The IGP routing protocol in the PE network is OSPF. The config i used to achieve this is layed out below.

First step is to define the customer VRFS and i apply the following config on each of the PE routers.

ip vrf CUSTA
rd 1:1
route-target export 1:1
route-target import 1:1
!
ip vrf CUSTB
rd 2:2
route-target export 2:2
route-target import 2:2
!
ip vrf CUSTC
rd 3:3
route-target export 3:3
route-target import 3:3

Second step is to apply the vrf config to the customer facing interfaces on the PE routers. At each step i verify my config with the show ip vrf command.

PE1(config-if)#DO SIIB
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.1 YES NVRAM up up
Serial2/0 10.0.0.2 YES manual up up
Serial2/1 10.0.0.6 YES NVRAM up up
Serial2/2 10.0.0.10 YES NVRAM up up

PE1(CONFIG)#int s2/0
PE1(config-if)#ip vrf forwarding CUSTA
% Interface Serial2/0 IP address 10.0.0.2 removed due to enabling VRF CUSTA
PE1(config-if)#ip address 10.0.0.2 255.255.255.252
PE1(config)#int s2/1
PE1(config-if)#ip vrf forwarding CUSTB
% Interface Serial2/1 IP address 10.0.0.6 removed due to enabling VRF CUSTB
PE1(config-if)#ip address 10.0.0.6 255.255.255.252
PE1(config-if)#int s2/2
PE1(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/2 IP address 10.0.0.10 removed due to enabling VRF CUSTC
PE1(config-if)#ip address 10.0.0.10 255.255.255.252

PE1#s ip vrf
Name Default RD Interfaces
CUSTA 1:1 Se2/0
CUSTB 2:2 Se2/1
CUSTC 3:3 Se2/2

PE2#siib
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.2 YES NVRAM up up
Serial2/0 12.0.0.2 YES NVRAM up up
Serial2/1 12.0.0.6 YES NVRAM up up

PE2(config)#int s2/0
PE2(config-if)#ip vrf for
PE2(config-if)#ip vrf forwarding CUSTA
% Interface Serial2/0 IP address 12.0.0.2 removed due to enabling VRF CUSTA
PE2(config-if)#ip address 12.0.0.2 255.255.255.252
PE2(config-if)#int s2/1
PE2(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/1 IP address 12.0.0.6 removed due to enabling VRF CUSTC
PE2(config-if)#ip address 12.0.0.6 255.255.255.252
PE2(config-if)#do s ip vrf
Name Default RD Interfaces
CUSTA 1:1 Se2/0
CUSTB 2:2
CUSTC 3:3 Se2/1

PE3#siib
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.3 YES manual up up
Serial2/0 11.0.0.2 YES NVRAM up up
Serial2/1 11.0.0.6 YES NVRAM up up

PE3(config-vrf)#int s2/0
PE3(config-if)#ip vrf forwarding CUSTB
% Interface Serial2/0 IP address 11.0.0.2 removed due to enabling VRF CUSTB
PE3(config-if)#ip address 11.0.0.2 255.255.255.252
PE3(config-if)#int s2/1
PE3(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/1 IP address 11.0.0.6 removed due to enabling VRF CUSTC
PE3(config-if)#ip address 11.0.0.6 255.255.255.252
PE3(config-if)#DO S IP VRF
Name Default RD Interfaces
CUSTA 1:1
CUSTB 2:2 Se2/0
CUSTC 3:3 Se2/1

The 3rd step is to configure the PE to CE BGP adjacencies. N.B. The CE to PE adjacencies are standard BGP config and i do not detail here. To keep the output down i have detailed the config required on PE1 only, as the config on the other PE routers is very similar.

router bgp 1000
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.5 remote-as 2
neighbor 10.0.0.9 remote-as 3

address-family ipv4 vrf CUSTC
neighbor 10.0.0.9 remote-as 3
neighbor 10.0.0.9 activate

address-family ipv4 vrf CUSTB
neighbor 10.0.0.5 remote-as 2
neighbor 10.0.0.5 activate

address-family ipv4 vrf CUSTA
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.1 activate

The 4th step is to configure the PE to PE adjacencies. Again i have detailed PE1 config only here

PE1
router bgp 1000
neighbor 13.0.0.2 remote-as 1000
neighbor 13.0.0.3 remote-as 1000
!
address-family vpnv4
neighbor 13.0.0.2 activate
neighbor 13.0.0.2 send-community extended
neighbor 13.0.0.3 activate
neighbor 13.0.0.3 send-community extended
exit-address-family

The 5th step is to enable mpls in the provide network.
On PE1, PE2 and PE3

conf t
mpls ip
int fa0/0
mpls ip

For verification

PE1#s ip bgp vpnv4 all sum | beg Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 1 46 49 24 0 0 00:17:01 2
10.0.0.5 4 2 6 6 24 0 0 00:01:33 2
10.0.0.9 4 3 5 4 19 0 0 00:00:43 2
101.101.101.101 4 1000 30 32 24 0 0 00:17:31 2
102.102.102.102 4 1000 31 34 24 0 0 00:17:19 2

PE1#s ip bgp vpnv4 *
BGP table version is 30, local router ID is 100.100.100.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTA)
*> 1.1.1.0/24 10.0.0.1 0 0 1 ?
r> 10.0.0.0/30 10.0.0.1 0 0 1 ?
*>i12.0.0.0/30 101.101.101.101 0 100 0 7 ?
*>i102.102.102.0/24 101.101.101.101 0 100 0 7 ?
Route Distinguisher: 2:2 (default for vrf CUSTB)
*> 2.2.2.0/24 10.0.0.5 0 0 2 ?
*>i4.4.4.0/24 102.102.102.102 0 100 0 4 ?
r> 10.0.0.4/30 10.0.0.5 0 0 2 ?
*>i11.0.0.0/30 102.102.102.102 0 100 0 4 ?
Route Distinguisher: 3:3 (default for vrf CUSTC)
*> 3.3.3.0/24 10.0.0.9 0 0 3 ?
*>i5.5.5.0/24 102.102.102.102 0 100 0 5 ?
*>i6.6.6.0/24 101.101.101.101 0 100 0 6 ?
r> 10.0.0.8/30 10.0.0.9 0 0 3 ?
*>i11.0.0.4/30 102.102.102.102 0 100 0 5 ?
*>i12.0.0.4/30 101.101.101.101 0 100 0 6 ?

Finally i examine the routing tables on peer customer sites to check routes have been shared. Here i dump the Customer A routing tables

CUSTA1>s ip route

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
7.0.0.0/24 is subnetted, 1 subnets
B 7.7.7.0 [20/0] via 10.0.0.2, 00:30:23
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Serial2/0
12.0.0.0/30 is subnetted, 1 subnets
B 12.0.0.0 [20/0] via 10.0.0.2, 00:37:16

CUSTA2#sir
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 12.0.0.2, 00:37:54
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, Loopback0
10.0.0.0/30 is subnetted, 1 subnets
B 10.0.0.0 [20/0] via 12.0.0.2, 00:37:54
12.0.0.0/30 is subnetted, 1 subnets
C 12.0.0.0 is directly connected, Serial2/0

I ping across the cloud

For Customer C
CUSTC3>ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 544/1161/1684 ms
CUSTC3>ping 6.6.6.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 624/1000/1700 ms

For Customer B
CUSTB2>p 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 692/1121/1388 ms

CUSTA1#ping 7.7.7.7

For customer A
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 60 percent (5/5), round-trip min/avg/max = 792/1004/1228 ms

QOS - MQC shape average vs shape peak

2009-07-16T21:26:00.000-07:00

The operation of shape peak is exactly the same as shape average:it calculates the default bc in the same manner, except, that each interval it gets to fill up the Be bucket as well. With the shape average command the excess burst is only sent if the bc bucket is full i.e. after periods of inactivity.

If a network has additional bandwidth available (over the provisioned CIR) and the application can tolerate occasional packet loss, the extra bandwidth can be exploited through the use of peak rate shaping. There may be occasional packet drops when network congestion occurs.

If the traffic being sent to the network must strictly conform to the configured network provisioned CIR, then use average traffic shaping.

If you had: shape peak 8000

We get a default tc of 1/8th of a second which gives us a bc of 1000 and a be of the same value. So the sending rate equals bc + be per tc or 16000. The rate equation is as follows

peak rate = CIR * (1 + Be/Bc)
peak rate = 8000 * (1 + 10/10) = 16000

In summary

shape average 8000 equates to a tcp traffic flow of 8000 bps.
shape peak 8000 equates to tcp traffic flow of 16000 bps.

R1
policy-map RICH
class class-default
shape average 8000 1000 1000

int fa0/0
policy-map output RICH

show policy-map int fa0/0
Service-policy output: RICH

Class-map: class-default (match-any)
86 packets, 7295 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
8000/8000 250 1000 1000 125 125

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 86 7295 0 0 no

R1
policy-map RICH
class class-default
shape peak 8000 1000 1000

int fa0/0
policy-map output RICH

show policy-map int fa0/0
Service-policy output: RICH

Class-map: class-default (match-any)
159 packets, 13622 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
16000/8000 250 1000 1000 125 250

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 4 298 0 0 no

QOS - MQC Policer

2009-07-13T21:41:00.001-07:00

The lab requirement here is to meter incoming HTTP traffic. When the traffic rate is less than 256kbps packets should be marked with precedence 4, and when the traffic exceeds 256kbps the traffic should be marked with precedence 0. The normal burst duration is 100 ms amd and an excess burst of 100ms should be allowed. Traffic exceeding these parameters should be dropped.

With the policing config the traffic rate is configured as bps wherease the burst size is configured in bytes. For a burst duration of 100ms then the burst size is calculated as follows: 256000 / 10 / 8 = 3200

I apply the configuration on R1 as follows

R1
class-map HTTP
match protocol http

policy-map POLICE
class HTTP
police 256000 bc 3200 be 3200 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop

int fa0/0
service-policy input POLICE

Verification

Router_1#show policy-map int fa0/0
FastEthernet0/0

Service-policy input: POLICE

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
police:
cir 256000 bps, bc 3200 bytes, be 3200 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

A further addendum to this post is the ability to police individual traffic flows inside an pre-existing policer!

For example, R1 is on a LAN segment connected to R6 and R4. A further requirement might be that traffic flows from these routers should only be able to consume half of the available bandwidth i.e. 128kbps each. This can be achieved by nesting policers as follows.

ip access-list extended R4
permit ip host 155.1.146.4 any
ip access-list extended R6
permit ip host 155.1.146.6 any

class-map R4
match access-group name R4
class-map R6
match access-group name R6

policy-map POLICE2
class R4
POLICE 128000 1600 1600 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop
class R6
POLICE 128000 1600 1600 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop

policy-map POLICE
class HTTP
police 256000 bc 3200 be 3200 conform-action transmit exceed-action set-prec-transmit 0 violate-action drop
service-policy POLICE2

Verification

Router_1#s policy-map int fa0/0
FastEthernet0/0

Service-policy input: POLICE

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
police:
cir 256000 bps, bc 3200 bytes, be 3200 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
transmit
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Service-policy : POLICE2

Class-map: R4 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name R4
police:
cir 128000 bps, bc 1600 bytes, be 1600 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: R6 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name R6
police:
cir 128000 bps, bc 1600 bytes, be 1600 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

QOS - FRTS PVC Priority Queue

2009-07-10T22:09:00.000-07:00

Within frame relay it is possible to prioritise one vcs traffic over and above another.
A priority queue for PVCS!!

map-class frame-relay DLCI_503
frame-relay interface-queue priority high
map-class frame-relay DLCI_502
frame-relay interface-queue priority medium
map-class frame-relay DEFAULT
frame-relay interface-queue priority low

int s2/0
frame-relay interface-queue priority
frame-relay class DEFAULT
frame-relay interface-dlci 503
class DLCI_503
frame-relay interface-dlci 502
class DLCI_502

QOS - FRTS custom queue

2009-07-09T21:52:00.000-07:00

Here i define a Frame Relay custom queue on dlci 502 on R5.

www traffic is defined to use 50% of the bandwidth, telnet traffic 30% and everything else is defined to use the default queue with a 20% share of the bandwitdh.

Additionally the queue size is set to 40 packets for the queues in use i.e. 1-3.

queue-list 2 protocol ip 1 tcp www
queue-list 2 protocol ip 2 tcp telnet
queue-list 2 default 3
queue-list 2 queue 1 byte-count 500 limit 40
queue-list 2 queue 2 byte-count 300 limit 40
queue-list 2 queue 3 byte-count 200 limit 40

map-class frame-relay DLCI_502
frame-relay cir 128000
frame-relay bc 1280
frame-relay be 0
frame-relay custom-queue-list 2

For verification i use the show traffic-shape queue command and the show frame pvc 502 command.

Router_5#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 501
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 504
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 503
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 502
Queueing strategy: custom-queue list 2

Router_5#show frame pvc 502

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

DLCI = 502, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 48 output pkts 67 in bytes 1548
out bytes 2227 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:19:07, last time pvc status changed 00:17:28
cir 128000 bc 1280 be 0 byte limit 160 interval 10
mincir 64000 byte increment 160 Adaptive Shaping none
pkts 79 bytes 2371 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: custom-list 2

List Queue Args
2 3 default

List Queue Args
2 1 protocol ip tcp port www
2 2 protocol ip tcp port telnet
2 1 byte-count 500 limit 40
2 2 byte-count 300 limit 40
2 3 byte-count 200 limit 40
Output queues: (queue #: size/max/drops/dequeued)
0: 0/20/0/0 1: 0/40/0/0 2: 0/40/0/0 3: 0/40/0/0 4: 0/20/0/0
5: 0/20/0/0 6: 0/20/0/0 7: 0/20/0/0 8: 0/20/0/0 9: 0/20/0/0
10: 0/20/0/0 11: 0/20/0/0 12: 0/20/0/0 13: 0/20/0/0 14: 0/20/0/0
15: 0/20/0/0 16: 0/20/0/0

QOS - FRTS priority queue

2009-07-08T22:16:00.000-07:00

Priority queueing can also be applied on a per VC basis. Configuration of the priority queues and flows is done in the standard manner.

access-list 150 permit tcp any any eq www
access-list 151 permit udp any any eq tftp
access-list 152 permit tcp any any eq cmd

priority-list 1 protocol ip high list 151
priority-list 1 protocol ip medium list 150
priority-list 1 protocol ip normal list 152
priority-list 1 default low

To apply the priority queueing this is NOT done under the interface. Without thinking i tried this and received the following error.

Router_5(config)#int s2/0
Router_5(config-if)#priority-group 1
Cannot change interface queuing when Frame-Relay traffic-shapi
ng is configured

For per VC priority queueing the priority queue must be applied to the map class used by the VC.

map-class DLCI_503
frame-relay priority-group 1

This can then be verified using the show traffic-shape queue command and the show frame pvc 503 commands.

Router_5#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 501
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 504
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 503
Queueing strategy: priority-group 1
Traffic queued in shaping queue on Serial2/0 dlci 502
Queueing strategy: fcfs

Router_5#show frame-relay pvc 503

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

DLCI = 503, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/

input pkts 71 output pkts 68 in bytes 6372
out bytes 6608 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:30:32, last time pvc status changed 00:28:53
cir 256000 bc 2560 be 0 byte limit 320 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 43 bytes 3952 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: priority-list 1

List Queue Args
1 low default

List Queue Args
1 high protocol ip list 151
1 medium protocol ip list 150
1 normal protocol ip list 152
Output queue: high 0/20/0, medium 0/40/0, normal 0/60/0, low 0/80/0

QOS - FRTS fair queue

2009-07-07T22:19:00.000-07:00

By default the queue will be FIFO or fcfs (first come first served). This can be seen by executing the show traffic-shape queue command.

Router_3#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 305
Queueing strategy: fcfs

Effectively this queueing mechanism is a 'per interface' queue. Per-VC WFQ can be enabled using the frame-relay fair-queue command.

map-class frame-relay DLCI_305
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
frame-relay mincir 256000
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion
frame-relay fair-queue 16 32 0 512

The change can be verified using the show traffic-shape queue command

Router_3#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 305
Queueing strategy: weighted fair
Queueing Stats: 0/512/16/0 (size/max total/threshold/drops)
Conversations 0/0/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 256 kilobits/sec

QOS - FRTS adaptive shaping

2009-07-07T21:55:00.000-07:00

R3 ------- R5

The lab requirement is to allow router 3 to 'oversubcribe' the link TO router 5 at 384k. The provider actually guarantees 256k.
In this situation the cir is set to the 'oversubcribed' rate and the mincir is set to the providers guaranteed rate.

Router 3
map-class frame-relay DLCI_305
frame-relay cir 384000
frame-relay mincir 256000
frame-relay bc 3840
frame-relay be 0
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion

frame-relay adaptive-shaping becn allows the router to adjust its sending rate down to minCIR when BECNs are received from the provider cloud.

frame-relay fecn-adapt when set on the receiving router enables it to generate BECNs when a FECN is received from the provider cloud.

Router 5
map-class frame-relay DLCI_503
frame-relay fecn-adapt

Also in this scenario, the feature frame-relay adaptive-shaping interface-congestion enables the sending router to slow down transmission when the interface queue reaches its threshold.

QOS - FRTS

2009-07-07T02:47:00.000-07:00

FRTS or Frame Relay Traffic shaping was intended as a replacement to GTS. It allows a more granular approach to QOS with shaping per VC.

Once traffic shaping is enabled on a physical interafce a CIR of 56kbps and a tc of 125ms applies. Configuration parameters are defined using the map-class frame-relay command and are then applied to the interface using frame-relay interface-dlci xxx.

In this example R3 and R5 and connected via a frame-relay circuit. The CIR is 256k, with bursts up to 384k permitted. R5 must not overwhelm R3 i.e. it must conform to the CIR of R3.

Router 3

map-class frame-relay DLCI_305
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 1280

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 305
class DLCI_305

Router 5

map-class frame-relay DLCI_503
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 503
class DLCI_503

Once applied the configuration can be verified with the show traffic-shape command

Router_3#show traffic-shape

Interface Se2/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
305 256000 480 2560 1280 10 320 -

FRTS employs a three tiered approach to queueing. The per vc queues, then the main interface queue, followed by the physical interface transmit ring. These can all be adjusted as follows

per vc FIFO: frame-relay holdq
interface FIFO: hold-queue
transmit-ring: tx-ring-limit

QOS - CAR

2009-07-06T22:41:00.000-07:00

CAR or Committed Access Rate

The lab topology and requirement in the post is the same as with the QOS - GTS post.
This time it is achieved using CAR.

TOPOLOGY: R2 ------ R3 ------ R1 ------ R4

The LAB requirement is to use CAR to limit the traffic flow to R4.
Packets destined to R4 loopback (150.1.4.4) is allowed 16k and packets destined to R4 fa0/0 (155.1.148.4) is allowed only 8K.

Router_1
int fa0/0
rate-limit access-group 100 8000 1000 2000 conform-action continue exceed-action drop
rate-limit access-group 101 16000 1000 2000 conform-action continue exceed-action drop

I execute pings from R3 and R2

Router_3#ping 155.1.148.4 size 4000 repeat 1000 timeout 1
Router_2#ping 155.1.148.4 size 4000 repeat 1000 timeout 1

I now verify the rate limiting on R1

Router 1
show int fa0/0 rate-limit
FastEthernet0/0
Output
matches: access-group 100
params: 8000 bps, 1500 limit, 2000 extended limit
conformed 59 packets, 65866 bytes; action: transmit
exceeded 136 packets, 199464 bytes; action: drop
last packet: 20ms ago, current burst: 1810 bytes
last cleared 00:01:04 ago, conformed 8000 bps, exceeded 24000 bps
matches: access-group 101
params: 16000 bps, 1500 limit, 2000 extended limit
conformed 95 packets, 130030 bytes; action: transmit
exceeded 100 packets, 135300 bytes; action: drop
last packet: 36ms ago, current burst: 1676 bytes
last cleared 00:01:04 ago, conformed 16000 bps, exceeded 16000 bps

QOS - GTS

2009-07-06T22:02:00.000-07:00

TOPOLOGY: R2 ------ R3 ------ R1 ------ R4

GTS or generic traffic shaping. This predates MQC.
The LAB requirement here is to use GTS to limit the traffic flow to R4. Packets destined to R4 loopback (150.1.4.4) is allowed 16k and packets destined to R4 fa0/0 (155.1.148.4) is allowed only 8K.

I create two acls matching the required traffic flows on R1

access-list 100 permit ip any 155.1.148.0 0.0.0.255
access-list 101 permit ip any 150.1.4.0 0.0.0.255

I apply 2 traffic-shape commands to the fa0/0 interface on R1.

interface FastEthernet0/0
ip address 155.1.148.1 255.255.255.0
duplex half
traffic-shape group 100 8000 1000 2000 10
traffic-shape group 101 16000 1000 2000 10

I execute 2 pings: One from R3 to fa0/0 on R4, and one from R2 to lo0 on R4.

Router_3#ping 155.1.148.4 size 2000 repeat 1000 timeout 1
Router_2#ping 150.1.4.4 size 2000 repeat 1000 timeout 1

I then examine the traffic shaping with the following three commands on R1.

show traffic-shape
show traffic-shape statistics
show traffic-shape queue fa0/0

Router_1#show traffic-shape

Interface Fa0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 100 8000 375 1000 2000 125 125 -
- 101 16000 375 1000 2000 62 125 -

Router_1#show traffic-shape queue fa0/0
Traffic queued in shaping queue on FastEthernet0/0
Traffic shape group: 100
Queueing strategy: weighted fair
Queueing Stats: 10/10/64/46 (size/max total/threshold/drops)
Conversations 1/1/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 8 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 10/4048/46/0/0
Conversation 1, linktype: ip, length: 1514
source: 155.1.13.3, destination: 155.1.148.4, id: 0x002B, ttl: 254, prot: 1

Traffic shape group: 101
Queueing strategy: weighted fair
Queueing Stats: 9/10/64/61 (size/max total/threshold/drops)
Conversations 1/1/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 16 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 9/4048/61/0/0
Conversation 5, linktype: ip, length: 1514
source: 155.1.23.2, destination: 150.1.4.4, id: 0x004E, ttl: 253, prot: 1

Lastly the show traffic-shape statistics command indicates the ping to R4 loopback is transmitting twice the amount of data in comparison to the ping to R4 fa0/0 interface.

Router_1#show traffic-shape stat
Acc. Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Fa0/0 100 10 98 130592 92 128508 yes
Fa0/0 101 10 277 329510 254 309188 yes

GTS can also be applied to the interface as a whole with the traffic-shape rate command. For example.

int fa0/0
traffic-shape rate 128000 8000 8000 100

QOS - Hardware Queue

2009-06-27T22:08:00.000-07:00

Here i look at QOS starting from the ground up.

First for traffic in the outbound direction. Each interface has a hardware queue also known as the tx-ring or transmit ring. This is always serviced FIFO.

The size of this queue can be viewed

Router_1#show controllers fa0/0 | inc tx_lim
tx_limited=0(256)
In this example the default size is 256 packets. This can be adjusted. In this example i reduce the size to 50 packets.

config-if=tx-ring-limit 50

If the hardware queue becomes full then the output software queue is used for buffering traffic. When adjusting queueing mechanisms it is this logic for emptying this queue that is adjusted e.g. PQ,CBWFQ, CQ etc

The size of this queue can be seen using the standard show interface command. by default it has a size of 40 packets.

Router_1#show int fa0/0 | inc Output queue
Output queue: 0/40 (size/max)

The size of the queue can be adjusted using the following command

conf-if# hold-queue 20 out

N.B. The hold-queue size applies when default FIFO queueing is in use on the interface. When other queuing methods are in use this command does not apply and the software queue sizes are set by the relevant queuing commands.

Now Input queueing....

Packets in an inbound direction are immediately handled by the interface drivers, router cpu etc. If buffering is needed due to high throughput or router load then the input queue is used.

The size of this queue is 75 packets by default and this can be viewed using the show interface command.

Router_1#show int fa0/0 | inc Input queue
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

This can be adjusted as follows

config-if#hold-queue 20 in

PIM - SSM

2009-06-20T22:23:00.000-07:00

PIM SSM or Source Specific Multicast, contrary to PIM BiDir, does NOT require the PIM shared tree, and does not use it. No RPS are required and RP protocols such as Auto RP or BSR are not needed. With SSM the SPT is always used.

Like BiDir PIM configuration is pretty straightforward.

The range of multicast groups that are using ssm signaling must be specified on all routers in the mcast domain

To enable pim ssm on the default range of 232.0.0.0/8

#conf t
config#ip pim ssm range default

Note for groups in the ssm range no shared trees are allowed and any (*,G) joins will be dropped.

The final step is to enable IGMP version 3 needs on the receiver facing interfaces.

for SW1 TO JOIN 232.8.8.8 for source 150.1.5.5

config-if#ip igmp version 3
config-if#ip igmp join 232.8.8.8 source 150.1.5.5

PIM - BIDIR

2009-06-20T21:36:00.000-07:00

Bidirectional PIM can be used when most receivers of mcast traffic are also senders at the same time. It is an extension to PIM sparse mode that only uses the shared tree for multicast distribution. Packets flow to and from the RP only.

It is relatively easy to configure, although the BIDIR configuration example on the CISCO web site doesn't quite give the full picture, as it only shows configuration on as single router.

BiDir PIM must be enabled on all multicast routers and specified multicast groups need to be configured as BiDir. This can be done using static rp, autop rp or BSR.

I use the simple router topology SW1 ----- R3 ------ R5

On each router i enable BiDir PIM.

conf t
ip pim bidir-enable

The RP (R5 in this case) must specify which bidir groups it services.

ip access-list st 45
permit 238.0.0.0 0.255.255.255

For BSR
ip pim rp-candidate lo0 group-list 45 bidir

For AUTO-RP
ip pim send-rp-announce lo0 scope 16 group-list 45 bidir

For static RP
ip pim rp-address 150.1.5.5 45 bidir

On SW1 i join the bidir mcast group 238.0.0.1

conf t
int fa0/0
ip igmp join-group 238.0.0.1

On R3 i examine the mroute table

Router_3#s ip mroute 238.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 238.0.0.1), 00:16:10/00:02:22, RP 150.1.5.5, flags: BC
Bidir-Upstream: Serial2/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:15:52/00:02:34
Serial2/0, Bidir-Upstream/Sparse, 00:16:10/00:00:00

From R5 i verify solution with a ping to multicast group 238.0.0.1

Router_5#ping 238.0.0.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 238.0.0.1, timeout is 2 seconds:

Reply to request 0 from 155.1.0.3, 88 ms
Reply to request 0 from 155.1.37.7, 228 ms
Reply to request 0 from 155.1.0.3, 88 ms

Multicast - Rate Limiting

2009-06-15T22:25:00.000-07:00

SW1 -------- R3 ---------- R5

Here i make use of the multicast rate limiting function on R3 to control the amount of multicast traffic allowed to reach SW1.

First SW1 joins multicast groups 225.0.0.1 and 225.0.0.3

SW1
conf t
int fa0/0
ip igmp join-group 225.0.0.1
ip igmp join-group 225.0.0.3

On R3 the requirement is to limit the mcast traffic to 225.0.0.1 to 1k and 225.0.0.3 to 3k. The aggregate multicast traffic rate must not exceeed 5k.

This requirement can be achieved via the multicast rate limit function. Multiple rate limit statements can be applied to an interface and they are processed in a linear top down fashion. Hence careful consideration must be given to the order of the statements as applied.

First i use ACLS to define the mcast groups

R3
ip access-list standard GROUP_1
permit 225.0.0.1
ip access-list standard GROUP_3
permit 225.0.0.3

Then i apply the rate limit function.

interface FastEthernet0/0
ip multicast rate-limit out group-list GROUP_1 1
ip multicast rate-limit out group-list GROUP_3 3
ip multicast rate-limit out 5

After applying the mcast routes can be viewed and the bandwidth limits are shown

Router_3#s ip mroute 225.0.0.1
(*, 225.0.0.1), 00:13:28/00:02:33, RP 150.1.5.5, flags: SJC
Incoming interface: Serial2/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:13:28/00:02:51, limit 1 kbps

Router_3#s ip mroute 225.0.0.3
(*, 225.0.0.3), 00:07:34/00:02:51, RP 150.1.5.5, flags: SJC
Incoming interface: Serial2/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:07:34/00:02:51, limit 3 kbps

I then test the rate limiting via ping tests from R5. First i try a ping rate that conforms to the bandwidth limit.

Router_5#pin 225.0.0.1 size 100 repeat 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 155.1.37.7, 184 ms
Reply to request 0 from 155.1.37.7, 184 ms
Reply to request 1 from 155.1.37.7, 212 ms
Reply to request 1 from 155.1.37.7, 212 ms

Now i try a ping with an increased data size that exceeds the 1 kbps limit and, as expected, the traffic is dropped.

Router_5#pin 225.0.0.1 size 200 repeat 2

Type escape sequence to abort.
Sending 2, 200-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:
..

I repeat the above test on the mcast group 225.0.0.3 that has a higher bandwidth limit of 3k.

Router_5#pin 225.0.0.3 size 360 repeat 2

Type escape sequence to abort.
Sending 2, 360-byte ICMP Echos to 225.0.0.3, timeout is 2 seconds:

Reply to request 0 from 155.1.37.7, 208 ms
Reply to request 0 from 155.1.37.7, 212 ms
Reply to request 1 from 155.1.37.7, 268 ms
Reply to request 1 from 155.1.37.7, 268 ms
Router_5#pin 225.0.0.3 size 400 repeat 2

Type escape sequence to abort.
Sending 2, 400-byte ICMP Echos to 225.0.0.3, timeout is 2 seconds:
..
Router_5#

PIM - IGMP GROUP LEAVE TIMERS

2009-06-14T22:12:00.000-07:00

If a host on the LAN leaves a group it sends an IGMP leave message (assuming PIM version 2). Upon receipt the elected IGMP querier will send out an IGMP last member group query to ascertain if there are still other hosts on the LAN segment who are members of the group. If no hosts reply, after the message has been repeated, then the IGMP querier router removes the (*,G) mroute.

The timers/counters involved in this exchange are

ip igmp last-member-query-count (default 2)

ip igmp last-member-query-interval (default 1000ms)

PIM - IGMP QUERIER TIMEOUT

2009-06-14T22:07:00.000-07:00

The router elected as IGMP querier will send out an IGMP query each configured interval. If non IGMP querier routers on the same LAN segment do not hear any IGMP queries for a period of time they will try and assume the IGMP querier role.

The timers used in this exchange are as follows

ip igmp query-interval (default 60 seconds)

ip igmp querier-timeout (default 120 seconds - 2 * ip igmp query interval)

PIM - IGMP GROUP QUERY TIMERS

2009-06-14T21:53:00.000-07:00

The IGMP querier will send out an igmp group query to check group memmbership on the connected LAN segment. Normallly an IGMP group report response will be received. If no group report is received then the (*,G) mroute is removed.

In this message exchange the following timers can be influenced.

ip igmp query-interval (default 60 seconds)

ip igmp query-max-response-time (default 10 seconds).

PIM/IGMP Elections

2009-06-13T22:38:00.000-07:00

On a shared LAN segment, amongst the PIM enabled routers, a selected router must assume the responsibilty for i) sending any PIM register/prune messages to the RP and for ii) sending IGMP query messages.

I was until recently under the misunderstanding that the PIM DR router performed both of these functions - wrong!! These functions are completely decoupled and in fact they have a different election process and selection criteria.

First the Querier Election Process.
At start up each router sends a query message to the all systems group 224.0.0.1 from its own interface address. The router with the lowest ip address is elected IGMP querier.

Second the PIM DR Election Process
The router with the highest ip address is elected as PIM DR. This selection process can also be influenced by configuring a pim DR priority. By default all routers have priority 1, hence highest ip address wins by default. However if DR priority is used then highest DR priority wins.

The show igmp interface command can be used to show elected DR and querier. Here 155.1.148.1 is elected querier (lowest ip address on LAN segment) and 155.1.148.6 is elected DR (highest ip address on LAN segment).

Router_1(config)#do s ip igmp int fa0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 155.1.148.1/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 20 seconds
IGMP querier timeout is 40 seconds
IGMP max query response time is 4 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 0 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 155.1.148.6
IGMP querying router is 155.1.148.1 (this system)
No multicast groups joined by this system

PIM - BSR load balancing

2009-06-12T22:10:00.000-07:00

With BSR if multiple RPs are defined to service the same multicast groups then the BSR candidate router will distribute the load amongst these RPS. This is done using an algorithm based on the HASH length defined. The longer the hash length the more random the assignment.

Based on the following config, the RP assignment can be examined on the routers.

R1
ip pim rp-candidate Lo0

R3
ip pim rp-candidate Lo0

R5
ip pim bsr-candidate Lo0 32

Here i examine the RP for group 238.1.1.1 and 237.1.1.1. The BSR has assigned R3 as the R3 (150.1.9.9) as the RP for 238.1.1.1 and R1 (150.1.7.7) AS THE rp FOR 237.1.1.1.

R1#show ip pim rp-hash 238.1.1.1
RP 150.1.9.9 (?), v2
Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:48, expires: 00:01:46
PIMv2 Hash Value (mask 255.255.255.255)
RP 150.1.7.7, via bootstrap, priority 0, hash value 377749190
RP 150.1.9.9, via bootstrap, priority 0, hash value 1884030652
R1#show ip pim rp-hash 237.1.1.1
RP 150.1.7.7 (?), v2
Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:01:12, expires: 00:01:39
PIMv2 Hash Value (mask 255.255.255.255)
RP 150.1.7.7, via bootstrap, priority 0, hash value 1501822662
RP 150.1.9.9, via bootstrap, priority 0, hash value 860620476

PIM - BSR

2009-06-12T12:22:00.000-07:00

PIM BSR (Bootstrap Routing) - the basics

The BSR mechanism is a nonproprietary method of defining RPs that can be used with third-party routers. There is no configuration necessary on every router separately (except on candidate-BSRs and candidate-RPs). The canidate-RPs are analagous with Auto-RP candidate RPs and the candidate-BSRs are analagous with the Auto RP mapping agent.

Thes can be defined as follows.

R1
ip pim rp-candidate Loopback0

R3
ip pim rp-candidate Loopback0

R5
ip pim bsr-candidate Loopback0 31

Router_5#show ip pim rp-hash 224.1.1.1
RP 150.1.7.7 (?), v2
Info source: 155.1.37.7 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:15:07, expires: 00:02:21
PIMv2 Hash Value (mask 255.255.255.254)
RP 150.1.7.7, via bootstrap, priority 0, hash value 1852227743
RP 150.1.9.9, via bootstrap, priority 0, hash value 800581801

PIM - Multicast Boundary

2009-06-11T22:16:00.000-07:00

The multicast boundary feature, when used with a standard acl, can be used to filter (S,G) and (*,G) join messages to the RP as well as filter mcast traffic destined to a multicast group. Note it does not filter PIM register messages as these are sent as unicast messages from the PIM DR to the PIM RP.

Consider the following configuration

access-list 5 deny 232.0.0.0 7.255.255.255
access-list 5 permit 224.0.0.0 15.255.255.255

int fa0/0
ip multicast boundary 5 filter-autorp

This command will filter multicast traffic for the range 232.0.0.0/5. This includes any traffic in this range plus any ranges that overlap with this range.

The addition of the filter-autorp messages ensures the filtering is applied to rp announcements as well as multicast traffic.

For example the downstream switch SW2 was receiving announcements for the following groups.

SW2#s ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/5
RP 150.1.7.7 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:19:45, expires: 00:02:33
Group(s) 224.0.0.0/4
RP 150.1.9.9 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:19:15, expires: 00:01:34
Group(s) (-)224.50.50.50/32
RP 150.1.9.9 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:19:15, expires: 00:02:36
Group(s) 232.0.0.0/5
RP 150.1.9.9 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:19:15, expires: 00:01:37

After the multicast boundary statement wis applied to the upstream neighbor rp announcements for 232.0.0./5 and 224.0.0.0/4 are both removed.

SW2#s ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/5
RP 150.1.7.7 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP
Uptime: 00:23:58, expires: 00:02:20
Group(s) (-)224.50.50.50/32
RP 150.1.9.9 (?), v2v1
Info source: 150.1.1.1 (?), elected via Auto-RP

PIM - MA Placement in a Frame Relay network

2009-06-10T23:07:00.000-07:00

When placing the Mapping Agent in a frame relay hub and spoke environment always aim to locate it at the hub or behind it.

PIM by default will assume NBMA interfaces are broadcast capable. However, by default, when a spoke sends a multicast message the hub will not replicate this to other spokes, obeying the split horizon rule. This can in part be solved by the placement of the ‘ip pim nbma-mode’ command on the hub. It is worth noting however that this only fixes sparse-mode traffic. Dense mode traffic will NOT be replicated.

Hence this poses a problem for auto-rp information which uses dense mode to mcast groups 224.0.1.39 and 224.0.1.40.

If the RP and mapping agent are placed on a spoke then auto-rp messages will only reach the hub node. If the mapping agent is on the hub then RPs could be located on the spokes as long as the announces reach the hub.

There are a couple of resolutions to this problem. First use sub-interfaces on the hub, or secondly create multicast enabled tunnels between the spokes.

The tunnel config for the spokes is shown here.

Router_1#
interface Tunnel0
ip address 155.1.20.20 255.255.255.0
ip pim sparse-mode
tunnel source Loopback1
tunnel destination 150.1.3.3
tunnel mode ipip

Router_3#
interface Tunnel0
ip address 155.1.20.21 255.255.255.0
ip pim sparse-mode
tunnel source Loopback0
tunnel destination 150.1.1.1
tunnel mode ipip

Another caveat is that if the tunnel is not included in the IGP routing then static multicast routes will be required pointing at the tunnel to ensure RPF checks don’t fail.

R1
Ip mroute 150.1.1.1 255.255.255.255 tu0

Note. The problem with the disssemination of traffic to mcast group 224.1.0.40 can be seen on the hub (R5) as the frame relay serial interface S2/0 is missing in the OIL interface list.

(150.1.1.1, 224.0.1.40), 01:14:19/00:02:34, flags: LT
Incoming interface: Serial2/0, RPF nbr 155.1.0.1
Outgoing interface list:
Loopback0, Forward/Sparse, 01:14:19/00:00:00
Serial2/1, Forward/Sparse, 01:14:19/00:00:00
FastEthernet0/0, Forward/Sparse, 01:14:19/00:00:00

PIM misc - dense mode reqd in sparse-dense region

2009-06-10T12:46:00.000-07:00

Suppose the lab required one Mcast range ONLY operate in dense mode, whereas the rest of the domain should operate in sparse mode???

This can be achieved by making use of the 'deny' statement in the ACL used to denote the mcast groups serviced by the candidate RP.

SW3#s access-list 11
Standard IP access list 11
40 deny 224.50.50.50
20 permit 232.0.0.0, wildcard bits 7.255.255.255
30 permit 224.0.0.0, wildcard bits 15.255.255.255

When examining the rp mapping then the 'denied' range will be shown with a minus

Group(s) (-)224.50.50.50/32
RP 150.1.9.9 (?), v2v1
Info source: 150.1.9.9 (?), elected via Auto-RP
Uptime: 00:01:31, expires: 00:02:27
RP 150.1.7.7 (?), v2v1
Info source: 150.1.7.7 (?), via Auto-RP
Uptime: 00:01:07, expires: 00:02:50

PIM RP Load Balancing and Redundancy

2009-06-10T12:11:00.000-07:00

Here look at achieving load-balancing and redundancy of multicast traffic between RPS.

First load-balancing

Auto-RP is being used. SW1 is configured as RP for 224.0.0.0 - 231.255.255.255 and
SW3 is RP for 232.0.0.0 239.255.255.255.

SW1
ip pim send-rp-announce Loopback0 scope 16 group-list 11
ip access-list st 11
permit 224.0.0.0 7.255.255.255

SW3
ip pim send-rp-announce Loopback0 scope 16 group-list 11
ip access-list st 11
permit 232.0.0.0 7.255.255.255

Now examining the rp mapping on the RP we can see the load is balanced between SW1 (150.1.7.7) and SW3 (150.1.9.9).

Router_5>s ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/5
RP 150.1.7.7 (?), v2v1
Info source: 150.1.7.7 (?), elected via Auto-RP
Uptime: 00:00:06, expires: 00:02:53
Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:13:55, expires: 00:02:11
Group(s) 232.0.0.0/5
RP 150.1.9.9 (?), v2v1
Info source: 150.1.9.9 (?), elected via Auto-RP
Uptime: 00:00:31, expires: 00:02:24

Next step is to achieve redundancy. Make SW1 backup SW3 should it fail and vice versa.

This can be achieved by defining each candidate RP with the same duplicate range. The mapping agent will select the RP with the highest ip address.

So on SW1 and SW3 i update access list 11 as follows:-

ip access-list st 11
permit 224.0.0.0 15.255.255.255

Router_5>show ip pim rp map 224.0.0.0
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/5
RP 150.1.7.7 (?), v2v1
Info source: 150.1.7.7 (?), elected via Auto-RP
Uptime: 00:07:38, expires: 00:02:21
Group(s) 224.0.0.0/4
RP 150.1.9.9 (?), v2v1
Info source: 150.1.9.9 (?), elected via Auto-RP
Uptime: 00:02:01, expires: 00:01:56
RP 150.1.7.7 (?), v2v1
Info source: 150.1.7.7 (?), via Auto-RP
Uptime: 00:01:38, expires: 00:02:18
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), via Auto-RP
Uptime: 00:21:27, expires: 00:02:46

The mapping agent shows SW3 as the winning candidate RP for the 224.0.0.0/4 range. On other routers only the winning RP will be shown in the rp map table.

Router_6>s ip pim rp map

PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 150.1.9.9 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:04:10, expires: 00:02:42

Note. When selecting ranges to advertise the mapping agent will always advertise the longest match mcast range.

PIM DR

2009-06-08T21:28:00.000-07:00

On a multiaccess network there may be multiple IGMP enabled routers. It is the responsibility of one of these IGMP routers to send any PIM join messages towards the RP.

If no PIM DR priority is expilicitly configured the IGMP/PIM router with the highest ip address is elected as the DR and will send the join. The PIM DR priority can be used to influence which router is elected to forward the PIM join messages.

In the above scenario, without any DR priorities configured, R6 is elected DR as it has the highest ip address.

Router_1>S IP PIM NE
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
155.1.148.6 FastEthernet0/0 00:01:26/00:01:17 v2 1 / DR S
155.1.148.4 FastEthernet0/0 00:02:16/00:01:18 v2 1 / S
155.1.0.5 Serial2/0 00:00:21/00:01:24 v2 1 / DR S

If the lab requirement states R1 should be the DR for this segment this can be achieved with the use of the 'ip pim dr-priority' message.

config#int fa0/0
config-if#ip pim dr-priority 100

With the above config applied i re-examine the PIM neighbors and R1 has pre-empted the DR position.

Router_4#s ip pim ne
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
155.1.148.6 FastEthernet0/0 00:02:14/00:01:28 v2 1 / S
155.1.148.1 FastEthernet0/0 00:02:35/00:01:28 v2 100/ DR S
155.1.46.5 Serial2/1 00:02:49/00:01:22 v2 1 / S

From R1 this can be seen as well using the 'show ip pim interface fa0/0' command.

Router_1#s ip pim interface fa0/0
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
155.1.148.1 FastEthernet0/0 v2/SD 2 30 100 155.1.148.1

In summary the PIM DR controls upstream PIM joins, and from my previous post the PIM assert mechanism controls downstream routing of multicast traffic.

Controlling access to RP

2009-06-07T23:04:00.000-07:00

PIM has the functionality to specify the multicast groups that an RP will allow joins from.

This allows central control over the mcast groups serviced by the RP.

The following config will only allow joins to mcast groups 224.11.11.11 and 224.111.111.111 for the RP 150.1.5.5. This can be enabled on the RP itself, or altenatively on routers on the path to the RP.

ip access-list st 5
permit 224.11.11.11
permit 224.111.111.111

ip pim accept-rp 150.1.5.5 5

With 'debug ip pim' enabled failed attempts to the join RP are logged

*Jun 8 07:03:13.039: PIM(0): Join-list: (*, 224.20.20.20),, ignored, invalid RP
150.1.5.5 from 155.1.58.2

PIM Assert

2009-06-07T22:37:00.000-07:00

The PIM Assert mechanism is used to shutoff duplicate flows onto the same multiaccess network. Routers detect this condition when they receive an (S,G) packet via a multi-access interface that is already in the (S,G) OIL. This causes the routers to send Assert Messages.

In this scenario the workstation attached to R6 has joined group 239.6.6.6. A multicast feed is started and both R1 and R4 begin sending the mcast.

With 'debug ip pim' enabled on R1 and R4, it can be seen that a PIM assert exhange is initiated between them.

ON R1
*Jun 8 06:18:49.419: PIM(0): Send v2 Assert on FastEthernet0/0 for 239.6.6.6, source 155.1.58.2, metric [80/65]
*Jun 8 06:18:49.423: PIM(0): Assert metric to source 155.1.58.2 is [80/65]
*Jun 8 06:18:49.423: PIM(0): We win, our metric [80/65]

ON R4
*Jun 8 06:18:49.359: PIM(0): Received v2 Assert on FastEthernet0/0 from 155.1.1
48.1
*Jun 8 06:18:49.367: PIM(0): Assert metric to source 155.1.58.2 is [80/65]
Router_4#
*Jun 8 06:18:49.371: PIM(0): We lose, our metric [90/2172416]

The winner of the assert exchange is the router with best (AD,Metric). In the above case, R1 has an AD of 80 and R4 has an AD of 90. R1 wins!

As a result R4 prunes the S,G entries in its routing table

Router_4#s ip mroute 239.6.6.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.6.6.6), 00:04:43/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/1, Forward/Sparse-Dense, 00:04:43/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:04:43/00:00:00

(150.1.8.8, 239.6.6.6), 00:00:56/00:02:05, flags: PT
Incoming interface: Serial2/1, RPF nbr 155.1.46.5
Outgoing interface list:
FastEthernet0/0, Prune/Sparse-Dense, 00:00:56/00:02:03

(155.1.58.2, 239.6.6.6), 00:00:56/00:02:05, flags: PT
Incoming interface: Serial2/1, RPF nbr 155.1.46.5
Outgoing interface list:
FastEthernet0/0, Prune/Sparse-Dense, 00:00:56/00:02:03

On R1 the S,G entries remain with an 'A' by them denoting Assert winner!

Router_1#s ip mroute 239.6.6.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.6.6.6), 00:05:01/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/0, Forward/Sparse-Dense, 00:05:01/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:05:01/00:00:00

(150.1.8.8, 239.6.6.6), 00:01:14/00:01:46, flags: T
Incoming interface: Serial2/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:01:14/00:00:00, A

(155.1.58.2, 239.6.6.6), 00:01:14/00:01:46, flags: T
Incoming interface: Serial2/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:01:14/00:00:00, A

SNMP version 3

2009-05-31T22:54:00.000-07:00

SNMP version 3 incorporates security enhancements into the SNMP protocol.

To utilise this new functionality SNMP groups with associated user names and passwords must be created.

The 1st step is to specify an acl of users allowed to access the group

config#ip access-list st 1
config-std-acl#permit 130.1.1.1

config#snmp-server group IELAB v3 auth access 1

The 2nd step is to specify the user names and passwords

config#snmp-server user rich IELAB v3 auth md5 CISCO

Verification can be done with the command

R4#s snmp user
User name: rich
Engine ID: 800000090300CA0309800000
storage-type: nonvolatile active

When defining the snmp host the authentication method can then be specified.

config#snmp-server host 154.1.3.100 version 3 auth IELAB

Multicast - Shared Trees

2009-05-21T22:20:00.000-07:00

I thought i would write about the multicast 'shared tree' and how it is built. Once understood, I feel this has certainly helped me with multicast and troubleshooting along the way.

This is a two stage process: the server 'registers' to the RP and the client 'joins' the RP. These 2 processes are independent of each other and is the same regardless of the underlying PIM RP selection protocol e.g. Auto rp, static rp, or BSR.

In this example i use multicast servers attached to R6 and clients attached to R4.
The RP is 150.1.5.5 on R5

First the registration process.
A server at 204.12.1.254 starts to send to a multicast address multicast address 224.4.4.4. The PIM interface on the local LAN segment receives the multicast packet and sends a PIM 'register' to the RP, 150.1.5.5 in this example. This message is actually encapsulated as a unicast message to 150.1.5.5.

When the RP receives this register message it acknowledges receipt

The output of the debug ip pim on R6 (local PIM interface) and R5 (the RP) shows this...

R6#
*May 21 06:35:16.647: PIM(0): Check RP 150.1.5.5 into the (*, 224.4.4.4) entry
*May 21 06:35:16.655: PIM(0): Send v2 Register to 150.1.5.5 for 204.12.1.254, gr
oup 224.4.4.4
*May 21 06:35:17.143: PIM(0): Received v2 Register-Stop on FastEthernet0/0 from
150.1.5.5
*May 21 06:35:17.147: PIM(0): for source 204.12.1.254, group 224.4.4.4
*May 21 06:35:17.147: PIM(0): Clear Registering flag to 150.1.5.5 for (204.12.1.
254/32, 224.4.4.4)

R5#
*May 21 06:35:16.483: PIM(0): Received v2 Register on Serial2/0 from 192.10.1.6
*May 21 06:35:16.487: for 204.12.1.254, group 224.4.4.4
*May 21 06:35:16.491: PIM(0): Check RP 150.1.5.5 into the (*, 224.4.4.4) entry
*May 21 06:35:16.495: PIM(0): Send v2 Register-Stop to 192.10.1.6 for 204.12.1.2
54, group 224.4.4.4

Following this registration process entries are placed in the mroute table on R6 and R5, but not any intervening routers in the unicast path between R6 and R5.

On R6 2 mroute entries are created: the (*,G) entry and the (S,G) entry. Both entries at this stage have a null output interface as no client has yet registered for this multicast feed. The (S,G) entry denotes that a server is sending to the multicast group.

R6#s ip mroute 224.4.4.4
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.4.4.4), 00:11:12/stopped, RP 150.1.5.5, flags: SPF
Incoming interface: FastEthernet0/0, RPF nbr 192.10.1.1
Outgoing interface list: Null

(204.12.1.254, 224.4.4.4), 00:11:12/00:02:51, flags: PFT
Incoming interface: FastEthernet1/0, RPF nbr 0.0.0.0
Outgoing interface list: Null

On R5, the RP, a similar 2 entries are created.

R5#s ip mroute 224.4.4.4
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.4.4.4), 00:10:16/stopped, RP 150.1.5.5, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(204.12.1.254, 224.4.4.4), 00:10:16/00:02:47, flags: P
Incoming interface: Tunnel53, RPF nbr 154.1.0.3, Mroute
Outgoing interface list: Null

This completes the register process.

Second the client 'join' process.
A mcast client is connected to R4 and sends an IGMP join for the multicast group 224.4.5.6. Upon receipt of the IGMP join R4 sends a PIM join message towards the RP (R5).

Debug output on R5 shows receipt of the join message.

R5#
*May 21 06:59:48.519: PIM(0): Received v2 Join/Prune on Tunnel53 from 154.1.0.3,
to us
*May 21 06:59:48.523: PIM(0): Join-list: (*, 224.4.5.6), RPT-bit set, WC-bit set
, S-bit set
*May 21 06:59:48.527: PIM(0): Add Tunnel53/154.1.0.3 to (*, 224.4.5.6), Forward
state, by PIM *G Join

On the RP (R5) a (*,G) entry is created in the mroute table

R5#s ip mroute 224.4.5.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.4.5.6), 00:02:47/00:02:58, RP 150.1.5.5, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel53, Forward/Sparse-Dense, 00:01:48/00:02:40
FastEthernet1/0, Forward/Sparse-Dense, 00:02:47/00:02:58

Notice this time the entry has a populated outgoing interface. With the join process all PIM enabled routers in the path to the RP also build such an entry in their mroute table.

This completes the join process.

Tying 'register' and 'join' together
The RP ties the join and register processes together. I initiate a server multicast feed to the multicast address 224.4.5.6.

I start a ping to 224.4.5.6

ping 224.4.5.6 repeat 10000
Reply to request 23 from 154.1.0.4, 552 ms
Reply to request 24 from 154.1.0.4, 676 ms
Reply to request 25 from 154.1.0.4, 788 ms
Reply to request 26 from 154.1.0.4, 964 ms
Reply to request 27 from 154.1.0.4, 824 ms

This will again initiate a new register from the local PIM interface to the RP for this multicast group.

I examine the mroute table on the RP with this multicast ping in process.

R5#s ip mroute 224.4.5.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.4.5.6), 00:03:55/00:03:29, RP 150.1.5.5, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel53, Forward/Sparse-Dense, 00:02:56/00:03:29
FastEthernet1/0, Forward/Sparse-Dense, 00:03:55/00:02:50

(204.12.1.254, 224.4.5.6), 00:00:22/00:02:59, flags: T
Incoming interface: Tunnel53, RPF nbr 154.1.0.3, Mroute
Outgoing interface list:
FastEthernet1/0, Forward/Sparse-Dense, 00:00:22/00:02:50

As before the RP contains both the (*,G) and (S,G) entries. Since a client has registered for this feed both entries also contain an interface in the outgoing interface list (OIL).

I examine the mroute table on R6 (the PIM router connected to the multicast server). Similarly there are 2 entries for the multicats group 224.4.5.6. Note the (S,G) entry has an OIL entry, however the (*,G) entry does not.

Only those routers in the path between the multicast client an the RP will have a populated OIL for this entry.

R6#s ip mroute 224.4.5.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.4.5.6), 00:03:13/stopped, RP 150.1.5.5, flags: SPF
Incoming interface: FastEthernet0/0, RPF nbr 192.10.1.1
Outgoing interface list: Null

(204.12.1.254, 224.4.5.6), 00:03:13/00:03:25, flags: FT
Incoming interface: FastEthernet1/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:03:12/00:03:16

BGP preferred path

2009-05-17T21:43:00.000-07:00

In this scenario R3 is advertising network 154.1.5.0/24 to bgp peers R1 and R2. The lab requirement is for AS 300 to be configured so that the link R1 to R3 is the preferred path to reach this network.

In such a scenario there are 2 usual candidates to meet this requirement: as-path prepending and MED. In this scenario as-path pre-pending is not allowed.

So the configuration for MED on R3 is as follows

ip prefix-list VLAN10 permit 154.1.5.0/24
route-map R1 permit 10
match ip address prefix-list VLAN10
set metric 100
route-map R1 permit 20

route-map R2 permit 10
match ip address prefix-list VLAN10
set metric 200
route-map R2 permit 20

router bgp 300
neighbor 154.1.13.1 route-map R1 out
neighbor 154.1.23.2 route-map R2 out

The above was my first configured solution. I examined the bgp routing table on R2 to verify my results:-

R2#s ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i154.1.5.0/24 154.1.13.3 100 100 0 300 400 i
* 154.1.23.3 200 0 300 400 i

As expected R2 had 2 paths to network 154.1.5.0/24. However R2s next hop for both learned routes was R3! I had missed one vital configuration element in terms of meeting the lab requirement. R1s advertisement of 154.1.5.0/24 to R2 was NOT adjusting the next hop. This is the correct beahviour since R1 has an EBGP peer relationship with R3.

To ensure traffic from R2 destined to R3 goes via R1 it is necessary for R1 to adjust the next hop of EBGP learned routes to itself.

R1
router bgp 200
neighbor 192.10.1.2 next-hop-self

Once applied i examined the bgp table on R2 again..

Rack1R2#s ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i154.1.5.0/24 192.10.1.1 100 100 0 300 400 i
* 154.1.23.3 200 0 300 400 i

Now R2s preferred route to reach R3 is via R1. Job done!

srr-queue commands - part IV

2009-05-16T21:55:00.000-07:00

The final part in my look at the srr queues is how DSCP or COS marked packets are assigned to the srr queues.

First the default settings

dscp default values 0-63
0-15 queue 2
16-31 queue 3
32-39, 48-63 queue 4
40-47 queue 1

cos default values 0-7
0,1 queue 2
2,3 queue 3
4,6,7 queue 4
5 queue 1

Within each queue marked packets can be placed in one of three threshold queues. By default all packets are placed in threshold 1. By default threshold 1 has the lowest tolerance to WTD.

The above default settings can all be adjusted depending on the requirements to be met with the following commands

mls qos srr-queue output dscp-map queue {queue-id} threshold {threshold id} {dscp1} ....{dscp8}
mls qos srr-queue output cos-map queue {queue-id} threshold {threshold id} {cos1} ....{cos8}

To ensure higher priority dscp or cos values are not dropped first they can be assigned to a threshold id with a higher value {2 or 3}. By default the higher threshold id values will have a higher tolerance to WTD.

Finally to review assignments use the show mls qos maps command.

Thats it for srr-queues. In my opinion, an absolute beast of a subject. Good to have an understanding of the configurable parameters, but the doc cd will be my friend should this come up.

srr-queue commands - part III

2009-05-15T22:12:00.000-07:00

Before i write about how traffic is allocated to queues, i realised there is another important piece to the srr queue puzzle. Namely how buffers are allocated and managed on the 4 srr queues.

This in itself appears to be a science best approached in a dark room!:-)

Buffers can be set up in advance and mapped to queue set in advance. 2 queue sets are available. An interface is then assigned to a queue set, thus applying the required buffers accordingly. By default an interface uses queue set 2.

An interface is assigned a queue-set as follows
config-if#queue-set 2
or
config-if#queue-set 1

As we know already there are 4 srr queues. A number of values can be set for each of these queues.

1) Buffer allocation
In percentage terms how much of the available interface buffer space is mapped to this queue. Allocation for the 4 srr queues must total 100%.

2) Buffer thresholds - of which there are 4
2 drop WTD (weighted tail drop) thresholds
1 reserved threshold
1 maximum threshold

First buffer allocation
mls qos queue-set {1-2} buffers {%1,%2,%3,%4}

e.g. mls qos queue-set 1 buffers 30 30 30 10
This sets the buffer allocation for srr queue 1 to 30%, queue 2 30%, queue 3 30% and queue 4 10%. N.B. if this command is not used the default allocation is 25% for each queue.

Second buffer thresholds
As mentioned there are 4 thresholds. If none are explicitly set then the following percentage defaults apply to the available buffer space:

queue 1 100 100 50 400
queue 2 200 200 50 400
queue 3 100 100 50 400
queue 4 100 100 50 400

e.g. for queue 1
100 wtd threshold 1
100 wtd threshold 2
50 reserved threshold
400 maximum threshold

So bringing the above alltogether in one example

mls qos queue-set output 1 buffers 30 20 30 20
mls qos queue-set output 1 threshold 1 40 60 100 200
mls qos queue-set output 1 threshold 2 40 60 100 200
mls qos queue-set output 1 threshold 3 40 60 100 200
mls qos queue-set output 1 threshold 4 40 60 100 200
int gi1/1
queue-set 1
i)srr buffer allocation for queues 1-4 is 30%,20%,30% and 20% respectively
ii)the srr queue thresholds are set identically for all 4 queues to 40%,60%,100% and 200%
iii) all the above config is applied to queue set 1, which is then applied to interface gi1/1

As mentioned at the start, when i first looked at this, it appears to be a another science in itself. I know i had to read the cisco doc at least a couple of times to get it straight - or maybe thats just me:-)

srr-queue commands - part II

2009-05-11T21:58:00.000-07:00

In this post i look at the srr-queue shape and share commands, what they do and how they interact.

There are 4 interface queues serviced by SRR. Each queue can be configured for either shaping or sharing, but not both. If shaping is configured then this takes precedence.
( The way i remember this is that shaping comes alphabetically before sharing )

Shaping guarantees a percentage of the bandwidth and limits the traffic to the configured amount. Conversely sharing allocates the bandwidth amongst the sharing queues according to the ratios configured, but does NOT limit it to this level.

Shaped and shared settings are configured using

config-if#srr-queue bandwidth shape {n} {n} {n} {n}
config-if#srr-queue bandwidth share {n} {n} {n} {n}

If the values are not set then the following default values apply

config-if#srr-queue bandwitdh shape 25 0 0 0
config-if#srr-queue bandwitdh share 25 25 25 25

Bandwidth allocation for a 10 mb link can be calculated as follows:-

SHAPED Q
Bandwidth allocated = 1/25 * BW
Hence for a 10 mb interface BW for queue 1 would be 400kbps

SHARED Qs
10mb - 400kps = 9.6 mb
Hence for queue 2,3 and 4 BW = 25/(25+25+25) * 9.6 = 3.2 mb

Supposing a lab requirement was to guarantee queue 1 2 mb, queue 2 2 mb and queue 3 and 4 to share the remainder this could be achieved with the following configuration

config-if#srr-queue bandwitdh shape 5 5 0 0
config-if#srr-queue bandwitdh share 0 0 25 25

In the next post i look at how traffic is mapped to the srr queues.

srr -queue commands - part I

2009-05-09T21:38:00.000-07:00

The lab requirement states that the maximum output usage on fa0/1 should not exceed 75 percent of the maximum line rate.

This can be achieved by making use of the srr-queue bandwidth limit command. For the above requirement to be met configure the following:-

config#interface fa0/1
config-if#srr-queue bandwitdh limit 75

For verification use the

show mls qos int fa0/1 queueing command

N.B. A pre-requisite command is the global config command mls qos.

OSPF routing part XII - filter-list

2009-05-07T22:28:00.000-07:00

Consider the above scenraio where router 2 is an ABR between areas 0,1 and 2. All adjacencies are up and full exchange of routes has taken place.

A new requirement is that area 2 is deemed confidential. Area 1 must not have access to any routes originating from Area 2.

This can be achieved by making using of the ospf filter-list functionality. First a prefix-list must be defined that indicates routes that must be filtered (and allowed!).

R2
ip prefix-list AREA2 deny 150.1.24.0/24
ip prefix-list AREA2 deny 150.1.40.40/32
ip prefix-list AREA2 permit 0.0.0.0/0 le 32

N.B. the last entry in the prefix list is essential to ensure all routes other than the previously denoted denied routes are allowed through.

On router 2 the filter-list can then be applied

R2
router ospf 1
area 1 filter-list prefix AREA2 in

When the routing table on R1 is subsequently examined the 150.1.24.0/24 and 150.1.40.40/32 routes are no longer present. Nice.

OSPF routing part XI - preferred neighbor

2009-05-05T22:19:00.000-07:00

A hub router in an OSPF topology has two neighbors connected over a single serial interface. The hub router is learning the same routes from both neighbors. How can the hub router be configured to prefer routers from a particular neighbor?

The solution to this problem brought to light a configuration parameter that had previously missed my attention. When using the ospf 'neighbor' command a cost can also be applied to routes learned from that neighbor.

Hence to achieve the requirement laid out simply required this parameter to be set accordingly

i.e. below i set a lower cost for neighbor 2. This could be usefull in the scenario where neighbor 2 has a connection with greater bandwidth or reliability.

router ospf 1
neighbor {ip address 1} cost 200
neighbir (ip address 2} cost 100

OSPF routing part X - non broadcast FR

2009-05-05T22:05:00.000-07:00

I recently came across a scenario where the requirement was to run OSPF over a frame-relay network. Normally this would represent a straightforward routing configuration. As ever with the CCIE the interesting part was that no broadcast keywords had been placed on the frame-relay map statements, and none were allowed.

If there are no broadcast capabilities on the underlying network this is not necessarily a problem for OSPF as long as a suitable OSPF non-broadcast network type is chosen.

I set the ospf network type to 'non-broadcast' and then 'point-to-multipoint non-broadcast' and these worked fine as long as the required neighbor statement was configured on the hub router.

Frame Relay Bridging

2009-04-27T21:37:00.000-07:00

VLAN 16 and 22 are broadcast capable segments only. The requirement here is that these two networks are bridged together.

R1
int fa0/0
bridge-group 1

int s2/0
bridge-group 1

int BVI1
ip address 192.10.1.1 255.255.255.0

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

int s2/0
frame-relay map bridge 102 br

R2
int fa0/0
bridge-group 1

int s2/0
bridge-group 1

int BVI1
ip address 192.10.1.2 255.255.255.0

bridge irb
bridge 1 protocol ieee
bridge 1 route ip

int s2/0
frame-relay map bridge 201 br

R1#s frame map
Serial2/0 (up): bridge dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active

R1#p 192.10.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#p 192.10.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/44/68 ms

In the above config i also connect the bridge group to the router via the BVI router interface. Since the bridged segment is logically one segment i put the routable protocol information on the BVI, and its ip address applies to all interfaces in the bridge group. The IOS treats the BVI as any other interface and so enables routing between the bridge group and the routed interfaces in the router.

cisco doc
http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_transprnt_brdg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1004971

Spanning Tree - portfast, bpduguard, bpdufilter

2009-04-25T21:24:00.000-07:00

I use the above diagram to illustrate the interaction between the spanning tree features: portfast, bpdufilter and bpduguard.

For a long time whilst i understood the purpose of these features i did not understand how in particular bpdufilter and bpduguard interacted with each other.
I have at last resolved this confusion by running a wire capture to see for myself exactly what is going on.

First the basics
portfast - moves a port immediately to the forwarding state
bpdufilter - stops a port sending bpdus
bpduguard - error disables a port if bpdus are received

1)
config-if#spanning-tree portfast

Enabling portfast the port moves to forwarding state and from the capture i can see BPDUs still being sent.

2)
config-if#spanning-tree portfast
config-if#spanning-tree bpdufilter

I enable bpdufilter and BPDUS are no longer sent.

3)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard

I enable bpduguard and can see bpdus being sent. I was somewhat surprised by this as i had always treated bpduguard as a more severe version of bpdufilter. i.e. no bpdus sent with the guard feature set - Wrong!!

The enlightening moment for me was the realisation that to enforce no bpdus are sent and bpduguard is on perhaps requires bpdufilter to be enabled alongside bpduguard.

4)
config-if#spanning-tree portfast
config-if#spanning-tree bpduguard
config-if#spanning-tree bpdufilter

With the above commands i observed no bpdus being sent. I had previously assumed these features were mutually exclusive. They are not, they perform different functions and can be used alongside each other.

To observe bpdu guard in action i connected the port to another switchport that was sending bpdus.

I then observed the following...

01:03:26: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/24 with BPDU Guard enabled. Disabling port.
01:03:26: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/24, putting Fa0/24in err-disable state
01:03:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down
01:03:28: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down

Examining the port status

show int status err-disabled
Port Name Status Reason
Fa0/24 err-disabled bpduguard

To ensure auto recovery i entered the following commands

config#errdisable recovery cause bpduguard
config#errdisable recovery interval 30

I then applied bpdufilter to the neighboring switch port sending bpdus and the local port was automatically restored to normal service.

DHCP Snooping

2009-04-24T04:54:00.000-07:00

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It differentiates between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch.

To enable on a switch.

config#ip dhcp snooping
config#ip dhcp snooping vlan {n}
All DHCP servers must be connected to the switch through trusted interfaces. Hence the above config goes hand and hand with

config-if#ip dhcp snooping trust

Once dhcp snooping is enabled on a vlan enabled all ports are treated as untrusted by default.
During the process where a user port acquires an ip address via DHCP the switch builds a database of mac addresses and associated IP. Henceforth when a switch receives a packet on an untrusted interface the switch compares the source MAC address and the address in the DHCP binding database. Normally the addresses match and the switch forwards the packet. Conversely if they dont the switch drops the packet.

N.B. By default a switch inserts and removes DHCP relay information (option-82 field) in forwarded DHCP request messages to the DHCP server. Consequently it is necessary to enter the following command on the router

config-if#ip dhcp relay information trusted

default gateway timing

2009-04-19T22:22:00.000-07:00

I came across a default gateway lab scenario that initially had me stumped. The requirement could be achieved via standard HSRP or VRRP configuration.

So the basic solution making R2 the active default gateway is as follows:

R1:
interface FastEthernet0/0
vrrp 1 ip 130.1.26.1
vrrp 1 preempt

R2:
interface GigabitEthernet0/1
vrrp 1 ip 130.1.26.1
vrrp 1 preempt
vrrp 1 priority 105

The sting in the requirement (and in my experience with CCIE there usually is one) is to ensure that if R2 has relinquished the active default gateway role, is to not allow resumption of the role, until gi0/1 has been up for a minimum of 5 minutes.

My first thought was to adjust the VRRP timers. INCORRECT since the max timer is 255 seconds - not eneough.

R2(config-if)#vrrp 1 timers advertise ?
<1-255> Advertisement interval in seconds

My second thought was introduce a delay on the interface tracking. INCORRECT since the max timer is 180 seconds - not enough

R2(config)#track 1 interface Fastethernet0/0 line-prot
R2(config-track)#delay up ?
<0-180> Seconds to delay

I thought about combining the two features together but this felt a little too convoluted.

After some further investigation i discovered there is a delay parameter on the preempt. This features has a parameter allowing up to 3600 seconds or 1 hour delay.

R2(config-if)#vrrp 1 preempt delay min ?
<0-3600> Seconds to delay

Hence i added the following line to my lab solution

R2(config-if)#vrrp 1 preempt delay min 300

As ever, it was easy, once i knew how:-)

telnet prohibited

2009-04-19T21:58:00.000-07:00

How can you prevent a telnetted user telnetting out to another a router??

Simply:

R1
conf t
line vty 0 4
transport output none

I telnet to router 1 and attempt to open a further telnet session

R1>telnet 160.1.1.2
% telnet connections not permitted from this terminal
Job done!

RMON - Remote Monitoring

2009-04-18T21:49:00.000-07:00

Before i detail the lab scenario a brief overview of RMON:

RMON is an IETF standard developed to enable network management stats to be gathered from remote sites without the overhead of SNMP constantly polling. When RMON is configured it gathers info and passes it back to management nodes. RMON is designed to work in conjunction with SNMP. Typically SNMP is enabled alongside RMON for an effective solution.

Lab scenario:
i) configure R1 to generate an SNMP trap whenever the output queue length (ifEntry.21.2) of its Serial0/0 interface exceeds 250 packets.
ii) This MIB value should be sampled every 30 seconds.
iii) When there are more than 250 packets in the output queue R1 should generate the message “WARNING: S1/0 Congested”.
iv) When the value falls back to 50 R1 should generate the message “INFO: S1/0returned to normal utilization”.
v) R1 should send SNMP traps to is 10.1.1.100 with the community string to be RICHTRAP

With RMON first configure the events and then configure the associated alarms

rmon alarm 1 ifEntry.21.2 60 absolute rising-threshold 250 1 falling-threshold 50 2
rmon event 1 trap IETRAP description "WARNING: S1/0 Congested"
rmon event 2 trap IETRAP description "INFO S1/0 returned to normal utilization"

Then configure the SNMP traps.

snmp-server host 10.1.1.100 IETRAP
snmp-server enable traps

As taken from the cisco doc:
For a host to receive notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.

CBAC - Context Based Access Control

2009-04-17T22:19:00.000-07:00

CBAC performs a similar function to refelexive acls. With CBAC however there’s much more granular control on the type of sessions monitored, along with the allowed session thresholds and timers (see ip inspect ? For types of control allowed).

R1 (trusted) --------- FA0/0 R2 S1/0 ---------- R3 (untrusted)

In this example no inbound tcp sessions are allowed into the protected network however R1 is allowed tcp access out to the untrusted network (R3). A standard blocking acl is applied to the outside interface on R2

access-list 100 deny tcp any any
access-list 100 deny udp any any
access-list 100 permit icmp any any echo-reply
access-list 100 permit eigrp any any
access-list 100 deny ip any any

interface S1/0
ip access-group 100 in

With this config R1 can ping R3 but cannot telnet to it.

I create an inpsection rule to examine all tcp traffic. I apply the inspection rule to interface Ethernet0/0 to inspect traffic from users on the protected network. When CBAC detects tcp traffic from the protected network, CBAC will create a dynamic entry in access list 100 to allow return traffic.

Router_2(config)#ip inspect name RICH tcp
Router_2(config)#int fa0/0
Router_2(config-if)#ip inspect RICH in

Unlike reflexive acls there is no explicit reference required in the acl on the untrusted interface - initially a source of some confusion for me!!! CBAC will add dynamic entries and open up access without it.

With the above config R1 can now initiate a telnet connection to R3

Verification commands on R2

#show ip inspect all
#show access-list 100

Alternatively the inpsect rule can be applied on the untrusted interface in the out direction achieving the same net result.

Router_2(config)#int s1/0
Router_2(config-if)#ip inspect RICH out

Restricting telnet access

2009-04-14T22:42:00.000-07:00

A lab requirement stated 'Allow telnet access to R6 on port 3005 and ensure standard telnet access on port 23 is not allowed'??

To fulfill this requirement requires use of the 'rotary' command on the vty ports.

line vty 0 4
rotary 5

The above enables telnet access on port 3005.

To fulfill the second requirement to restrict access on port 23 can be done via an ACL and access-class command...

ip access-list ext 101
deny tcp any any eq telnet
permit ip any any

line vty 0 4
access-list 101 in

To add an extra twist, a further requirement is added to ensure users entering via vty are prompted for local username and password. No login credentials are required for console access. This can be achieved with the following....

aaa new-model
aaa authentication login default none
aaa authentication login VTY local

line vty 0 4
login authentication VTY

Frame Relay - Load Interval

2009-04-13T22:55:00.000-07:00

Whenever the show interface command is used by default the 5 minute input and output rate is displayed along with the load over this interval

Show interface s2/0
…. output omitted ….
reliability 255/255, txload 2/255, rxload 2/255
…. output omitted ….
5 minute input rate 16000 bits/sec, 18 packets/sec
5 minute output rate 16000 bits/sec, 18 packets/sec
…..output omitted …..

This default behaviour can be changed using the interface command load-interval.

int se2/0
load-interval 30

N.B. The minimum is 30 seconds and can be any multiple of 30 up to 10 mins.

Frame Relay - Broadcast Queue

2009-04-13T22:26:00.000-07:00

The Cisco IOS creates a broadcast queue for interfaces running frame-relay. This queue performs 2 functions: it ensures routing traffic is dealt with as a priority but it also limits the bandwidth that can be consumed by such traffic.

When an interface has many DLCIs the overhead of replicating routing traffic can be significant.

The interface has the following default settings

size: 64 packets
byte-rate: 256000 bytes per second
packet-rate: 36 packets per second

To change the settings the following interface command can be used

frame-relay broadcast-queue {x} {y} {z}

The following example specifies a broadcast queue to hold 80 packets, to have a maximum byte transmission rate of 240000 bytes per second, and to have a maximum packet transmission rate of 160 packets per second:

frame-relay broadcast-queue 80 240000 160

The actual limit in any second is the first rate limit that is reached I.e. byte or packet.

To examine how the broadcast queue is performing simply use the show interface command:-

Rack1R1#show int s2/0
Serial2/0 is up, line protocol is up
{… output omitted …..}
Broadcast queue 0/64, broadcasts sent/dropped 83/0, interface broadcasts 86

BGP - ORF (Outbound Route Filtering)

2009-04-09T22:35:00.001-07:00

The standard method for BGP to filter routes entering the BGP table is to apply prefix-list filtering on incoming updates. For example

R1
ip prefix-list rich permit 10.1.1.0/24
neighbor 1.2.3.4 prefix-list rich in

In the above example R1 will only allow the 10.1.1.0/24 route into its BGP table.

The flaw with the above is that R1 must receive ALL routes from the 1.2.3.4 neighbor. Upon receipt R1 then allows only the required routes to enter the local BGP table. The problem here is that R1 must first receive the whole BGP table advertised by its neighbor.

It is exactly this BGP characteristic that ORF was designed to improve. With ORF enabled on neighboring routers, only the required routes are sent in the first place. Hence link bandwidth and the local routers memory are then spared unnecessary overhead.

An important note i made to myself is that the above config still applies i.e. route filtering is set up exactly as when ORF is not enabled. The required ORF functionality is then simply configured on top of this configuration.

N.B. Running Version 12.3(23) i noticed the config would only take hold if i applied under the address-family ipv4 sub command prompt.

R1
router bgp 200
address-family ipv4
neighbor 1.2.3.4 capability orf prefix-list send

R2
router bgp 100
address-family ipv4
neighbor 4.3.2.1 capability orf prefix-list receive

Once applied i ran debug ip bgp updates and was able to see the router only received the required routes. Before applying the ORF capability i was able to see all routes arriving and then the router denying those not allowed in the prefix-list.

BGP no-prepend and local-as

2009-03-21T23:50:00.000-07:00

The no-prepend and local-as options have been made available to support the 'neighbor a.b.c.d local-as' feature.

Put into my own words the 'local-as' feature allows internal as numbers to be changed, but still allowing partner BGP routers to peer with an old AS number. Hence this enables BGP AS to be changed without affecting partner BGP configuration.

One downstream affect of this is that the by default partnering AS systems still see both old and new as numbers in the path.

With the no-prepend option the 'local-as' number is NOT prepended to downstream BGP neighbors (except for the partner who is peering with the 'local-as' number).

With the 'replace-as' option the real bgp as number is not sent to the BGP partner that peers with the 'local-as'.

I found an excellent article on this at
http://wiki.nil.com/Network_migration_or_merger_with_BGP_Local-AS_feature

Reliable static routing

2009-01-23T23:53:00.000-08:00

Static routing is just that static. If an interface goes down the route remains in the table and potentially black holes traffic.

Reliable static routing gets around this problem by only installing a static route based on the the state of a tracked object. By using this feature static routes in effect become dynamic!

R1 --------------- R3

On R1 I reate an sla monitor to track the reachability of the loopback on R3

ip sla monitor 1
type echo protocol ipIcmpEcho 3.3.3.3
timeout 900
frequency 1
ip sla monitor schedule 1 life forever start-time now

I then create a tacking object

track 1 rtr 1

Router_1#s track
Track 1
Response Time Reporter 1 state
State is Up
5 changes, last change 00:00:02
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
STATIC-IP-ROUTING 0

I then create a reliable static route based on the status of the tracked object 1

ip route 5.5.5.5 255.255.255.255 10.0.0.3 55 track 1

The route only remains in the routing table as long as the loopback on R3 remains reachable.

Nice.

Configuring Voice VLAN

2009-01-21T22:36:00.000-08:00

Before enabling a voice VLAN, CISCO recommand that QoS is enabled (by entering the mls qos command) and the port trust state is set on the interface(by entering the mls qos trust cos command).

You can configure a port to carry voice traffic in one of 2 ways:

•Configure the port to carry Voice Traffic in IEEE 802.1Q Frames
or
•Configure the port to carry Voice Traffic in IEEE 802.1p Priority-Tagged Frames

DOT1Q
To configure a port to carry voice traffic in IEEE 802.1Q frames for a specific VLAN.

mls qos
Interface Fa0/X
mls qos trust cos
switchport access vlan X
switchport voice vlan Y (Tells the phone to use a dot1q header for VLAN Y)

n.b. The voice VLAN should be present and active on the switch when using its own vlan.

DOT1P
To configure a port to instruct the IP phone to carry traffic through the native data vlan.

mls qos
interface Fa0/X
mls qos trust cos
switchport access vlan X
switchport voice vlan dot1p (Tells the phone to use native data vlan)

By default voice traffic is sent with a cos value of 5 and data traffic with a cos value of 0.

Use the following commands to instruct the phone to change the cos value of data packets.

mls qos trust device cisco-phone
switchport priority extended cos 1 (Tells phone to set data traffic with cos 1)

HSRP - Tracking

2009-01-18T22:54:00.000-08:00

In my experience it would be useful to track an end to end connection, rather than the local serial connection (which may not go down when e2e connectivity is lost).

In the above diagram R1 should be the active HSRP router as long as it maintains its frame relay connection to R3. The trouble here is that the serial connection on R1 will remain 'up' even if the serial connection on R3 goes down.

One way around this is to configure a tunnel connection between R1 and R3 and run IP keepalives over this. Then with the HSRP configuration track the status of the tunnel connection. In this instance the tunnel connection goes down when the end to end connection over the frame relay cloud goes down.

R3
int tu0
ip unnumber lo0
tunnel source 149.1.123.3
tunnel dest 148.1.123.1
keepalives 10 3

R1
int tu0
ip unnumber lo0
tunnel source 149.1.123.1
tunnel dest 148.1.123.3
keepalives 10 3

int fa0/0
standby ip 149.1.127.254
standby priority 110
standby preempt
standby track tu0 11

R2
int fa0/0
standby ip 149.1.127.254
standby priority 100
standby preempt

banner tokens

2009-01-18T12:08:00.000-08:00

There are the 3 banner commands: motd, login and exec. motd is displayed upon arriving at the router, login when prompted for login, and exec when arriving at the exec prompt. Pretty self explanatory.

Commands to enter the banners are
i) banner motd
ii) banner login
iii) banner exec

The message is then delimited by the control character of your choice.

However did you know there are a few dynamic messages or 'tokens' that can be added to the message!

$(hostname) Displays the host name for the router.

$(domain) Displays the domain name for the router.

$(line) Displays the vty or tty (asynchronous) line number.

$(line-desc) Displays the description attached to the line.

By way of an example
Router_1(config)#banner login @
Enter TEXT message. End with the character '@'.
you are on router $(hostname)
@

So telnetting onto the router, the output is as follows :

Router_1>1.1.1.1
Trying 1.1.1.1 ... Open

you are on router Router_1

User Access Verification

Password:

Multicast - Auto RP Filtering

2009-01-17T21:50:00.000-08:00

In this post i detail auto rp filtering. This can be done by the mapping agent in the auto rp domain.

I had some difficulty getting this feature to work as required. In essence the concept is simple: the mapping agent denotes which RPs are allowed to advertise which multicast groups. However i discovered there are some limitations around how this works.

Consider the following

R1 -------- R2 -------- R3

R1 is the rp for groups 230.0.0.0/8 and 231.0.0.0/8

R2 is the mapping agent

R3 is the router initiating pings to the multicast groups.

In the above situation the requirement is for the mapping agent to allow R1 to be the RP for 231.0.0.0/8 and NOT 230.0.0.0/8. The config might be applied as follows

R1
int lo0
ip address 1.1.1.1 255.255.255.0
access-list 1 permit 230.0.0.0 1.255.255.255
ip pim autorp listener
ip pim send-rp-announce lo0 scope 16 group-list 1

R2
access-list 1 permit 1.1.1.1
access-list 2 permit 231.0.0.0 0.255.255.255
ip pim autorp listener
ip pim send-rp-discovery lo0 scope 16
ip pim rp-announce-filter rp-list 1 group-list 2

R3
ip pim autorp listener

I applied the above config and tried a ping from R3 to both multicast groups. To my surprise i was not able to ping either group!

Some research and head scratching later i realised that R2 was filtering both multicast groups from R1. The reason for this is that R1 is advertising itself as the RP for these groups in 1 ACL statement. If the mapping agent blocks any group within this advertised ACL ALL groups within this advertised space are denied.

In summary the mapping agent can only filter based on the same granularity as the multicast groups are advertised by the RP.

Hence to achieve the requirement in the above scenario R1 must first advertise itself as the RP for these multicast groups seperately.

If i change the config on R1 to the following then all is well.

R1
access-list 1 permit 230.0.0.0 0.255.255.255
access-list 1 permit 231.0.0.0 0.255.255.255

Router_3#p 231.31.31.31 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 231.31.31.31, timeout is 2 seconds:

Reply to request 0 from 142.1.13.1, 96 ms
Reply to request 1 from 142.1.13.1, 156 ms
Reply to request 2 from 142.1.13.1, 168 ms
Router_3#p 230.30.30.30 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 230.30.30.30, timeout is 2 seconds:
...

Note to myself: Watch out for this feature/anomoly:-)

Narrowing an acl

2009-01-17T11:16:00.000-08:00

By narrowing an acl i mean delimit traffic in the mimimal number of acl lines.

As an example consider the following addresses, and express as a 1 line acl!!

200.0.1.2
200.0.3.2
200.0.3.10
200.0.1.18
200.0.3.26
200.0.1.10
200.0.3.18
200.0.1.26

To break down consider the varibale portions of the acl in bit notation.
Then decide which bits can be either a zero or one without allowing any further traffic address combinations through the filter.

3rd Oct 4th Oct
200.0.1.2 0000 0001 0000 0010
200.0.3.2 0000 0011 0000 0010
200.0.3.10 0000 0011 0000 1010
200.0.1.18 0000 0001 0001 0010
200.0.3.26 0000 0011 0001 1010
200.0.1.10 0000 0001 0000 1010
200.0.3.18 0000 0011 0001 0010
200.0.1.26 0000 0001 0001 1010

0000 00*1 000* *010

Hence the one line acl can be represented as follows....

permit 200.0.1.2 0.0.2.24

Multicast - BSR

2009-01-15T22:54:00.000-08:00

I recently came across a lab scenario where 3 routers were operating in PIM Sparse mode. The question stated that an interface on one router should join a multicast group and all other routers should be able to ping this address.

The sting in the tail was that the configuration must be achieved on only 1 router and the 'ip pim autorp listener' command could NOT be used.

The obvious answer would have been to have configured auto rp. However a pre-requisite for this to work in a PIM sparse mode environment would be for the 'ip pim autorp listener' command to be configured on all routers in the domain.

The way around this problem is to configure BSR (bootstrap routing). This can operate in sparse mode without the 'autorp listener' prerequisite.

Therefore on one of the routers the place the following configuration

ip pim rp-candidate lo0
ip pim bsr-candidate lo0

MRM - Multicast Routing Monitor

2009-01-11T03:49:00.000-08:00

A tool designed to notify network admin of any multicast routing problems.

There are 3 components to MRM
-Manager
-Sender
-Receiver

The configuration is laid out on the doc cd under 'Using IP Multicast Tools'(well apart from the fact it neglects to inform you how to start the test!)

I implement MRM on the same topology used in the previous MSDP post.

The test sender is on R1

R1
int s1/0
ip mrm test-sender

R2
access-list 1 permit 10.0.0.1
access-list 2 permit 150.50.5.69
ip mrm manager test1
manager fa0/0 group 239.1.1.1
senders 1
receivers 2 sender-list 1

R4
int s1/0
ip mrm test-receiver

And so to the crucial piece of config NOT on the doc cd.
On R2 the manager

mrm test1 start

PGM - Pragmatic General Multicast.

2009-01-11T03:43:00.000-08:00

PGM is a reliable multicast transport protocol. It guarantees that a receiver in a multicast group receives all data packets (in comparison to normal multicast which is a best effort protocol).

Configuration is very straightforward.

config-if#ip pgm router

Thats it!

MSDP - Multicast Source Discovery Protocol

2009-01-10T23:58:00.000-08:00

Consider the above scenario where there are two separate Multicast domains. In the left hand side domain the RP is statically configured as 22.22.22.22. On the right hand side domain the RP is statically configured as 33.33.33.33

On the left the workstation has joined multicast group 224.99.99.99
From R2
Router_2#p 224.99.99.99

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 120 ms

On the right the workstation has joined multicast group 225.0.0.1
Router_3#p 225.0.0.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 150.50.5.69, 80 ms

Now I join the two multicast domains using MSDP. The MSDP configuration reminds me of BGP neighbor configuration.

R2
ip msdp peer 3.3.3.3 connect-source Loopback0

R3
ip msdp peer 2.2.2.2 connect-source Loopback0
Router_2#s ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
3.3.3.3 ? Up 00:00:17 2 0 ?

Router_3#show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
2.2.2.2 ? Up 00:00:08 2 0 ?
Router_3#

Now to test the power of MSDP!! From R3 on the right hand side of the multicast domain I try and ping the host on the left hand side of the multicast domain that is a member of 224.99.99.99

Router_3#p 224.99.99.99

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 232 ms

Success!!!!

From R2 on the left hand side of the multicast domain I try and ping the host on the left hand side of the multicast domain that is a member of 225.0.0.1

Router_2#p 225.0.0.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 150.50.5.69, 208 ms

Success!!!

Now to take things one step further and introduce MSDP Anycast. MSDP Anycast in the words of CISCO is ‘an intradomain feature that provides redundancy and load-sharing capabilities’. In my own words this features allows two separate Multicast domains to be configured with RPs sharing the same ip address. Should the RP in one domain become unavailable then the RP in the other domain transparently takes over.

In the given scenario I change the RP on the right hand side to share the same ip address (22.22.22.22) as the left hand side domain.

From R3 I can still ping both multicast hosts. To test the redundancy I take down the loopback interface on R3 that has the RP address.

Router_3(config)#int lo1
Router_3(config-if)#shut

I now check I can still ping the muticast host on the left hand side (even though there is actually no active RP in the original right hand side multicast domain).

Router_3#p 224.99.99.99

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 276 ms

Success!!

Multicast - Bidirectional

2009-01-09T23:38:00.000-08:00

Bidir PIM is designed for multicast apps that have a many to many architecture (as opposed to the typical one to many architecture of traditional multicast).

Configuring Bidir PIM is very similar to traditional PIM. To enable bidir-PIM on a router

Config#ip pim bidir-enable

And for the RPS just use the normal rp selection commands with the addition of the bidir option

STATIC RP: Ip pim rp-address {address} bidir
AUTO RP: Ip pim send-rp-announce (interface} scope {ttl} bidir
BOOTSTRAP RP: Ip pim rp-candidate {interface} bidiR

Use the same pim verification commands used for standard pim.

Multicast Routing - Misc

2009-01-09T22:57:00.000-08:00

In this post i detail some of the plethora of multicast commands that may be of use...

config-if#ip igmp access-group {acl}

interface command that delimits the multicast groups that the hosts are allowed to join.

config-if#ip igmp limit {n}
interface command that limits the number of groups that users on an interface may join

config-if#ip igmp join-group
joins multicast group with process switching

config-if#ip igmp static-group
joins multicast group with fast switching

ip pim spt-threshold {n}
specifies the threshold that must be reached before moving to the spt

ip multicast rate-limit in out group-list {x} {y}
Controls transmission rate TO a multicast group
where x is the acl matches the multicast groups
where y is the bandwidth statement

ip multicast-boundary
Implements a bidirectional boundary for multicast traffic
The following example shows how to set up a boundary for all administratively scoped addresses:

access-list 1 deny 239.0.0.0 0.255.255.255
access-list 1 permit 224.0.0.0 15.255.255.255
interface ethernet 0
ip multicast boundary 1

ip multicast cache-headers
Enables history of multicast traffic through the router.
Can be viewed with show ip mpacket

Router_2#s ip mpacket
IP Multicast Header Cache
11 packets received over 00:00:24, cache size: 1024 entries
Key: id/ttl timestamp (name) source group

0015/254 180.476 (?) 1.1.1.1 225.0.0.1
0071/15 181.336 (?) 5.5.5.5 224.0.1.39
0016/254 182.472 (?) 1.1.1.1 225.0.0.1

SSM - Source Specific Multicast

2009-01-09T22:48:00.000-08:00

A few key notes after reviewing the cisco doc cd...

Requires IGMP version 3

Reserved IANA range 232.0.0.0 232.255.255.255

Operates in PIM sparse mode or sparse dense mode

Enabled by ip pim ssm global command

When enabled PIM operations in the SSM address range are treated as PIM SSM.

Ip pim ssm
Int x
Ip pim sparse-mode | ip pim sparse-dense-mode
Ip igmp version 3

Enabling PIM SSM may cause problems for legacy PIM operations in the reserved SSM address range. The following config enables RP to restrict sources in the SSM range from registering

ip pim accept-register list no-ssm-range
ip access-list extended no-ssm-range
deny ip any 232.0.0.0 0.255.255.255
permit ip any any

Multicast Routing - Part V Tunnel

2009-01-08T22:52:00.000-08:00

The Multicast tunnel is a feature that can be used to join two multicast routers seperated by a 'non multicast' region.

In the above scenario i create a tunnel between the 2 multicast routers as follows...

R2
interface Tunnel0
ip address 20.20.20.2 255.255.255.252
ip pim sparse-dense-mode
tunnel source Loopback0
tunnel destination 5.5.5.5
ip pim send-rp-announce Loopback0 scope 16
ip pim send-rp-discovery scope 16

R5
interface Tunnel0
ip address 20.20.20.1 255.255.255.252
ip pim sparse-dense-mode
tunnel source Loopback0
tunnel destination 2.2.2.2
end
ip pim send-rp-announce Loopback0 scope 16

The dest pc joins mcast group 225.0.0.1

I then try pinging across the tunnel from the source PC.

Router_2#p 225.0.0.1 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:
...

Failure!!!

If i enable multicast debugging on R5 the reason becomes clear

debug ip mapcket
Router_5#
*Jan 9 07:03:40.263: IP(0): s=2.2.2.2 (Tunnel0) d=225.0.0.1 id=19, ttl=254, pro
t=1, len=100(100), RPF lookup failed for source or RP
*Jan 9 07:03:40.275: IP(0): s=2.2.2.2 (Tunnel0) d=225.0.0.1 id=19, ttl=253, pro
t=1, len=100(100), RPF lookup failed for source or RP

Whilst the multicast regions are now successfully joined the multicast route now differs from the unicast route. As indicated in the debug the reverse path check is now failing i.e. the path back to the multicast source does NOT match the unicast path to the source.

To resolve this issue i configure a static multicast route on R5 so that all multicast traffic is directed through the tunnel

Router_5(config)#ip mroute 0.0.0.0 0.0.0.0 tu0

I now ping again from R2 and success!!

Router_2#p 225.0.0.1 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 14.0.0.6, 484 ms
Reply to request 0 from 14.0.0.6, 484 ms
Reply to request 1 from 14.0.0.6, 180 ms
Reply to request 1 from 14.0.0.6, 180 ms
Reply to request 2 from 14.0.0.6, 296 ms
Reply to request 2 from 14.0.0.6, 308 ms

OSPF routing part IX - distance

2009-01-08T21:24:00.000-08:00

Suppose R1 has two ospf neighbors R2 and R3 and the lab requires all routes to be preferred from R2. This can be achieved by marking all routes from ospf neighbor R3 with an admin distance of 109 (compared to the default of 110).

If the ospf router id of r3 was 3.3.3.3 this can simply be achieved as follows...

ip access-list st 1
permit any

router ospf 1
distance 109 3.3.3.3 0.0.0.0 1

Director Response Protocol

2009-01-05T22:50:00.000-08:00

As far as i can tell this is one of those oddball subjects that just may rear its head on the CCIE Lab.

In this post i just denote
i) what is it
ii) where to find it on the doc cd
iii) provide a basic config.

Director Response Protocol.
This is a CISCO proprietary product. The DRP server agent is used to communicate with the Distributed Director platform. As a requirement in a lab i guess configuration of the server agent is a possibility.

On the doc cd look in 12.2 IP Configuration Guide. Then under Configuring IP Services. There is a reasonable description on configuring the server agent there.

The only configuration that is required to enable DRP is the global configuration
command 'ip drp server'. Over and above that the DRP server agent can then be configured to only allow certain Directors to communicate with it.

access-list 10 permit 185.28.8.1
access-list 10 permit 104.12.8.1

ip drp access-group 10

Additionally some authentication can be included between server agent and directors

key chain RICH
key 1
key-string CISCO
!
ip drp authentication key-chain RICH

I must confess the DRP still reamins a bit of a 'black box' subject to me, but i figure the above will be enough to cover off the basics.

NTP Broadcast Setup

2009-01-05T11:57:00.000-08:00

Most of the scenarios i have encountered with NTP involve setting up NTP relationships with the 'ntp server' or 'ntp peer' commands. In this post i am not going to detail this setup.

An interesting scenario i came across was when the lab requirement was to establish NTP in an environment but WITHOUT using the 'ntp peer' or 'ntp server' commands.

To enable this requires use of NTP in a broadcast mode. The config for this is straightforward (as always if you know the answer:-})

R1
config-if#ntp broadcast client

R2
config-if#ntp broadcast

Thats it!

As with standard udp NTP the setup can be verified via 'show ntp associations'.

Frame Relay Traffic Shaping - Part III

2009-01-04T07:43:00.000-08:00

A short post just to clarify a couple of frame relay traffic shaping features...

The minimum time slice on a Frame Relay interface is 10ms or 1/100 of a second. Hence to set the time slice on the interface to be the minimum, simply divide the CIR by 100.

As a further note....If there is a requirement to ensure that a single packet cannot take more than one interval to be transmitted, divide the bc by 8 to get the number of bytes and then set the fragment size to this. For example

map-class frame-relay DLCI_304
frame-relay cir 256000
frame-relay bc 2560
frame-relay fragment 320

Multicast Routing - Part III Controlling Access Part 2

2009-01-03T23:47:00.000-08:00

In my fist post on controlling multicast access i described the 'ip igmp access-group' command.

As denoted this can be usefull controlling access to specified multicast address spaces. On a further lab i encountered a multicast access scenario that required multicast traffic to be restricted in both directions i.e. not only prevent multicast feeds being accepted from an interface, but also prevent multicast feeds being sent out an interface.

In such a situation where multicast access control is required in both directions then the 'multicast boundary' functionality can be used. This creates more stringent access control.

Access can be controlled in a granular fashion by utilising the access-list parameter.

For example...use this to prevent access to the administratively scoped address space

Router(config-if)# ip multicast boundary 1
Router(config)# access-list 1 deny 239.0.0.0 0.255.255.255
Router(config)# access-list 1 permit 224.0.0.0 15.255.255.255

Whilst researching on multicast boudaries i then realised there was a 3rd option to control multicast access:-)...

The 'ip igmp access-group' command works perfectly for L3 interfaces. However if required to restrict access on a L2 interface this command will NOT cut the mustard.

This is where 'igmp profiles' can be used on an L2 access port.

int f0/01
switchport mode access
switchport access vlan 7
ip igmp filter 1
!
ip igmp profile 1
deny
range 239.0.0.0 239.255.255.255

BGP snippets

2009-01-02T23:33:00.000-08:00

BGP Default Router

R1 -------- R2

In this scenario R1 must advertise a BGP default route to R2. NO other BGP routes are allowed.

R1

router bgp 1
neighbor {a.b.c.d} default-originate
neighbor {a.b.c.d} prefix-list DEFAULT out

ip prefix-list DEFAULT permit 0.0.0.0/0

BGP - NON transit area

How do you ensure a BGP area is not used as a tranit area? One answer is to ensure it only advertises routes originated in it own area.

ip as-path access-list 1 permit ^$
router bgp 1
neighbor {a.b.c.d} filter-list 1 out

Redistribution from BGP

router ospf 1
redistribute bgp 1

With the statement above all BGP EXTERNAL routes will be propogatedinto OSPF. If there is a requirement for BGP internal routes to be propogated into OSPF then the following command is required under at BGP router prompt.

router bgp 1
bgp redistribute-internal

Redistribution of a single BGP area

If redistribution from BGP is required but only from a single BGP area this can be achieved via a route-map in conjunction with an as-path access-list.

router ospf 1
redistribute bgp 1 route-map BGP2OSPF
!
ip as-path access-list 1 permit _54_
!
route-map BGP2OSPF permit 10
match as-path 1

thats it:-)

OSPF Routing Problem

2009-01-02T06:31:00.000-08:00

Consider the following scenario.

Router 1 is sending a lot of traffic to the 164.1.5.0 subnet on Router 2. The preferred route (by default) is via R3 as this is an Intra-Area Route. The route between R1 and R2 is an Inter Area route so will NOT be considered for the traffic flow - this is regardless of the metric cost value.

The question is how to get R1 to prefer the direct, faster route to R2! As mentioned altering the route cost will have NO bearing, as Intra vs Inter are considered above such comparisons. Intra Area routes always win regardless of costs.

The way around this problem is to build a virtual link between R1 and R2. This way once up, the route to 164.1.5.0 will beomce preferrable.

Router 4
router ospf 100
area 1 virtual-link 5 150.1.5.5

Router 5
router ospf 100
area 1 vitual-link 150.1.4.4

EIGRP metric calculation

2009-01-01T23:21:00.000-08:00

If the standard bandwidth and delay parameters are used within EIGRP the formula for calculating the metric is as follows...

(10,000,000/bw(kbit) + delay/10) * 256

As an example examine the following entry from the eigrp topology table.

Router_1#s ip eigrp top 164.1.26.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2684416
Routing Descriptor Blocks:
164.1.13.3 (Serial2/1), from 164.1.13.3, Send flag is 0x0
Composite metric is (3026432/2514432), Route is Internal
Vector metric:
Minimum bandwidth is 1280 Kbit
Total delay is 40100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2

Using the formula....

(10,000,000/1280 + 40100/10) * 256 = (7812.5 + 4010) * 256
= 11822 * 256
= 3026432!!

N.B. Before moving figures outside of brackets truncate (not round) the figure to 0 decimal places.

Understanding this metric calculation may seem a bit like overkill - it did to me! However it could feasibly come into play if a question asked for EIGRP load balancing to be performed according to a certain ratio. In this instance it may be necessary to adjust the EIGRP metric to achieve the desired balancing.

NAT Load Balancing

2008-12-31T02:57:00.000-08:00

As an added feature of NAT it can be used to load balance a ‘serverfarm’. The router performing the natting can round robin connection requests to the real servers.

A virtual server address is required. The natting router takes tcp requests received on this address, and the specified ports, and passes them on in a rotary fashion to the servers.

This can be achieved with the following configuration on R2…..

interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat outside
!
interface FastEthernet1/0
ip address 11.0.0.2 255.255.255.0
ip nat inside

ip nat pool REALS 11.0.0.3 11.0.0.4 prefix-length 24 type rotary
ip nat inside destination list VIPACCESS pool REALS
!
ip access-list extended VIPACCESS
permit tcp any host 11.0.0.254 eq telnet

Now when telnetting to 11.0.0.254 from R1, R2 redirects the request to one of the 3 real server addresses

Router_1#telnet 11.0.0.254Trying 11.0.0.254 ... Open
Router_4>

On R2 i examine the nat translation table

Router_2#s ip nat trans

Pro Inside global Inside local Outside local Outside globaltcp 11.0.0.254:23 11.0.0.4:23 10.0.0.1:16630 10.0.0.1:16630

Multicast Gotchas

2008-12-29T08:18:00.001-08:00

I have listed a few gotchas that i have come across when configuring IP multicast.....

Multicast on a hub-and-spoke frame-relay network.

A multipoint interface won't, by default, send multicast received from one spoke out to another spoke. This doesn't apply to a 'hub-and-spoke' where the hub is using separate physical or virtual interfaces, just multipoint interfaces. For sparse traffic this can be fixed by applying 'ip pim nbma-mode' to the multipoint interface. For dense traffic, you can use a PIM-enabled tunnel between the spokes to fix this. To use the tunnel an mroute pointing to the tunnel is required, to ensure the RPF check does not fail.

Consider the above topology where R1, R2 and R3 are all enabled with ip pim dense-mode on the serial interfaces. R1 has joined multicast group 226.1.1.1. R2 is able to successfully ping this address but from R3 this fails.

To circumvent this problem the following tunnel configuration can be applied...

R1
interface Tunnel1
ip address 148.1.1.1 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.3.3

ip mroute 0.0.0.0 0.0.0.0 Tunnel1

R3
interface Tunnel1
ip address 148.1.1.2 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.1.1

RPF Checks

If multicast traffic is required to take a path which unicast wouldn't, then the recieving router will likely drop the traffic because it fails the RPF check. This is typically fixed by applying an mroute.

Using Auto-RP in Sparse Mode
It was my misconception until recently that Auto RP operates in sparse-dense mode only. In fact in can operate in sparse mode as long as routers are configured with ip pim autorp listener command.

IPV6 6to4 tunnels

2008-12-28T05:58:00.000-08:00

A IPV6 tunnelling method that can be used in a one to many environment (as opposed to point to point tunnelling). To configure it all that's required is
1) a tunnel interface given a special IPV6 address with an embedded IPV4 interface address.
2002:{first 2 octects ipv4 address}:{second 2 octects of ipv4 address}:...
2) an ipv6 static route '2002::/16 tu0'

The CISCO IOS works its magic to nail up connectivity to the other tunnel end points.

interface Tunnel0
no ip address
no ip redirects
ipv6 address 2002:101:101:134::1/64
tunnel source Loopback0
tunnel mode ipv6ip 6to4

interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
ipv6 route 2002::/16 Tunnel0

interface Loopback1
no ip address
ipv6 address 2002:1::1/64

All thats required to connect IPV6 address spaces over the tunnel is to implement IPV6 routing over the tunnel

e.g.

R1
ipv6 route 2002:3::/64 2002:303:303:134::3

Router_1#PING 2002:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/97/152 ms
Router_1#

Regular Expression Special Characters

2008-12-26T23:05:00.000-08:00

As a reminder to my self, the regular expression special characters.

Character Meaning
^ Start of string
$ End of string
[] Range of characters
- Used to specify range ( i.e. [0-9] )
( ) Logical grouping
. Any single character
* Zero or more instances
+ One or more instance
? Zero or one instance
_ start or end of string, or space

Examples (ive only scratched the surface here!)

Only allow routes originated by as 54
ip as-path access-list 1 permit _54$
ip as-path access-list 1 deny .*

Only allow routes from as 54 and directly connected peer AS,s
ip as-path access-list 1 permit ^54_([0-9]+)?$
ip as-path access-list deny .*

A great way to test regular expression is via the command
show ip bgp regexp {expression}

N.B. to enable a ? to be entered in a command line precede with ctrl-V.

Mark and Police

2008-12-24T03:38:00.000-08:00

In this post i bring together a number of QOS features to implement an end to end QOS marking and policing scenario.

On R2 i mark all traffic destined to UDP port 3333 with an IP precednce of 3. On R3 i ensure all traffic with an IP precednce of 3 utilises no more than 100,000 bps of the bandwidth between R3 and R4.

In order to test this scenario i make use of the IP SLA feature. R1 generates the traffic to the loopback 0 on R4 with a UDP dest port of 3333. On R4 i configure an IP SLA responder to ensure these packets are answered.

Here is the config i used....

R1
ip sla monitor 1
type udpEcho dest-ipaddr 99.99.99.99 dest-port 3333
request-data-size 1500
timeout 2000
frequency 15
ip sla monitor schedule 1 life forever start-time now

R2

access-list 100 permit udp any any eq 3333

class-map match-all SLA
match access-group 100

policy-map MARK
class SLA
set precedence 3

interface FastEthernet1/0
service-policy output MARK

R3
access-list rate-limit 1 mask 08

interface FastEthernet1/0
rate-limit output access-group rate-limit 1 100000 18750 37500 conform-action transmit exceed-action drop

R4
ip sla monitor responder type udpEcho ipaddress 99.99.99.99 port 3333

For verification i used the following commands on each of the routers

R1
s ip sla monitor stat
Round trip time (RTT) Index 1
Latest RTT: 160 ms
Latest operation start time: *06:04:24.763 UTC Thu Dec 25 2008
Latest operation return code: OK
Number of successes: 152
Number of failures: 24
Operation time to live: Forever

R2
s policy-map int fa1/0
FastEthernet1/0

Service-policy output: MARK

Class-map: SLA (match-all)
296 packets, 233248 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group 100
QoS Set
precedence 3
Packets marked 296

Class-map: class-default (match-any)
451 packets, 38519 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

R3
#s int fa1/0 rate-limit
FastEthernet1/0
Output
matches: access-group rate-limit 1
params: 96000 bps, 18750 limit, 37500 extended limit
conformed 100 packets, 78800 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 7788ms ago, current burst: 14 bytes
last cleared 00:12:48 ago, conformed 0 bps, exceeded 0 bps

R4
show ip sla monitor responder
IP SLA Monitor Responder is: Enabled
Number of control message received: 4 Number of errors: 0
Recent sources:
10.0.0.1 [06:10:24.379 UTC Thu Dec 25 2008]
10.0.0.1 [06:10:09.391 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:54.395 UTC Thu Dec 25 2008]
10.0.0.1 [06:09:39.371 UTC Thu Dec 25 2008]
Recent error sources:

udpEcho Responder:
IP Address Port
99.99.99.99 3333

It works! :-)

Policing: MQC vs Rate Limiting

2008-12-23T21:56:00.000-08:00

Suppose the lab requirement is to restrict traffic with IP precedence 3,4 and 5 to a max throughput of 500,000 mps. As ever with the CCIE there is more than one method to crack this nut. I guess it depends on your preferred method versus what the actual requirements and restrictions of the task are.

My personal preference would be to use MQC. The above requirement could be achieved as follows.....

ip access-list extended 101
permit ip any any prec 3
permit ip any any prec 4
permit ip any any prec 5

class-map PREC345
match access-group 101

policy-map POLICE
class PREC345
police 500000 93750 187500 conform-action transmit exceed-action drop

int fa0/0
service-policy output POLICE

For verification use the 'show policy-map int fa0/0' command.

Another method of achieving the same result is to use the older rate-limit command.....

rate-limit output access-group 101 496000 93750 187500 conform-action transmit exceed- action drop

There is a 3rd method of achieving the above. This is another variation on the rate-limit command. If the lab requirement specified the solution must be achieved using an ACL with only 1 line this may be one scenario where such a solution would come to the rescue.

There is a special access-list type named 'rate-limit'. This allows traffic to be selected based on MAC address, precedence or MPLS markings.

Router_2(config)#access-list rate-limit ?
<0-99> Precedence ACL index
<100-199> MAC address ACL index
<200-299> mpls exp ACL index

The requirement here is to use IP precedence 3,4 and 5.

access-list rate-limit 0 ?
Router_2(config)#access-list rate-limit 0 ?
<0-7> Precedence
mask Use precedence bitmask

As with an ACL only 1 precedence value can be configured per line. To allow multiple precedence values to be configured with one 'hit' requires the use of the mask option.

To make use of this the coding of the precedence values needs to first be recalled...

IP Precedence 0 = 00000001
IP Precedence 1 = 00000010
IP Precedence 2 = 00000100
IP Precedence 3 = 00001000
IP Precedence 4 = 00010000
IP Precedence 5 = 00100000
IP Precedence 6 = 01000000
IP Precedence 7 = 10000000

A packet with ip precedence of either 3,4 or 5 can be matched with bit pattern 00111000. The mask parameter expects this bit pattern in 2 HEX digits, so this has the equivalent value 38. (Note.. this is the 2 byte HEX equivalent and not the HEX value of the full byte which would be 56!!).

So bringing this all together the 1 line solution to the question would be

rate-limit output access-group rate-limit 0 1000000 93750 187500 conform-action
transmit exceed-action drop

Verification with rate-limiting can be done with 'show int fa0/0 rate-limit'

vlan filter

2008-12-23T00:11:00.001-08:00

Consider the following scenario where routers 1,2 and 3 are connected on a common LAN segment. All routers are in a common RIP domain.

The requirement is for Routers 2 and 3 to not accept ANY routes from R1 WITHOUT changing the config on R2 and R3!

A solution here is to use a vlan filter on the intermediate switch.
My first attempt was to apply the following (incorrect) configuration.

access-list 1 permit 224.0.0.9

vlan access-map DROP_RIP permit 10
match ip address 1
action drop
vlan access-map DROP_RIP permit 20

vlan filter DROP_RIP vlan 232

With the above config ALL RIP neighbor adjacencies were lost!!! The problem was the access list i had used. A more targetted ACL is required to only drop RIP traffic from Router 1.

The following ACL achieves the requirement.

access-list 100 permit udp host 192.10.1.254 any eq rip

This question also got me thinking on how it would be possible to block other routing protocols of the switch.

The equivalent access list entries for EIGRP, OSPF and BGP are as follows......

Extended IP access list 100
20 permit eigrp host 50.0.0.254 any
30 permit ospf host 50.0.0.254 any
40 permit tcp host 50.0.0.254 any eq bgp

50 permit tcp host 50.0.0.254 eq bgp any

RIP - Versions 1 and 2

2008-12-22T22:20:00.000-08:00

Most RIP scenarios these days are based on version 2. That is RIP updates are multicast to ip address 224.0.0.9. In RIP version 1 updates are broadcast to 255.255.255.255.

By default RIP sends updates in version 1 but is capable of receiving up dates in version 1 and 2.

When the 'version 2' command is entered at the router config prompt RIP only then sends and receives in version 2.

If a requirement arises where another router requires version 1 updates, whilst not changing the version 2 operation of the router, this poses a problem. This can be overcome by manipulating the sent and received RIP version on an interface level. This overrides the config router commands.

Here i enable the router to send rip version 1 and 2 updates out of interface fa1/0.

int fa1/0
ip rip send version 1 2

Use the show ip protocol command for verification.

FRTS versus MQC FRTS - Part II

2008-12-18T22:41:00.000-08:00

Following on from part I i know introduce a further requirement to set the frame-relay discard eligibility bit on all non critical frames (non DSCP 5).

For consistency i apply this on R4 using traditional FRTS on R4 and then using MQC FRTS on R5.

R4

1) i create a new class DSCP5 matching the critical traffic
2) I create a policy-map FR_405 that only sets the de bit for the non-critical frames
3) Finally within the pre-existing frame-relay map-class RICH i reference the new policy-map.

class-map match-all DSCP5
match dscp cs5

policy-map FR_405
class DSCP5
class class-default
set fr-de

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
service-policy output FR_405
frame-relay fragment 960

For verification is use the 'show frame-relay pvc 405' command

R4#s frame-relay pvc 405

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

DLCI = 405, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 169 output pkts 175 in bytes 21260
out bytes 18308 dropped pkts 6 in pkts dropped 6
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 30
out bcast pkts 112 out bcast bytes 13140
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:17:45, last time pvc status changed 00:16:05
service policy FR_405
Serial2/0: DLCI 405 -

Service-policy output: FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group 100
0 packets, 0 bytes
5 minute rate 0 bps
Match: dscp cs5 (40)
0 packets, 0 bytes
5 minute rate 0 bps

Class-map: class-default (match-any)
30 packets, 3169 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 30
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 960
cir 768000 bc 7680 be 0 limit 960 interval 10
mincir 384000 byte increment 960 BECN response no IF_CONG no
frags 175 bytes 18308 frags delayed 0 bytes delayed 0

shaping inactive
traffic shaping drops 0

On R5

As on R4 the first 2 steps are identical: i create a new class and policy map. I then reference the new policy map from within the pre-existing service-policy RICH. Nested service policies!!!:-)

class-map match-all DSCP5
match dscp cs5

policy-map FR_405
class DSCP5
class class-default
set fr-de

policy-map RICH
class class-default
shape average 768000 7680
service-policy FR_405

For verification i use the 'show policy-map int s2/0.54' command.

R5#s policy-map int s2/0.54

Serial2/0.54

Service-policy output: RICH

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 1920 7680 7680 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1 84 0 0 no

Service-policy : FR_405

Class-map: DSCP5 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: dscp cs5 (40)

Class-map: class-default (match-any)
1 packets, 84 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
fr-de
Packets marked 3

Both methods achieve the same result!

FRTS versus MQC FRTS - Part I

2008-12-18T08:40:00.000-08:00

MQC FRTS (Modular Quallity Of Service Command Line Interface Frame Relay Traffic Shaping!) has become mainstream in IOS 12.4. This enables FRTS to conform to the same MQC standard method of configuration.

In the following example i use FRTS on the spoke routers with the equivalent MQC FRTS configuration on the hub router.

Spoke Router Config

map-class frame-relay RICH
frame-relay cir 768000
frame-relay bc 7680
frame-relay fair-queue
frame-relay fragment 960

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 405
class RICH

Hub Router Config

policy-map SHAPE
class class-default
shape average 768000 7680 0

interface Serial2/0.35 multipoint
service-policy output SHAPE
interface Serial2/0.54 multipoint
service-policy output SHAPE

Points of note
1) For the shaping within MQC this requires the configuration to be done under the class class-default.
2) If required the class-default can reference another policy map, via the service-policy command. In this way CBWFQ or LLQ can also be introduced.
3) the 'shape average 768000 7680' command equates to the 'frame-relay cir 768000' plus the 'frame-relay bc 7680' command.

For verification use 'show traffic-shape' for FRTS and 'show policy-map' for MQC FRTS

e.g.

s traffic-shape

Interface Se2/0.35
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
503 768000 6048 768000 0 63 6048 -

s policy-map int s2/0.54

Serial2/0.54

Service-policy output: SHAPE

Class-map: class-default (match-any)
22 packets, 242 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
768000/768000 960 7680 0 10 960

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 22 242 0 0 no

rip - neighbor filtering options

2008-12-12T21:53:00.000-08:00

In the above topology i want R6 to only allow routes from R2. Similarly i want R2 to only allow routes from R6.

To meet this requirement i use different methods on each router to achieve the same net result. Both methods require use of the distribute-list command.

On R6 i use and extended acl to first deny the RIP neighbors i do not require and allow the rest. On R2 i make use of the distribute-list gateway command in conjunction with a prefix-list to only allow the neighbors i require.

R6

router rip
version 2
network 54.0.0.0
network 150.1.0.0
network 204.12.1.0
distribute-list 100 in
no auto-summary
!

access-list 100 deny ip host 54.1.7.254 any
access-list 100 deny ip host 204.12.1.254 any
access-list 100 permit ip any any

R2

router rip
version 2
network 204.12.1.0
distribute-list gateway RICH in
no auto-summary
!
ip prefix-list RICH seq 5 permit 204.12.1.6/32

The IP prefix-list in the distribute-list gateway statement allows prefixes to be filtered as they are received based on the source of the update. This allows updates learned from BB3 to be denied, but still allows updates to be received from R6.

Frame Relay - End to End Keepalives

2008-12-11T11:53:00.000-08:00

Frame Relay keepalives allow end to end monitoring of a frame-relay circuit. This enables the local DLCI status to represent the status of the end to end ciruit.

To enable it has to be configured within a frame relay map-class - so its no good looking under the frame-relay sub interface!!

map-class frame-relay DLCI504
frame-relay end-to-end keepalive request

interface s2/0.54
frame-relay class DLCI504

To verify use the command 'show frame-relay end-to-end keepalive'

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

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

SEND SIDE STATISTICS

Send Sequence Number: 91, Receive Sequence Number: 255
Configured Event Window: 3, Configured Error Threshold: 2
Total Observed Events: 111, Total Observed Errors: 38
Monitored Events: 0, Monitored Errors: 0
Successive Successes: 0, End-to-end VC Status: UP

IP Telephony

2008-12-10T22:27:00.000-08:00

In this post an ip phone is attached to fa0/5 on a switch. The requirement is for the switch to mark the voice vlan as 10 and data as 100. The COS value from the phone should be trusted and the switch needs to instruct the phone to assign cos value of 1 to data.

mls qos
vlan 10

int fa0/5
switchport voice vlan 10
switchport access vlan 100
mls qos trust cos
switchport priority extend cos 1N.B. unlike data, when a voice vlan is assigned on an interface the vlan is NOT automatically created on the switch.
N.B.B without any instruction, the cisco phone will mark all data packets with a COS value of 0.

The necessary config for voice on a 3560 can be cribbed from the 'VOICE Vlan' section under the 3560 configuration guide.

Traffic Filtering - Without an ACL

2008-12-07T22:57:00.000-08:00

There is a requirement for R2 to filter traffic to and from neighboring routers R1 and R3. The catch however is that an ACL cannot be used. An unlikely scenario in the real world, but there again something that may be thrown up in a CCIE lab.

R1 ---------------(fa1/0) R2 (fa1/1)--------------- R3

To acheive this a service-policy can be used.

class FROM_R1
match input-interface fa1/0

class FROM_R3
match input-interface fa1/1

policy-map TO_R1
class FROM_R3
drop

policy-map TO_R3
class FROM_R1
drop

int fa1/0
service-policy output TO_R1

int fa1/1
service-policy output TO_R3

Another scenario that might lead to use of a service policy to filter traffic is when an acl cannot be used in isolation to achieve the required filtering results.
For example the requirement may be drop icmp echo and echo replies with a packet length between 300 and 350.

This functionality cannot be achieved using an ACL alone: there is no way of matching on packet length in an acl.
However packet length can be matched in a class map.

Hence

ip access-list ext 101
permit icmp any any echo
permit icmp any any echo-reply

class-map match-all ICMP
match access-group 101
match packet length min 300 max 250

policy-map ICMP
class ICMP
drop

int fa0/0
service-policy input ICMP
service-policy output ICMP