IT support

Virtual switching system (VSS) Configuration For Cisco 4500 series switches

2014-05-26T13:16:00.000+07:00

Introduction:

The Cisco Virtual Switching System is a clustering technology that pools two Cisco Catalyst 4500-E Series Switches with Cisco Catalyst Supervisor Engine 7-E or 7-LE or two Catalyst 4500-X Series Switches into a single virtual switch. In a VSS, the data plane of both clustered switches is active at the same time in both chassis. VSS members are connected by virtual switch links (VSLs) using standard Gigabit or 10 Gigabit Ethernet connections between the VSS members. VSLs can carry regular user traffic in addition to the control plane communication between the VSS members.

Refer to https://supportforums.cisco.com/document/124626/virtual-switching-system-vss-configuration-cisco-4500-series-switches

Physical vs Logical Topology in a VSS Configuration

This document describes how to configure a virtual switching system (VSS) for the Catalyst 4500 series switch (Supervisor Engine 7-E, Supervisor Engine 7L-E).

Some key point to be remembered for Cisco 4500 VSS:

1) Configuration/Capability Supported supervisors on Catalyst 4500-E: VSS support Supervisor Engine 7-E or 7-LE (identical pairs).For more information about hardware to support please refer 4500 VSS Hardware requirement

2) Software requirement: Cisco IOS XE 3.4.0SG and ROMMON IOS Version 15.0(1r) SG7 later released support VSS.(Also refer How to Upgrade Cisco 4500 SUP7-E & Sup7L-E ROMMON To support VSS).

3)license requirement :

To know more on license requirement refer "Release Notes for the Catalyst 4500E Series Switch"

Feature	LAN Base	IP Base	Enterprise Service
Virtual Switching System (VSS	No	Yes (SUP7E only)	Yes
Support for Layer 3 MEC—VSS with Layer 3 Multichassis EtherChannel (MEC) at the aggregation layer Support for VSLP Fast Hello—With VSLP Fast Hello, the Catalyst 4500-X configured for VSS can now connect Access Switches that do not support the ePAgP protocol. Support for VSL Encryption Support for Asymmetrix chassis	No	Yes (SUP7E) No (SUP7LE)	Yes (SUP7E) Yes (SUP7LE)

For information about Software Activation Licensing please refer Cisco Catalyst 4500E Supervisor 7-E and 7L-E and Cisco Catalyst 4500-X Series Software Activation Licensing Deployment Guide.

4) Single-sup cross-chassis VSS support: Yes.

5) Quad-sup VSS configuration with in-chassis redundant sups: In-chassis redundant sups in rommon mode with active uplinks.

6) It also supports 10 Gigabit Ethernet Virtual Switch Link (VSL) and 1 Gigabit Ethernet VSL.

7) SSO and nonstop forwarding (NSF) must be configured on each switch. If a VSS does not meet the requirements for SSO redundancy; it will be incapable of establishing a relationship with the peer switch. Catalyst 4500/4500-X series switches' VSS does not support route processor redundancy (RPR) mode.

Prerequisite:

Before configuring VSS on Cisco 4500 please verify hardware and software requirement.


SW1#sh ver | in IOS

Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSAL-M), Version 03.04.00.SG RELEASE SOFTWARE (fc3)

Cisco IOS-XE software, Copyright (c) 2005-2010, 2012 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
or the applicable URL provided on the flyer accompanying the IOS-XE
documentation or "License Notice" file accompanying the IOS-XE software

SW1#sh ver | in ROM

ROM: 15.0(1r)SG7

System returned to ROM by power-on 

SW1#sh license image levels 

Module name       Image level Priority Configured Valid license

--------------------------------------------------------------------

WS-X45-SUP7-E     entservices  1         YES        entservices            
                  ipbase       2         NO         ipbase                

    Role           Current Level     Reboot Level
----------
                  lanbase      3         NO         lanbase  
 
Module Nam
e----------------------------------------------------------

entservices       entservices
WS-X45-SUP7-E  Active


SW2#sh ver | in IOS

Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSAL-M), Version 03.04.00.SG RELEASE SOFTWARE (fc3)

Cisco IOS-XE software, Copyright (c) 2005-2010, 2012 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
or the applicable URL provided on the flyer accompanying the IOS-XE

documentation or "License Notice" file accompanying the IOS-XE softw

SW2#sh ver | in ROM

ROM: 15.0(1r)SG7

System returned to ROM by power-on

SW2#sh license image levels

Module name       Image level Priority Configured Valid license

--------------------------------------------------------------------

WS-X45-SUP7-E     entservices  1         YES        entservices            
                  ipbase       2         NO         ipbase                

  Role           Current Level     Reboot Level
-----------
                  lanbase      3         NO         lanbase 

Module Name 
 ---------------------------------------------------------

 entservices       entservices
WS-X45-SUP7-E   Active

Configuration Steps:

STEP1: Assigning Virtual Switch Domain and Switch Numbers

First you have to configure the same virtual switch domain number on both switches of the VSS. The virtual switch domain is a number between 1 and 255.After domain number you must configure one switch to be switch number 1 and the other switch to be switch number 2.


SW1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#switch virtual domain 10

Domain ID 10 config will take effect only

after the exec command 'switch convert mode virtual' is issued

SW1(config-vs-domain)#switch 1

SW1(config-vs-domain)#exit

SW1(config)#


SW2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW2(config)#switch virtual domain 10

Domain ID 10 config will take effect only

after the exec command 'switch convert mode virtual' is issued

SW2(config-vs-domain)#switch 2

SW2(config-vs-domain)#exit

SW2(config)#

STEP2: Configuring VSL Port Channel:

Then you need to configure VSL with a unique port channel on each switch. During the conversion, the VSS configures both port channels on the VSS Active switch. If the VSS Standby switch VSL port channel number has been configured for another use, the VSS comes up in RPR mode. To avoid this situation, check that both port channel numbers are available on both of the switches.


SW1(config)#int port-channel 5
SW1(config-if)#switchport

ual link 1
SW1(config-if)#no shut
SW
SW1(config-if)#switch vir
t1(config-if)#exit

2: %SPANTREE-6-PORTDEL_ALL_VLANS: Port-channel5 deleted from all Vlans
*Jan 24 05:19:57.0
9


SW2(config)#int port-channel 10
SW2(config-if)#switchport

ual link 2
SW2(config-if)#no shut
SW
SW2(config-if)#switch vir
t2(config-if)#exit
SW2(config)#

6-PORTDEL_ALL_VLANS: Port-channel10 deleted from all Vlans
*Jan 24 05:14:17.273: %SPANTREE
-

STEP3: configure the VSL ports

You need to add the VSL physical ports to the port channel. In the following example, interfaces Gigabit Ethernet 7/3 and 7/4 on Switch 1 are connected to interfaces Gigabit Ethernet 4/45 and 4/46 on Switch 2.


SW1(config)#int range gig7/3 - 4

SW1(config-if-range)#switchport mode trunk

SW1(config-if-range)#channel-group 5 mode on

WARNING: Interface GigabitEthernet7/3 placed in restricted config mode. All extraneous configs removed!
WARNING: Interface GigabitEthernet7/4 placed in restricted config mode. All extraneous configs removed!


SW1(config-if-range)#exit


SW2(config)#int range gig4/45 - 46

SW2(config-if-range)#switchport mode trunk

SW2(config-if-range)#channel-group 10 mode on

WARNING: Interface GigabitEthernet4/45 placed in restricted config mode. All extraneous configs removed!
WARNING: Interface GigabitEthernet4/46 placed in restricted config mode. All extraneous configs removed!


SW2(config-if-range)#exit

Note: Once the interfaces are put into VSL port-channel with “channel-group" command, then the interfaces goes into “notconnect” status. Interface status will show UP, but the line protocol will be down. The interface will be in UP/down (not connect) status, till the switch is rebooted in step 4.

STEP4: Converting the Switch to Virtual Switch Mode:

You need to enter the “switch convert mode virtual” command on Switch 1 for Converting to Virtual Switch Mode .After you enter this command it will prompted to confirm the action. Enter yes. The system creates a converted configuration file, and saves the file to the bootflash:


SW1#switch convert mode virtual 

his command will convert all interface names


Tto naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and

s/no]: yes
Convert
reload the switch.
Do you want to proceed? [y
eing interface names
Building configuration...

3 bytes[OK]
Saving converted configuration to bootflash: .
Compressed configuration from 6551 bytes to 28
9..
Destination filename [startup-config.converted_vs-20130124-062921]?

n (G) Signature verification PASSED  

Rommon
Please stand by while rebooting the system...
Restarting system. 

Romm
o (P) Signature verification PASSED  


D
FPGA   (P) Signature verification PASS
E

Similarly you need to enter the “switch convert mode virtual” command on Switch 2 for converting to Virtual Switch Mode.


SW2#switch convert mode virtual 


This command will convert all interface names

to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and

s/no]: yes
Convert
reload the switch.
Do you want to proceed? [y
eing interface names
Building configuration...

4 bytes[OK]
Saving converted configuration to bootflash: .
Compressed configuration from 6027 bytes to 27
7..
Destination filename [startup-config.converted_vs-20130124-052526]?

n (G) Signature verification PASSED  

Rommon
Please stand by while rebooting the system...
Restarting system. 

Romm
o (P) Signature verification PASSED  

FPGA   (P) Signature verification PASSED 


                                     *
* Welcome to Rom Mon
************************************************************
*                   
 itor for   WS-X45-SUP7-E System.       *
* Copyright (c) 2008-2012 by Cisco Systems, Inc.           *

                 *
*****************************************
* All rights reserved.                                     *
*                                        

*******************

After you confirm the above commands on both switches, the running configuration is automatically saved as the startup configuration and the switch reboots. After the reboot, the switch is in virtual switch mode, so you must specify interfaces with three identifiers (switch/module/port).

When switches are being converted to VSS, you should not set them to ignore startup-config. If done, the switch can be enabled to parse the startup-config at the rommon prompt. Ignoring startup-config in VSS mode causes a switch to boot in a semi-VSS mode, which can only be corrected by a reboot and by enabling the parsing of startup-config.

Verification:

1) To displays the virtual switch domain number, and the switch number and role for each of the switches you can use “show switch virtual”command.


SW1#sh switch virtual 


xecuting the command on VSS member switch role = VSS Active, id = 1 

E

Switch mode                  : Virtual Switch

mber          : 1
Local switch op
Virtual switch domain number : 10
Local switch n
uerational role: Virtual Switch Active
Peer switch number           : 2

mmand on VSS member switch role = VSS Standby, id = 2 
Peer switch operational role : Virtual Switch Standby 

Executing the c
o 


Switch mode                  : Virtual Switch
Virtual switch domain number : 10
Local switch number          : 2

Virtual Switch Active
Local switch operational role: Virtual Switch Standby
Peer switch number           : 1
Peer switch operational role :

2) Once both switches cluster in single virtual switch, you will only have Active switch console and your Standby switch console appears as follow:


SW2-standby> 

tandby console disabled
S

3) To displays the role, switch number, and priority for each of the switch in the VSS use “show switch virtual role” command.


SW1#sh switch virtual role 


xecuting the command on VSS member switch role = VSS Active, id = 1 

E
RRP information for Instance 1 


---------------------------------
Valid Flags   Peer     Preferred R
----------------------------------
-eserved
               Count     Peer       Peer  


---------------
TRUE   V       1           1         1  

Switch Swi
----------------------------------------------------
-tch Status Preempt       Priority Role     Local   Remote

  SID
----------------------------------------------------------
       Number         Oper(Conf)   Oper(Conf)         SID 
 ----------
LOCAL   1     UP     FALSE(N )     100(100) ACTIVE   0       0

epresents the local switch  

Flags : V - Valid
In dual-active re
REMOTE  2     UP     FALSE(N )     100(100) STANDBY 6834   6152  

Peer 0 
rcovery mode: No  

Executing the command on VSS member switch role = VSS Standby, id = 2 

RRP information for Instance 2  


Count     Peer       Peer  

---------------------------------------
--------------------------------------------------------------------
Valid Flags   Peer     Preferred Reserved
              
 -----------------------------
TRUE    V       1           1         1  

Switch Switch Status Preempt       Priority Role     Local   Remote

2     UP     FALSE(N )     100(100) STANDBY  0       0
REMOTE  1
       Number         Oper(Conf)   Oper(Conf)         SID     SID
--------------------------------------------------------------------
LOCAL 
      UP     FALSE(N )     100(100) ACTIVE   6152   6834 

Peer 0 represents the local switch

Flags : V - Valid


In dual-active recovery mode: N
o

4) To Displays information about the VSL use “show switch virtual link”command.


SW1#sh switch virtual link  


xecuting the command on VSS member switch role = VSS Active, id = 1 

E
VSL Status : UP
VSL Uptime : 3 minutes
VSL Control Link : Gi1/7/4  


VSL Status : UP
VSL Uptime : 3 minutes
VSL Control Link : Gi2/4/45

Executing the command on VSS member switch role = VSS Standby, id = 2

5) You can also verify information about the VSL port channel using “show switch virtual link port-channel”command.


SW1#sh switch virtual link port-channel 


xecuting the command on VSS member switch role = VSS Active, id = 1 

E
Flags: D - down       P - bundled in port-channel

standby (LACP only)
       R - Layer
       I - stand-alone s - suspended
       H - Hot
-3     S - Layer2
       U - in use     N - not in use, no aggregation

e, no aggregation due to minimum links not met
  
       f - failed to allocate aggregator         

       M - not in u
s     m - not in use, port not aggregated due to minimum links not met
       u - unsuitable for bundling

rts
------+-------------+
       d - default port  
       
       w - waiting to be aggregated  


Group Port-channel Protocol   P
o-----------+-------------------
5     Po5(SU)          -       Gi1/7/3(P) Gi1/7/4(P)

member switch role = VSS Standby, id = 2  

Flags: D - 
10    Po10(SU)         -       Gi2/4/45(P) Gi2/4/46(P)  

Executing the command on VS
Sdown       P - bundled in port-channel
       I - stand-alone s - suspended
       H - Hot-standby (LACP only)

ate aggregator         
       

       R - Layer3     S - Layer2
       U - in use     N - not in use, no aggregation
       f - failed to allo
c       M - not in use, no aggregation due to minimum links not met
       m - not in use, port not aggregated due to minimum links not met

ts
------+-------------+----------
       u - unsuitable for bundling
       d - default port  
       
       w - waiting to be aggregated 

Group Port-channel Protocol   Po
r-+-------------------
5     Po5(SU)          -       Gi1/7/3(P) Gi1/7/4(P)
10    Po10(SU)         -       Gi2/4/45(P) Gi2/4/46(P) 



SW1
#

Reference:

Catalyst 4500 Series Switch Software Configuration Guide, Release IOS XE 3.4.0SG and IOS 15.1(2)SG

Catalyst Confidence: VSS on the 4500 :

Cisco - Virtual Switching System Available on Cisco Catalyst 4506-E

2014-05-15T10:21:00.001+07:00

Cisco IOS XE Software Release 3.4.0SG and Cisco IOS Software Release 15.1(2)SG for Cisco Catalyst 4500E, 4500-X, and 4900 Series Switches

Overview

This product bulletin describes the primary hardware and software features supported by Cisco IOS® Software Release XE3.4.0SG/15.1(2)SG for the following products:

Cisco® Catalyst® 4500 Series Supervisor Engine 7-E and Supervisor Engine 7L-E running Cisco IOS XE Software Release 3.4.0SG
Cisco Catalyst 4500-X Series Switch running Cisco IOS XE Software Release 3.4.0SG
Cisco Catalyst 4500 Series Supervisor Engine 6-E and Supervisor Engine 6L-E running Cisco IOS Software Release 15.1(2)SG
Cisco Catalyst 4900M, 4948E, and 4948E-F Switches running Cisco IOS Software Release 15.1(2)SG

Cisco IOS XE Software Release 3.2.0SG and Cisco IOS Software Release 15.0(2)SG are the base releases for new extended maintenance on Cisco Catalyst 4500E, 4500-X and Cisco Catalyst 4900M and 4948E/E-F Series Switches.

For detailed information about the features and hardware supported in Extended Maintenance Release Cisco IOS XE Software Release 3.4.0SG and Cisco IOS Software Release 15.1(2)SG, refer to the release notes and support documentation at:

Cisco IOS XE Software 3.40SG release notes for:
- Cisco Catalyst 4500E (with Supervisor Engine 7-E/7L-E)
- Cisco Catalyst 4500-X
Cisco IOS Software 15.1(2)SG release notes for:
- Cisco Catalyst 4500E (with Supervisor Engine 6-E/6L-E)
- 4900M, 4948E and 4948E-F

Primary Hardware and Software Service Innovations Delivered in Cisco IOS XE Software Release 3.4.0SG and Cisco IOS Software Release 15.1(2)SG

Cisco IOS Software Release XE3.4.0SG/15.1(2)SG is part of the new software releases on Cisco Catalyst 4500E and 4500-X Series Switches and Cisco Catalyst 4900M and 4948E/E-F Switches. These releases deliver new software and hardware innovations in campus access and aggregation deployments that span across many technologies, including security, high availability, and IP multicast. Each technology is covered in more detail in this product bulletin.

Software Features

Cisco Virtual Switching System (VSS) for Cisco Catalyst 4500E (Supervisor Engine 7-E and 7L-E) and 4500X Series Switches

Cisco VSS on the Cisco Catalyst 4500E and Cisco Catalyst 4500-X provides the following benefits:

Simplified network operations:
- Providing a single point of management (with single IP address), it allows any updates, policy changes and configurations to be synchronized between the two switches, eliminating error-prone manual synchronization.
- Forming Multichassis EtherChannel (MEC) to the logical switch, Cisco VSS provides a loop-free topology, no longer needing to rely on Spanning Tree Protocol.
- A single routing instance on the virtual switch eliminates the issues of managing, tuning, and troubleshooting first hop routing protocols such as Hot Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP).
- Cisco Prime™ 4.2.2 now enables one to centrally manage the pair of switches as a single virtual chassis.
Resiliency:
- Stateful failover between the supervisor engines on the two chassis provides subsecond failover and transparent failover even to delay-sensitive applications such as voice and video.
- With EtherChannels extended across two physical chassis, it provides for increased resiliency. These links are configured as MEC, minimizing traffic disruption from switch or uplink failure.
Increased system bandwidth:
- The active-active MEC extended across two physical chassis provides for dual bandwidth utilization, increasing return on investment (ROI) and reducing additional capital expenditures (CapEx) to add capacity.

For Cisco Catalyst 4500E, VSS is supported in IP base and Enterprise services on Supervisor Engine 7-E and in Enterprise services only on Supervisor Engine 7L-E. On Cisco Catalyst 4500-X, VSS is supported in IP base and enterprise services. All 1 Gigabit Ethernet (GE) and 10GE links may be configured for virtual switch links (VSL).

The physical and logical views of VSS are represented in Figures 1 and 2.

Figure 1. VSS Physical View Showing the Physical Connectivity

Figure 2. VSS Physical View Showing the Physical and Logical View

How to configure Queuing on Cisco 3560 and 3750 switch

2014-04-08T16:35:00.000+07:00

QoS (Quality of Service) on Cisco Catalyst switches is not as easy as configuring it on routers. The big difference is that on routers QoS runs in software while on our switches it’s done in hardware. Since switching is done in hardware (ASICs) we also have to do our congestion management (queuing) in hardware. The downside of this is that QoS is in effect immediately. In this article I will give you an overview of all the different commands and an explanation of how QoS works. If you are totally new to LAN QoS do yourself a favor and watch this video:

The first 54 minutes are about classification, marking and policing so if you only care about congestion management and queuing you can skip the first part. Having said that let’s walk through the different commands.

Priority Queue

If your switch supports ingress queuing then on most switches (Cisco Catalyst 3560 and 3750) queue 2 will be the priority queue by default. Keep in mind that there are only 2 ingress queues. If we want we can make queue 1 the priority queue and we can also change the bandwidth. Here’s how to do it:

Switch(config)#mls qos srr-queue input priority-queue 1 bandwidth 20

The command makes queue 1 the priority queue and limits it to 20% of the bandwidth of the total internal ring bandwidth.

For our egress queuing we have to enable the priority queue ourselves! It’s not enabled by default. Here’s how you can do it:

Switch(config)#interface fa0/1
Switch(config-if)#priority-queue out

The command above will enable the outbound priority queue for interface fa0/1. By default queue 1 is the priority queue!

Queue-set

The queue-set is like a template for QoS configurations on our switches. There are 2 queue-sets that we can use and by default all interfaces are assigned to queue-set 1. If you plan to make changes to buffers etc. it’s better to use queue-set 2 for this. If you change queue-set 1 you will apply you new changes to all interfaces.

This is how you can assign an interface to a different queue-set:

Switch(config)#interface fa0/2
Switch(config-if)#queue-set 2

Above we put interface fa0/2 in queue-set 2. Keep in mind that we only have queue-sets for egress queuing, not for ingress.

Buffer Allocation

For each queue we need to configure the assigned buffers. The buffer is like the ‘storage’ space for the interface and we have to divide it among the different queues. This is how to do it:

mls qos queue-set output  buffers Q1 Q2 Q3 Q4

Above you see the mls qos command. First we select the queue-set and then we can divide the buffers between queue 1,2,3 and 4. For queue 1,3 and 4 you can select a value between 0 and 99. If you type 0 you will disable the queue. You can’t do this for queue 2 because it is used for the CPU buffer. Let’s take a look at an actual example:

Switch(config)#mls qos queue-set output 2 buffers 33 17 25 25

This will divide the buffer space like this:

33% for queue 1.
17% for queue 2.
25% for queue 3.
25% for queue 4.

Besides dividing the bufferspace between the queues we also have to configure the following values per queue:

Threshold 1 value
Threshold 2 value
Reserved value
Maximum value

The command to configure these values looks like this:

mls qos queue-set output  threshold  T1 T2 RESERVED MAXIMUM

First you need to select a queue-set, select the queue number and finally configure a threshold 1 and 2 value, reserved value and the maximum value.

Here’s an example:

Switch(config)#mls qos queue-set output 2 threshold 3 33 66 100 300

In the example above we configure queue-set 2. We select queue 3 and set the following values:

Threshold 1 = 33%
Threshold 2 = 66%
Reserved = 100%
Maximum = 300%

This means that threshold 1 can go up to 33% of the queue. Threshold 2 can go up to 66% of the queue. We reserve 100% buffer space for this queue and in case the queue is full we can borrow more buffer space from the common pool. 300% means we can get twice our queue size from the common pool.

Assign marked packets/frames to correct queue

You now know how to configure the buffers and thresholds but we still have to tell the switch which CoS and DSCP values have to go to which queue. Here’s the command for it:

mls qos srr-queue

This is what it means:

Direction: input or output.
Marking: CoS or DSCP.
Queue: The queue number.
Threshold: this can be threshold 1,2 or 3.
Values: The CoS or DSCP values you want to put here.

Let’s take a look at an actual example:

Switch(config)#mls qos srr-queue output cos-map queue 1 threshold 1 0 1

The command assigns CoS values 0 and 1 to queue 1 up to threshold 1.

Switch(config)#mls qos srr-queue output cos-map queue 1 threshold 2 2 3

This example assigns CoS values 2 and 3 to queue 1 up to threshold 2.

Switch(config)#mls qos srr-queue output cos-map queue 4 threshold 2 6 7

And this one assigns CoS values 6 and 7 to queue 4 up to threshold 2.

Bandwidth Allocation

The buffers determine how large the queues are. In other words how ‘big is our storage’. The bandwidth is basically how often we visit our queues. We can change the bandwidth allocation for each interface. Here’s what it looks like for our igress queuing:

mls qos srr-queue input bandwidth Q1 Q2

Igress queuing only has two queues. We can divide a weight between the two queues. Here’s an example:

Switch(config)#mls qos srr-queue input bandwidth 30 70

With the command above queue 1 will receive 30% of the bandwidth and queue 2 will receive 70%. These two values are “weighted” and don’t have to add up to 100%. If I would have typed somethine like “70 60″ then queue 1 would receive 60/130 = about 46% of the bandwidth and queue 2 would receive 70/130 = about 53%. Of course it’s easier to calculate if you make these values add up to 100.

For our egress queues we have to do the same thing but it will be on interface level. We can also choose between shaping or sharing. Sharing means the queues will divide the available bandwidth between each other. Shaping means you set a fixed limit, it’s like policing. Here’s an example:

Switch(config)#interface fa0/1
Switch(config-if)#srr-queue bandwidth share 30 20 25 25

This will divide the bandwidth as following:

Queue 1: 30%
Queue 2: 20%
Queue 3: 25%
Queue 4: 25%

In this case we have a 100Mbit interface which means queue 1 will receive 30Mbit, queue 2 20Mbit, queue 3 25Mbit and queue 4 25Mbit. If there is no congestion than our queues can go above their bandwidth limit. This is why it’s called “sharing”.

If I want I can enable shaping for 1 or more queues. This is how you do it:

Switch(config)#interface fa0/1
Switch(config-if)#srr-queue bandwidth shape 20 0 0 0

This value is a weighted value. The other queues are not shaped because there’s a 0. When you configure shaping for a queue it will be removed from the sharing mechanism. So how much bandwidth does queue 1 really get? We can calculate it like this:

1/20 = 0.05 x 100Mbit = 5Mbit.

So traffic in queue 1 will be shaped to 5Mbit. Since queue 1 is now removed from the sharing mechanism…how much bandwidth will queue 2,3 and 4 get?

Let’s take a look again at the sharing configuration that I just showed you:

Switch(config)#interface fa0/1
Switch(config-if)#srr-queue bandwidth share 30 20 25 25

I just explained you that queue 1 would receive 30Mbit, queue 2 20Mbit, queue 3 25Mbit and queue 4 also 25Mbit. Since I enabled shaping for queue 1 it doesn’t join the sharing mechanism anymore. This means there is more bandwidth for queue 2,3 and 4. Here’s what the calculation looks like now:

Interface fa0/1 is 100Mbit.
We configured shaping to 5Mbit for queue 1 so there is 95Mbit left.
We configured a weighted of value 20,25 and 25 for queue 2,3 and 4.
20 + 25 + 25 = 70 total.
Queue 2 will receive 20/70 = 0.28 * 100 Mbit – 5 Mbit = 27.1 Mbit.
Queue 3 will receive 25/70 = 0.35 * 100 Mbit – 5 Mbit = 33.9 Mbit.
Queue 4 will receive 25/70 = 0.35 * 100 Mbit – 5 Mbit = 33.9 Mbit.

If we add all these values together:

Queue 1 is shaped to 5 Mbit.
Queue 2 is shared to 27.1 Mbit.
Queue 3 is shared to 33.9 Mbit.
Queue 4 is shared to 33.9 Mbit.
5 + 27.1 + 33.9 + 33.9 = Total bandwidth of 100 Mbit.

That’s how you do it!

It’s also possible to rate-limit the entire interface for egress traffic if you want to save the hassle of configuring shaping. This is how you do it:

Switch(config)#interface fa0/1
Switch(config-if)#srr-queue bandwidth limit 85

This will limit our 100 Mbit interface to 85% so you’ll end up with 85 Mbit.

Verification and troubleshooting

Now you know how to configure everything. Let’s take a look at the different commands you can use to verify everything!

First you should check the capabilities of a switch. You can do this on the interface level as following:

Switch#show interfaces fa0/23 capabilities
FastEthernet0/23
Model:                 WS-C3560-24PS
Type:                  10/100BaseTX
Speed:                 10,100,auto
Duplex:                half,full,auto
Trunk encap. type:     802.1Q,ISL
Trunk mode:            on,off,desirable,nonegotiate
Channel:               yes
Broadcast suppression: percentage(0-100)
Flowcontrol:           rx-(off,on,desired),tx-(none)
Fast Start:            yes
QoS scheduling:        rx-(not configurable on per port basis),
tx-(4q3t) (3t: Two configurable values and one fixed.)
CoS rewrite:           yes
ToS rewrite:           yes
UDLD:                  yes
Inline power:          yes
SPAN:                  source/destination
PortSecure:            yes
Dot1x:                 yes

Above you can see that this Cisco Catalyst 3560 switch has 4 queues with 3 threshold levels.

If you are configuring QoS you need to make sure you enabled it globally first with the “mls qos” command. You can verify if QoS is active or not with the following command:

Switch#show mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

It tells us that QoS is enabled globally. We can also check the QoS parameters for each interface as following:

Switch#show mls qos interface fa0/1
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 1
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

Above you can see the trust state for this interface. We can also verify the queue-sets for this switch. If you didn’t configure them you will find some default values:

Switch#show mls qos queue-set
Queueset: 1
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      25      25      25      25
threshold1:     100     200     100     100
threshold2:     100     200     100     100
reserved  :      50      50      50      50
maximum   :     400     400     400     400
Queueset: 2
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      33      17      25      25
threshold1:     100      33      33     100
threshold2:     100      66      66     100
reserved  :      50     100     100      50
maximum   :     400     200     200     400

Above you will find queue-set 1 and 2. You can see how the buffers are divided per queue and the values for our thresholds, reserved and maximum values.

We can check how queuing is configured per interface. This is how you do it:

Switch#show mls qos interface fastEthernet 0/24 queuing
FastEthernet0/24
Egress Priority Queue : disabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  25 25 25 25
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

Above you see that the priority queue is disabled. Also you see the shaped and shared values and that this interface belongs to queue-set 1.

If you are troubleshooting you should check if you see any drops within the queues. You can do it like this:

Switch#show platform port-asic stats drop FastEthernet 0/1

Interface Fa0/1 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0

Here you can see the drops for each queue. We can also verify if we are receiving traffic that is marked:

Switch#show mls qos interface fastEthernet 0/1 statistics
FastEthernet0/1 (All statistics are in packets)

dscp: incoming
-------------------------------

0 -  4 :           0            0            0            0            0
5 -  9 :           0            0            0            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0            0            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :           0            0            0            0            0
45 - 49 :           0            0            0            0            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :           0            0            0            0
dscp: outgoing
-------------------------------

0 -  4 :           0            0            0            0            0
5 -  9 :           0            0            0            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0            0            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :           0            0            0            0            0
45 - 49 :           0            0            0            0            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :           0            0            0            0
cos: incoming
-------------------------------

0 -  4 :           2            0            0            0            0
5 -  7 :           0            0            0
cos: outgoing
-------------------------------

0 -  4 :           0            0            0            0            0
5 -  7 :           0            0            0
Policer: Inprofile:            0 OutofProfile:            0

That’s all I have for you for now! I suggest you to check out these commands on your own switches to become familiar with them.

René is the creator of Networklessons.com where he writes about networking topics like Cisco, Routing, Switching, Linux, Wireless & Security. He also created GNS3Vault.com where people can study Cisco labs for free.

Introduction To Catalyst 3560 QoS

2014-03-07T09:13:00.002+07:00

In today’s blog we are going to take a look at QoS on the Catalyst 3560 platform – the only switch we need to be concerned with in the CCIE R&S lab. QoS on the 3560 is quite an elaborate topic. This article is not designed to teach you every possible command and option there is to know, but is designed rather to take a look at the most important aspects that are important to understand from the perspective of a CCIE R&S candidate. The ultimate resource for Catalyst 3560 QoS information is of course the 3560 software configuration guide. We will first look at the general QoS model, and then take some time to break apart each section. I won’t lie to you guys — 3560 QoS is an intense topic for most people. This blog will be lengthy, but I will try to keep it to the most important things. 10 or 11 pages is certainly probably more attractive than picking it out of the 1300 page configuration guide yourself : ) Hopefully after reading this blog you will have a much clearer understanding of your options when dealing with 3560 QoS.

QoS Actions For Ingress Traffic

When traffic arrives on a switchport, there is a set of different QoS functions we have the ability to apply.

• Classification

• Policing

• Marking

• Queueing

• Scheduling

Most of these functions are specific for ingress traffic. A few of the options, namely queueing and scheduling, we can also do for egress traffic. One important thing to remember with the 3560 is that when we talk about queueing or scheduling, we could be talking about it from the perspective of inbound traffic (ingress) or outbound traffic (egress). The queueing and scheduling is very similar, but with ingress queueing we have two queues, whereas with egress queueing we have four. In both situations, one queue can be configured as a strict priority queue. In this article we will take a look at Classification, Policing and Marking. Additionally, we will look at egress Queueing and Scheduling.

Classification

The entire point of QoS is to give prefferential treatment to some packets that are deemed “more important” than other packets during times of congestion. If we want to do that, we need a way to figure out what packets are more important. That is the basis of classification. There are multiple different ways to do classification on the 3560, depending on what type of environment you are working in and what it is you are trying to accomplish. We may classify traffic at the interface level through a variety of methods we will discuss below, or at the VLAN level. If you choose to do classification at the VLAN level you will need the mls qos vlan-based command on interfaces that are part of the VLAN you want to do classification on. If we are talking about non-IP traffic we can classify based on trusting the incoming CoS values or based on MAC ACLs. Recall that CoS is a layer 2 thing, so it makes sense that we can classify non-IP traffic with CoS. CoS bits get set in the L2 header, and really have nothing to do with IP. With IP traffic however, we can classify based on trusting incoming CoS, DSCP, IP Precendence values or with L3 ACLs. This also makes sense if you recall that DSCP and IP Precedence are marked in the ToS byte of the IP header. If you attempt to trust DSCP or IP Precendence for non IP traffic, one of two things will happen: If the frame has a CoS value, it will be retained. If not, the default port CoS value will be used. If you choose to classify with ACLs instead of trusting QoS markings, ultimately you will be configuring an ACL, calling the ACL in a class-map, and calling the class-map from a policy-map which you will apply to the interface. You can also configure VLAN based classification by applying a policy-map that does classification and marking to an SVI. Generally speaking, if you choose to not trust anything, and you don’t have any ACLs configured, things will be marked down to best-effort. If a packet is unmarked when it arrives, it will be assigned the default CoS value assigned to the interface, which is 0. This of course, is something we can change with the mls qos cos command.

Understanding trust states as well as the internal mapping table logic of your 3560 switch is probably one of the most important things to know about. It is also one of the most important things to know how to manipulate.

First of all, in order to turn on QoS processing on the switch, we need to enable it with the mls qos command. Secondly, we need to understand our options. As stated previously, you can configure your switch ports to trust certain QoS markings, or not trust QoS markings. By default, nothing is trusted. To trust the markings you will use a variant of the mls qos trust command as shown below. The device option gives us the ability to essentially say “ONLY trust the incoming QoS markings IF the device connected to this port is a Cisco phone.” This allows us to trust an IP phone’s QoS markings for voice packets while also protecting against a user unplugging his PC from the phone and running his cable directly into the switch and getting priority treatment of all packets.


3560(config)#mls qos
3560(config)#int fa0/1
3560(config-if)#mls qos trust ?
cos            cos keyword
device         trusted device class
dscp           dscp keyword
ip-precedence  ip-precedence keyword

So far we have seen that when a frame arrives at the switch port we can either trust the markings or not trust the markings. If we don’t trust the markings or if there is no marking we will get a CoS value of 0 by default. However, if we DO decide to trust the markings, we move on to the next step — mappings. You see, the 3560 has a variety of internal mapping tables that decide what the final markings are going to be, which are based on the incoming markings. For example, we have CoS-To-DSCP,and DSCP-To-CoS among others. The idea is that when a frame comes in, the switch can look at the incoming QoS markings, and from those incoming markings derive a new QoS marking which will ultimately determine how that traffic gets queued. Let’s have a look at some examples.


3560#sh mls qos maps ?
cos-dscp       cos-dscp map keyword
cos-input-q    cos-input queue map keyword
cos-output-q   cos-output queue map keyword
dscp-cos       dscp-cos map keyword
dscp-input-q   dscp-input queue  map keyword
dscp-mutation  dscp-mutation map keyword
dscp-output-q  dscp-output queue map keyword
ip-prec-dscp   ip-prec-dscp map keyword
policed-dscp   policed-dscp map keyword
|              Output modifiers

3560#sh mls qos maps cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 24 32 40 48 56

3560#sh mls qos maps dscp-cos
Dscp-cos map:
d1 :  d2 0  1  2  3  4  5  6  7  8  9
---------------------------------------
0 :    00 00 00 00 00 00 00 00 01 01
1 :    01 01 01 01 01 01 02 02 02 02
2 :    02 02 02 02 03 03 03 03 03 03
3 :    03 03 04 04 04 04 04 04 04 04
4 :    05 05 05 05 05 05 05 05 06 06
5 :    06 06 06 06 06 06 07 07 07 07
6 :    07 07 07 07

3560#sh mls qos maps cos-output-q
Cos-outputq-threshold map:
cos:  0   1   2   3   4   5   6   7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

In the examples above we are looking at three different tables: Cos-To-DSCP and DSCP-To-Cos as well as the CoS to output queue mapping. The idea is this — A frame comes in with some QoS marking (Let’s call it CoS for now) that we happen to trust on the port. The switch then looks at the CoS-To-DSCP mapping and derives a DSCP value to give to the packet. The switch then consults the DSCP-To-CoS map to derive a new CoS value. Finally, based on that CoS value, it chooses an output queue. For example, we can see that CoS 2 gets marked with DSCP 16 and that DSCP 16 gets marked with CoS 2. Let’s say we are trusting CoS and a frame comes in with a CoS of 3. We see that the CoS-To-DSCP map will map CoS 3 to DSCP 24. The DSCP-To-CoS map is then consulted, and we see the CoS value will end up remaining at 3. Finally, we see that CoS 3 gets mapped to output queue #3 with a drop threshold of 1. Keep in mind that this is one particular example of one particular function. If we decided to trust DSCP or IPP instead of CoS, we would consult different tables but the general idea is the same. If we are trusting DSCP instead of CoS on the interface, we can let that DSCP value remain intact and pass through, or we can change it with a DSCP mutation map.

Understanding this process is important for a CCIE candidate. What is equally as important is to know how to modify these default mappings. The key thing to remember is “mls qos map”. From there you can do mostly anything. Let’s go back to our example. Let’s say we are trusting CoS and we want to make sure that incoming frames marked as CoS 3 get mapped to DSCP 28 instead of DSCP 24.


3560(config)#mls qos map cos-dscp ?
  CoS values separated by spaces (up to 8 values total)

3560(config)#mls qos map cos-dscp 0 8 16 28 32 40 48 56
3560(config)#do sh mls qos map cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 28 32 40 48 56

Now suppose that we need to make sure DSCP 28 gets marked back to CoS 5 so that it is sent to priority queue #1 outbound.

If you wish to modify the default CoS/DSCP to output queue mappings you can use the mls qos srr-queue output command.

Policing And Marking

After arriving traffic has been classified, things can move on to the next step if necessary, which is policing and marking. Policing, much like on routers, is for rate-limiting the bandwidth of a particular type of traffic. On the 3560 switch, we can police on an individual interface, or even on an SVI by using hierarchical policies. When we police traffic, we set bandwidth limits on that traffic, and decide what to do about it if things are misbehaving. Namely, we can pass the traffic, drop the traffic, or mark down the QoS markings of the packets. This is all decided on a per-packet basis. After being policed, and potentially marked down THEN we can move into queueing.

One thing to understand about policing on the 3560 switch, is that it works a bit differently than other types of policing or shaping you may be familiar with. Particuarly, people seem to get hung up on why everything they learned about with regards to frame-relay traffic-shaping or shaping in general no longer applies here. Well, for one thing we are talking about policing traffic and not shaping it. Shaping implies some sort of queueing in order to shape the traffic to a given rate over time. Policing on the other hand does not queue traffic. The old well known formula for FRTS Tc = Bc/CIR is not really appropriate for policing on a 3560 switch. The policing IS done using a token bucket type algorithm, but it is much different than the token bucket algorithm used for FRTS. With FRTS things are based on how much data you can send per time slice (Tc). With 3560 policing there is really no concept of hard set time slices. The amount of data you can send at any given moment is more determined by time and the configured policed rate / burst size than anything else. Letting formulas used for traffic-shaping confuse you when doing policing is like comparing apples and oranges. If you don’t allow yourself to confuse the two different but similar technologies, you should be OK.

Policing Physical Ports

Once you decide to police a physical port as opposed to an SVI, you stil have options : ) You can police an individual port based on a policy linked to a single class of traffic, or you can police an individual port based on a policy that is linked to multiple classes (aggregate policer.) The individual port policer is pretty simple. The aggregate policer just allows you to police a SET of classes all together. For example, you can configure multiple class-maps and police the rate of the sum of all the class maps to a certain rate. Let’s have a look at the syntax for the policer on a 3560 switch. This is something you would apply inside a policy-map.

police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}]

The rate specified in bits per second tells us what the average rate is that we wish to police to. This is not necessarily a hard limit because we also have the ability to configure a burst size. The burst size allows the policed traffic to temporarily burst above and beyond the average rate. Keep in mind that the average rate is in terms of bits per second while the burst is in bytes. Notice I didn’t say bytes per second. The burst value specified is essentially defining how DEEP the token bucket is. It has nothing to do with how many bits or bytes PER anything. It is simply the size of the bucket in bytes. This parameter works in conjunction with how fast the bucket leaks (the policed rate) to determine if a packet comforms or does not conform. If the traffic conforms, it is transmitted. If the packet does not conform, we can either drop it or mark down the QoS based on the policed-dscp map. Many people learning this technology tend to get hung up on what values to use for burst. Part of this stems from the idea that when we conigure policing on a router using CAR, we are often told to use the formula Bc = [(CIR / 8) * 1.5] for the Bc burst value (as we are told in the command reference as recommended values). There is no such recommendation for burst values on the 3560. In short, do what you are told in the lab. If you are not given a burst value, I would not recommend you stress too much about what values to put here.

Let’s look at an example of a typical port-based policer on the 3560. Let’s say we want to police FTP traffic on port 19 to an average rate of 20Mbps with a burst of 10KB. We would configure something like this:


ip access-list extended FTP-TRAFFIC
permit tcp any any range ftp-data ftp
!
class-map match-all FTP-TRAFFIC
match access-group name FTP-TRAFFIC
!
policy-map POLICE-FTP
class FTP-TRAFFIC
police 20000000 10000 exceed-action drop
!
interface FastEthernet0/19
service-policy input POLICE-FTP

Now, let’s take a look at an aggregate policer. The idea here is this — We have a policy-map that will match multiple classes of traffic. If the rate of all the classes COMBINED goes over a certain level, we do something about that. In this case, let’s say we are matching HTTP, Telnet, and SSH traffic and we don’t want all that traffic combined to exceed 10 Mb/s with a burst of 50KB on interface fa0/1


mls qos aggregate-police WEB-TELNET-SSH 10000000 50000 exceed-action drop
!
ip access-list extended HTTP-TRAFFIC
permit tcp any any eq 80
!
ip access-list extended TELNET-TRAFFIC
permit tcp any any eq 23
!
ip access-list extended SSH-TRAFFIC
permit tcp any any eq 22
!
!
class-map HTTP
match access-group HTTP-TRAFFIC
!
class-map TELNET
match access-group TELNET-TRAFFIC
!
class-map SSH
match access-group SSH-TRAFFIC
!
!
policy-map AGGREGATE-POLICER
class HTTP
police aggregate WEB-TELNET-SSH
!
class TELNET
police aggregate WEB-TELNET-SSH
!
class SSH
police aggregate WEB-TELNET-SSH
!
!
interface FastEthernet0/1
service-policy input AGGREGATE-POLICER

Policing On SVIs

Policing at the SVI level can be a little more confusing at first. The reason it is more confusing is because it requires hierarchical policies. You cannot apply a policy-map that does policing directly to an SVI. This is similar to how you cannot apply queueing on a router to an ethernet sub-interface. You must configure a more general VLAN based “parent” policy and then call your more specific interface based “child” policy from inside the parent VLAN policy. For example, let’s say we want to police HTTP traffic inbound to VLAN 80 to 1Mb with a 20KB burst size. The interfaces in VLAN 80 we want to apply this to are Fa0/1 – Fa0/5. It would look something like this


! Apply VLAN-Based QoS to participating ports
!
interface range FastEthernet0/1 - 5
mls qos vlan-based
!
ip access-list extended HTTP
permit tcp any any eq 80
permit tcp any eq 80 any
!
class-map HTTP
match access-group name HTTP
!
class-map POLICED-PORTS
match interface FastEthernet 0/1 - FastEthernet 0/5
!
! Child policy to police the interfaces of VLAN 80
!
policy-map INTERFACE-POLICY
class POLICED-PORTS
police 1000000 20000
!
! Parent policy to apply to VLAN 80 in general
!
policy-map VLAN-POLICY
class HTTP
service-policy INTERFACE-POLICY
!
interface vlan 80
service-policy input VLAN-POLICY

Marking

The good news is that at this point, marking has really already been discussed. Marking can be done in a few ways. We have already seen how traffic can be marked through the classification process. If we trust markings on the port then incoming marked traffic can be re-marked either through the internal switch mappings, passed through in the case of DSCP, or remarked through a policy. If we don’t trust markings, we can still re-mark the traffic with a policy, or allow it to be marked down as best effort. If the traffic is not marked in the first place, we can choose to mark it ourselves, or assign it the default interface CoS.

Queueing And Scheduling

As I mentioned earlier, the 3560 has two input queues per interface with queue 2 being the default priority queue. The 3560 also has four output queues per interface, with queue 1 being the priority queue. The priority queue is not something that happens automagically, and must be enabled. To enable the input prioriity queue you will use the global command mls qos srr-queue input priority-queue. To enable the output priority queue you will use the interface level command priority-queue out.

When we are talking about Queueing on the 3560 there is a concept known as WTD or weighted tail drop that applies to both input and output queues. To put it simply, each queue has three different drop thresholds that correspond to different CoS values. Frames that are “less important” than others can be configured to be dropped at lower levels of congestion than “more important” frames. For example, maybe CoS values 5,6 and 7 are considered very important in your network, but CoS 1-4 are less important. Your WTD configuration would probably have CoS 1-4 mapped to the thresholds that get dropped sooner than CoS 5-7. Maybe CoS 1-4 gets dropped at 60% congestion, whereas CoS 5-7 only gets dropped when it absolutely HAS to at 100% congestion. In the grand scheme of things for routing and switching I would say understand the basic concept and know where to find the information if you have to.

Now, when we talk about how the queues actually get serviced and how much they get serviced (who gets better treatment by getting more attention), we are getting into SRR or shaped round robin. This happens again for both input and output queues. We will focus on egress queueing here. As usual, there are multiple options. Namely, we have shaped mode and shared mode. In short, with shaped mode each queue is guaranteed a certain amount of bandwidth, but also policed to that level. If the other queues are not filled, the extra bandwidth is not utilized. With shared mode as the name implies, the bandwidth among the queues is shared according to configured weights, but is not policed. There is a significant difference in understanding the syntax between the two modes.

With shaped mode we have the following interface command:

srr-queue bandwidth shape

In this case the weight values are talking about a specific amount of bandwidth guaranteed for that queue. Weight 1 is for queue 1, weight 2 for queue 2 , etc…The numbers that you enter are the denominator portion of a fraction. For example:


srr-queue bandwidth shape 4 4 4 4

srr-queue bandwidth shape 8 0 0 0

First of all, these are two different examples. In the first line, we are saying “each queue will get 1/4 of the bandwidth of this interface guaranteed.” In the second example, we are saying “Queue 1 will get 1/8 of the bandwidth guaranteed, and all other queues operate in shared mode”. When we use the 0 for the other three queues we tell them to operate in shared mode. So in the case of the second example, queues 2-4 would shared the remaining 87.5% equally.

With shared mode we have the following command:

srr-queue bandwidth share

In the case of shared mode, the numbers have different meanings. Now we are looking at a ratio or how the queues relate to each other. The values themselves have no real meaning. The only thing that matters in shared mode is the ratio of the queues. For example, the following three lines accomplish the exact same thing — They each would allocate 25% of the interface bandwidth to each queue because the ratio between the queues is 1:1.


srr-queue bandwidth share 1 1 1 1

srr-queue bandwidth share 25 25 25 25

srr-queue bandwidth share 100 100 100 100

Let’s try something a bit diferent:

srr-queue bandwidth share 10 20 30 40

With the last example, queue 4 gets 4x as much bandwidth as queue 1 because it has a ratio of 4:1 with queue 1. Queue 4 gets twice as much bandwidth as queue 2, and 1 1/3x bandwidth as queue 3.

Hopefully, this article has been of help to everbody out there learning QoS on the Catalyst 3560. I hope that his has given you some valuable insite into the many different options and capabilities of this switch. As you can see, the 3560 is a very powerful device! As always, I would highly recommend and encourage you guys to do more research, labbing and reading on your own to master this topic. The place to go is the 3560 software configuration guide on the DocCD which you can find here:

http://www.cisco.com/en/US/products/hw/switches/ps5528/products_installation_and_configuration_guides_list.html

By Joe Astorino – CCIE #24347
http://blog.ipexpert.com/2010/05/26/introduction-to-catalyst-3560-qos/

Troubleshooting High CPU Utilization in IP Input Process

2013-11-05T11:58:00.000+07:00

Introduction

This document explains how to troubleshoot high CPU utilization due to the IP input process.
Note: This document does not provide strategies to prevent different types of attacks.

Prerequisites

Requirements

Cisco recommends that you read Troubleshooting High CPU Utilization on Cisco Routers before you proceed with this document.

Components Used

This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

IP Input

The Cisco IOS^® software process called IP input takes care of process-switching IP packets. If the IP input process uses unusually high CPU resources, the router is process-switching a lot of IP traffic. Check these issues:

Interrupt switching is disabled on an interface (or interfaces) that has (have) a lot of traffic
Interrupt switching refers to the use of switching algorithms other than process switching. Examples include fast switching, optimum switching, Cisco Express Forwarding switching, and so on (refer to Performance Tuning Basics for details). Examine the output of the show interfaces switching command to see which interface is burdened with traffic. You can check the show ip interface command to see which switching method(s) are used on each interface. Re-enable interrupt switching on that interface. Remember that regular fast switching is configured on output interfaces: if fast switching is configured on an interface, packets that go out of that interface are fast-switched. Cisco Express Forwarding switching is configured on input interfaces. To create Forwarding Information Base (FIB) and adjacency table entries on a particular interface, configure Cisco Express Forwarding switching on all interfaces that route to that interface.
Fast switching on the same interface is disabled
If an interface has a lot of secondary addresses or subinterfaces and there is a lot of traffic sourced from the interface and destined for an address on that same interface, then all of those packets are process-switched. In this situation, you should enable ip route-cache same-interface on the interface. When Cisco Express Forwarding switching is used, you do not need to enable Cisco Express Forwarding switching on the same interface separately.
Fast switching on an interface providing policy routing is disabled
If a route-map has been configured on an interface, and a lot of traffic is handled by the route-map, then the router process-switches this traffic. In this situation, you should enable ip route-cache policy on the interface. Check the restrictions mentioned in the "Enabling Fast-Switched Policy-Based Routing" section of Configuring Policy-Based Routing.
Traffic that cannot be interrupt-switched arrives
This can be any of the listed types of traffic. Click on linked items for more information.
- Packets for which there is no entry yet in the switching cache
  Even if fast, optimum, or Cisco Express Forwarding switching (CEF) is configured, a packet for which there is no match in the fast-switching cache or FIB and adjacency tables is processed. An entry is then created in the appropriate cache or table, and all subsequent packets that match the same criteria are fast, optimum, or CEF-switched. In normal circumstances, these processed packets do not cause high CPU utilization. However, if there is a device in the network which 1) generates packets at an extremely high rate for devices reachable through the router, and 2) uses different source or destination IP addresses, there is not a match for these packets in the switching cache or table, so they are processed by the IP Input process (if NetFlow switching is configured, source and destination TCP ports are checked against entries in the NetFlow cache as well). This source device can be a non-functional device or, more likely, a device attempting an attack.
  (*) Only with glean adjacencies. Refer to Cisco Express Forwarding for more information about Cisco Express Forwarding adjacencies.
- Packets destined for the router
  These are examples of packets destined for the router:
  - Routing updates that arrive at an extremely high rate. If the router receives an enormous amount of routing updates that have to be processed, this task might overload the CPU. Normally, this cannot happen in a stable network. The way you can gather more information depends on the routing protocol you have configured. However, you can start to check the output of the show ip route summary command periodically. Values that change rapidly are a sign of an unstable network. Frequent routing table changes mean increased routing protocol processing, which results in increased CPU utilization. For further information on how to troubleshoot this issue, refer to the Troubleshooting TCP/IP section of the Internetwork Troubleshooting Guide.
  - Any other kind of traffic destined for the router. Check who is logged on to the router and user actions. If someone is logged on and issues commands that produce long output, the high CPU utilization by the "IP input" process is followed by a much higher CPU utilization by the Virtual Exec process.
  - Spoof attack. To identify the problem, issue the show ip traffic command to check the amount of IP traffic. If there is a problem, the number of received packets with a local destination is significant. Next, examine the output of the show interfaces and show interfaces switching commands to check which interface the packets are coming in. Once you have identified the receiving interface, turn on ip accounting on the outgoing interface and see if there is a pattern. If there is an attack, the source address is almost always different, but the destination address is the same. An access list can be configured to solve the issue temporarily (preferably on the device closest to the source of the packets), but the real solution is to track down the source device and stop the attack.
- Broadcast traffic
  Check the number of broadcast packets in the show interfaces command output. If you compare the amount of broadcasts to the total amount of packets that were received on the interface, you can gain an idea of whether there is an overhead of broadcasts. If there is a LAN with several switches connected to the router, then this can indicate a problem with Spanning Tree.
- IP packets with options
- Packets that require protocol translation
- Multilink Point-to-Point Protocol (supported in Cisco Express Forwarding switching)
- Compressed traffic
  If there is no Compression Service Adapter (CSA) in the router, compressed packets must be process-switched.
- Encrypted traffic
  If there is no Encryption Service Adapter (ESA) in the router, encrypted packets must be process-switched.
- Packets that go through serial interfaces with X.25 encapsulation
  In the X.25 protocol suite, flow control is implemented on the second Open System Interconnection (OSI) layer.
A lot of packets, that arrive at an extremely high rate, for a destination in a directly attached subnet, for which there is no entry in the Address Resolution Protocol (ARP) table. This should not happen with TCP traffic because of the windowing mechanism, but can happen with User Datagram Protocol (UDP) traffic. To identify the problem, repeat the actions suggested in order to track down a spoof attack.
A lot of multicast traffic goes through the router. Unfortunately, there is no easy way to examine the amount of multicast traffic. The show ip traffic command only shows summary information. However, if you have configured multicast routing on the router, you can enable fast-switching of multicast packets with the ip mroute-cache interface configuration command (fast-switching of multicast packets is off by default).
Router is oversubscribed. If the router is over-used and cannot handle this amount of traffic, try to distribute the load among other routers or purchase a high-end router.
IP Network Address Translation (NAT) is configured on the router, and lots of Domain Name System (DNS) packets go through the router. UDP or TCP packets with source or destination port 53 (DNS) are always punted to process level by NAT.
There are other packet types that are punted to processing.
There is fragmentation of IP Datagram. There is a small increase in CPU and memory overhead due to fragment of an IP datagram. Refer to Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC for more information on how to troubleshoot this issue.

Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode - What's the Difference?

2013-10-03T15:06:00.001+07:00

IPSec’s protocol objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality.

As outlined in our IPSec protocol article, Encapsulating Security Payload (ESP) and Authentication Header (AH) are the two IPSec security protocols used to provide these security services. Analysing the ESP and AH protocols is out of this article’s scope, however you can turn to our IPSec article where you’ll find an in-depth analysis and packet diagrams to help make the concept clear.

Understanding IPSec Modes –Tunnel Mode & Transport Mode

IPSec can be configured to operate in two different modes, Tunnel and Transport mode. Use of each mode depends on the requirements and implementation of IPSec.

IPSec Tunnel Mode

IPSec tunnel mode is the default mode. With tunnel mode, the entire original IP packet is protected by IPSec. This means IPSec wraps the original packet, encrypts it, adds a new IP header and sends it to the other side of the VPN tunnel (IPSec peer).

Tunnel mode is most commonly used between gateways (Cisco routers or ASA firewalls), or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it.

Tunnel mode is used to encrypt traffic between secure IPSec Gateways, for example two Cisco routers connected over the Internet via IPSec VPN. Configuration and setup of this topology is extensively covered in our Site-to-Site IPSec VPN article. In this example, each router acts as an IPSec Gateway for their LAN, providing secure connectivity to the remote network:

Another example of tunnel mode is an IPSec tunnel between a Cisco VPN Client and an IPSec Gateway (e.g ASA5510 or PIX Firewall). The client connects to the IPSec Gateway. Traffic from the client is encrypted, encapsulated inside a new IP packet and sent to the other end. Once decrypted by the firewall appliance, the client’s original IP packet is sent to the local network.

In tunnel mode, an IPSec header (AH or ESP header) is inserted between the IP header and the upper layer protocol. Between AH and ESP, ESP is most commonly used in IPSec VPN Tunnel configuration.

The packet diagram below illustrates IPSec Tunnel mode with ESP header:

ESP is identified in the New IP header with an IP protocol ID of 50.

The packet diagram below illustrates IPSec Tunnel mode with AH header:

The AH can be applied alone or together with the ESP, when IPSec is in tunnel mode. AH’s job is to protect the entire packet. The AH does not protect all of the fields in the New IP Header because some change in transit, and the sender cannot predict how they might change. The AH protects everything that does not change in transit. AH is identified in the New IP header with an IP protocol ID of 51.

IPSec Transport Mode

IPSec Transport mode is used for end-to-end communications, for example, for communication between a client and a server or between a workstation and a gateway (if the gateway is being treated as a host). A good example would be an encrypted Telnet or Remote Desktop session from a workstation to a server.

Transport mode provides the protection of our data, also known as IP Payload, and consists of TCP/UDP header + Data, through an AH or ESP header. The payload is encapsulated by the IPSec headers and trailers. The original IP headers remain intact, except that the IP protocol field is changed to ESP (50) or AH (51), and the original protocol value is saved in the IPsec trailer to be restored when the packet is decrypted.

IPSec transport mode is usually used when another tunneling protocol (like GRE) is used to first encapsulate the IP data packet, then IPSec is used to protect the GRE tunnel packets. IPSec protects the GRE tunnel traffic in transport mode.

The packet diagram below illustrates IPSec Transport mode with ESP header:

Notice that the original IP header at the front is the IP header from the original IP packet. Placing the sender’s IP header at the front (with minor changes to the protocol ID), proves that transport mode does not provide protection or encryption to the original IP header and ESP is identified in the New IP header with an IP protocol ID of 50.

The packet diagram below illustrates IPSec Transport mode with AH header:

The AH can be applied alone or together with the ESP when IPSec is in transport mode. AH’s job is to protect the entire packet, however, IPSec in transport mode does not create a new IP header in front of the packet but places a copy of the original with some minor changes to the protocol ID therefore not providing essential protection to the details contained in the IP header (Source IP, destination IP etc). AH is identified in the New IP header with an IP protocol ID of 51.

In both ESP and AH cases with IPSec Transport mode, the IP header is exposed.

Cisco Equipment Performance (per pps and Mbps)

2013-07-05T14:03:00.001+07:00

Introduction

You plan to purchase Cisco router but not sure how fast they are? Or you just need to know how fast your Cisco router you already have? Following official Cisco documentations should be a good start to find out.

Cisco Router Performance (pdf file)
Cisco Switch Performance (pdf file)
Cisco ASA 5500 Series Next Generation Firewalls

Some illustrations

Point 1:

The 1941 model is rated at a theoretical max of 299kpps with *no* services -- no nat, no firewall, no inspect, no anything. The router performance rating in mbps is given by 64-byte performance -- but if you assume standard imix distribution -- you're still only looking at ~223mbps bare services.

ISR/G2 is a software driven platform. Anything you turn on requires CPU cyles -- which takes away from the boxes ability to push packets.

It is the same scenario with the c720x/vxr (get the vxr models if you go this route) with an npe-g1 or npe-g2 -- the difference is that the 7206 is a bigger router with a better clock.

If you're looking for edge router with firewall and crypto - you'll get better performance from an ASA 5500 series for a lot better price. However -- if you need to speak bgp with the provider -- you're going to need a router or go with Juniper SRX models.

Point 2:

Lets compare apples to apples, here.

Please keep in mind that routed ports != switched ports.

A 3550 with two gbics could switch a gig/sec of packets. It is most likely that the switch could come close to that speed "routing" those packets. The issue is that you're not going to be able to run inspect, cbac, nat, etc. on a 3550 switch. For that, you need a 'router' that is capable of said features. The problem is that those features either need (a) a lot of cpu cycles to run or (b) specialized asics to perform those features at line rate (or in the case of the asr1k -- have enough virtualised cores on the box to be able to dedicate one to each function as needed). Another approach is to use Catalyst 6500 series switch with ASA firewall module to provide routing, switching, and firewall on the same box.

In reviewing the switch's counterpart - switchperformance.pdf - you see a much higher pps number. However this is just routing and switching, nothing fancy. The switch ports in a 887 router model should get you close to gig speeds with standard frame size. They are -- after all -- just hitting the switch and back out (although a closer look at the architecture again may be in order to see if you're hitting any weird anomalies or pitfalls). The "fabric" (whose term should not be misused) may not support more than one or two concurrent gig streams -- but you should be able to switch at a gig.

Long story short, you need to compare things correctly and in the right context. You also need to understand the fundamental difference between a 'router' and a 'switch' and how they each can be used for the greatest gain. You are not going to get an easy answer to your question. You are going to need to get a bigger router, one meant to handle a gig with services. If you were just doing nat, you may be able to squeeze out with a 6503e/sup720 and use hardware-assisted nat and use an ASA firewall module for filtering, etc -- but it is unclear whether such switch configuration that would run you in comparison to a 7206vxr/npe-g2.

Point 3:

Another example is the 1700 router line. One can install an additional 10M ether (WIC-1ENET) or a 4 port switch (WIC-4ESW). While one can get near 100Mbps between ports on the ESW as long as they are in the same VLAN. Any routed (eg. inter-vlan) packets have to go to the CPU. The CPU interface for both cards is the Motorola PQUICC high speed serial bus, which is also why those WICs ONLY work in the 1700's. That bus maxes out at 12Mbps(??), on paper. In practice, the WIC can never go over 8.

The 7200's have well documented PCI backplane bandwidth limits. (in Cisco-speak, a "credit" system) The backplane capacity of most cat switches is documented as well. This "credit" system is just Cisco's way of simplifying the bandwidth requirements. In this 7200 series router context, the credit system refers to the bandwidth requirements of the PA's.

What isn't well documented is the effects of services on throughput. And for good reason since one static NAT translation is way different from 10k dynamic translations. Further, Cisco doesn't want to publish actual PCI bus bit rates for their hardware.

Point 4:

The credit system on the c7200 (which Cisco may officially refer as bus points) is enjoyable document to keep. You know where you sit at all times and as long as you do the math, you're ok. All things considered, from a cisco perspective, its very clear cut. For this case the onboard ge ports would be enough for a 1 Gbps link throughput.

The 7200 chassis (or any vendor's chassis) has a finite point value. Each added PA takes its given value (though you must keep track of the math yourself). Exceed the points, then you risk contention. If you know your traffic flows -- you can do this -- but you have to be careful.

The Cat6k offers different perspective entirely. Look at any mailing list on the effects of mixing and matching cfc/dfc types in the chassis, how the cards attach to the backplane, how the internal movement of traffic actually happens as it pertains to the backplane -- not to even mention the limitations of each sup and how they affect the overall forwarding of the box. While the Cat6k performance is well documented, it is very hard to take in for all cards on that platform. While it still provides value and is still a swiss-army knife, it will be interesting when the Cat6k platform is finally EOL and is replaced with something of next generation platform.

Specification of other Cisco equipments

For other Cisco equipments, you can check the following link:
Cisco Product Quick Reference Guide

Additional Info: Nexus switch performaces
»Cisco Forum FAQ »Between Catalyst 6500, Catalyst 6500E, and Nexus platforms

Some Discussions

Check out the following discussions for real-live illustration

Reviews
»[HELP] Cisco 1811 is crashing
»[HELP] Cisco router vs 3Com router
»1921 vs 891 Throughput Testing
»Metro Ethernet: 2821 vs. 2921 router
»[H/W] Cisco 851 versus new gen cheap routers (ex:Dir-600)
»[Config] New ISP, same router (Cisco 1711)
»[H/W] 1711 - upgrade to 1811 or 881 or the new 891
»[H/W] Home Setup - 50MB Cable Connection
»[H/W] Router for 100Mbps/1000Mbps Encrypted

Performance Test
»1811 Load / Performance Testing Results

What is ARP and how does it work in the Cisco IOS?

2013-06-03T16:27:00.001+07:00

The Address Resolution Protocol, or ARP, is a critical protocol in your network infrastructure. What is ARP? It’s an Internet protocol used to map an IP address to a MAC Address. Usually ARP just “works” and you don’t have to do anything about it. However, there are reasons that you may need to make ARP or configure ARP on your router.

Here is how you make a static ARP entry in the Cisco IOS:

In global configuration mode, use:

arp {ip-address | vrf vrf-name} hardware-address encap-type [interface-type]

Here is an example:

arp 10.28.6.14 0700.0800.1834 arpa

To remove an ARP entry, use the no arp command.

To show arp entries, just type show arp and you will see results like this:

Protocol Address          Age (min) Hardware Addr   Type   Interface
Internet 10.4.2.4               10   0000.0c07.ac14 ARPA   FastEthernet0/0
Internet 10.3.3.3               10   0000.0c07.ac14 ARPA   FastEthernet0/0
Internet 10.3.2.7               10   0000.0c07.ac14 ARPA   FastEthernet0/0
Internet 10.4.2.1               10   0007.b400.1401 ARPA   FastEthernet0/0
Internet 10.3.3.7               10   0000.0c07.ac14 ARPA   FastEthernet0/0

As you can see, the IP addresses are mapped to the hardware/MAC addresses on Ethernet interfaces.

Just a tip, if your device’s MAC address isn’t showing up in the ARP table on a switch or router that it is communicating through, it will never be able to communicate. There must be some reason (like an interface down) that is preventing it from making that Layer 2 (Ethernet) to Layer 3 (IP) connection. You can also use the debug arp command to troubleshoot.

And, one final tip- on a Cisco IOS switch, you can use the show mac-address-table or show mac command to see MAC to IP address mappings.

For additional information on using ARP in the Cisco IOS, please see Cisco IOS IP Addressing Service documentation.

For additional information http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml

IP Multicast to MAC Address Mapping

2013-01-31T17:12:00.000+07:00

Map Multicast MAC address to IP Multicast Addresses

In the course of reading through the BSCI authorize self-study guide, I’ve come across a multicast example where the author talks about the concepts behind the multicast IP to MAC address mapping.

In order to achieve the translation between a Layer 3 IP multicast address and Layer 2 multicast MAC address, the low-order 23 bits of the IP address (Layer 3) is mapped into the low-order 23 bits of the MAC address (Layer 2).
The high order 4 bits of the Layer 3 IP address is fixed to 1110 to indicate the Class D address space between 224.0.0.0 through 239.255.255.255
- Ethernet MAC addresses start with 01:00:5E, allowing for a range from 01:00:5E:00:00:00 through 01:00:5E:7F:FF:FF.
With 32 total bits present in an IP address and 4 high order bits of it set at 1110, we are left with 28 bits of unique IP addresses we can use (32 - 4 = 28).
But remember, 23 low-order bits out of the 28 available bits are mapped to the MAC address, giving us 5 remaining bits of overlap.
With the 5 bits of extra overlap, there are 32 (2⁵ = 32) IP multicast address that map to one MAC multicast address.

The problem is, the book does not explain or show how it solved the mapping. So I went about researching how it was done. If you happened to be studying for BSCI, I am referring to the section of the BSCI: Authorized Self-Study Guide, by Teare and Paquet, that starts on page 598 – 600.
The following is an example of how we arrive with those 32 IP addresses that map to a single MAC address:
For reference, use the following conversion chart for converting hex to binary and vice versa

Let’s start by using the example MAC address given in the book :

01:00:5e:0a:00:01

Convert the hexadecimal MAC address 01:00:5e:0a:00:01 to binary
- 0000 0001 : 0000 0000 : 0101 1110 : 0000 1010 : 0000 0000 : 0000 001
- Here’s a breakdown of the conversion bit by bit:
Isolate the 23 low-order binary bits from the converted MAC address:
- 0000 0001 : 0000 0000 : 0101 1110 : 0000 1010 : 0000 0000 : 0000 0001
Take the low order 23 bits from step 2 and plug it into the low-order 23 bits of the IP address (do this in binary):
- 1110 xxxx : x000 1010 : 0000 0000 : 0000 0000
  - 1110 - First 4 high-order bits of the IP address for the multicast address space (224.x.x.x).
  - xxxx x - 5 remaining bits after the 23bits of the IP address is mapped to the MAC address plus the 4 high order bits 1110. This is equal to 32 total IP addresses.
Convert the binary equivalent of the IP addresses to decimal, replacing the x variables with all the values to get all 32 possible IP addresses:
- 11100000 : 0000 1010 : 0000 0000 : 0000 0001= 224.10.0.1
- 11100001 : 0000 1010 : 0000 0000 : 0000 0001= 225.10.0.1
- 11100010 : 0000 1010 : 0000 0000 : 0000 0001= 226.10.0.1
- 11100011 : 0000 1010 : 0000 0000 : 0000 0001= 227.10.0.1
- 11100100 : 0000 1010 : 0000 0000 : 0000 0001= 228.10.0.1
- 11100101 : 0000 1010 : 0000 0000 : 0000 0001= 229.10.0.1
- 11100110 : 0000 1010 : 0000 0000 : 0000 0001= 230.10.0.1
- 1110 0111 : 0000 1010 : 0000 0000 : 0000 0001= 231.10.0.1
- 11101000 : 0000 1010 : 0000 0000 : 0000 0001= 232.10.0.1
- 11101001 : 0000 1010 : 0000 0000 : 0000 0001= 233.10.0.1
- 11101010 : 0000 1010 : 0000 0000 : 0000 0001= 234.10.0.1
- 11101011 : 0000 1010 : 0000 0000 : 0000 0001= 235.10.0.1
- 11101100 : 0000 1010 : 0000 0000 : 0000 0001= 236.10.0.1
- 11101101 : 0000 1010 : 0000 0000 : 0000 0001= 237.10.0.1
- 11101110 : 0000 1010 : 0000 0000 : 0000 0001= 238.10.0.1
- 11101111 : 0000 1010 : 0000 0000 : 0000 0001= 239.10.0.1
- 11100000 : 1000 1010 : 0000 0000 : 0000 0001= 224.138.0.1
- 11100001 : 1000 1010 : 0000 0000 : 0000 0001= 225.138.0.1
- 11100010 : 1000 1010 : 0000 0000 : 0000 0001= 226.138.0.1
- 11100011 : 1000 1010 : 0000 0000 : 0000 0001= 227.138.0.1
- 11100100 : 1000 1010 : 0000 0000 : 0000 0001= 228.138.0.1
- 11100101 : 1000 1010 : 0000 0000 : 0000 0001= 229.138.0.1
- 11100110 : 1000 1010 : 0000 0000 : 0000 0001= 230.138.0.1
- 11100111 : 1000 1010 : 0000 0000 : 0000 0001= 231.138.0.1
- 11101000 : 1000 1010 : 0000 0000 : 0000 0001= 232.138.0.1
- 11101001 : 1000 1010 : 0000 0000 : 0000 0001= 233.138.0.1
- 11101010 : 1000 1010 : 0000 0000 : 0000 0001= 234.138.0.1
- 11101011 : 1000 1010 : 0000 0000 : 0000 0001= 235.138.0.1
- 11101100 : 1000 1010 : 0000 0000 : 0000 0001= 236.138.0.1
- 11101101 : 1000 1010 : 0000 0000 : 0000 0001= 237.138.0.1
- 11101110 : 1000 1010 : 0000 0000 : 0000 0001= 238.138.0.1
- 11101111 : 1000 1010 : 0000 0000 : 0000 0001= 239.138.0.1
All the 32 IP addresses on step 4 map to MAC address 01:00:5e:0a:00:01

Convert IP Multicast Address to Multicast MAC Address

Conversely, a multicast IP address can be converted to its equivalent MAC address. Once you’ve figured out how to convert from Layer 2 MAC to Layer 3 IP, doing the reverse is easy.
To start, we can pick any address from the 32 IP addresses we converted above. Let’s pick a random one like 227.138.0.1

First convert the address 227.138.0.1 to binary:
- 11100011 : 10001010 : 00000000 : 00000001
- We’re only concerned with the red colored portion which represents the low-order 23bits of the IP address.
- Notice that we are dropping the high order bit of the second octet.
Convert those 23 bits to hexadecimal:
- 0A:00:01
We already know that the first 3-bytes (24 bits) of the MAC address is 01:00:5E. This was established earlier in the article. Simply append the result on step 2 to the first 3-bytes and you have your MAC address:
- 01:00:5E:0A:00:01
- *You can pick any of the 32 Ip addresses we have on the list above and you will always get 01:00:5E:0A:00:01 as your MAC address following the steps just mentioned.

To summarize:

1^st octet – Notice that the first octet is left alone.
2^nd octet – You only need to convert the last 7 bits to hex. The second octet in decimal is 138. But if you drop the highest order bit, it becomes a decimal 10 or hex 0A.
3^rd octet – Convert it directly to hex.
4^th octet – Convert it directly to hex.

Refer http://routemyworld.com/2009/03/04/ip-multicast-to-mac-address-mapping/

Datarate Conversion Table

2012-11-09T10:16:00.003+07:00

Data Measurement Chart
Data Measurement	Size
Bit	Single Binary Digit (1 or 0)
Byte	8 bits
Kilobyte (KB)	1,024 Bytes	or	8192 bits
Megabyte (MB)	1,024 Kilobytes	or	1048576 Bytes	8388608 Bits
Gigabyte (GB)	1,024 Megabytes	or	1048576 KB	1073741824 Bytes	8589934592 Bits
Terabyte (TB)	1,024 Gigabytes	or	1048576 MB	1073741824 KB	1099511627776 Bytes	8796093022208 Bits
Petabyte (PB)	1,024 Terabytes	or	1048576 GB	1073741824 MB	1099511627776 KB	1125899906842624 Bytes	9007199254740992 Bits
Exabyte (EB)	1,024 Petabytes	or	1048576 TB	1073741824 GB	1099511627776 MB	1125899906842624 KB	11522921504606846976 Bytes	9223372036854775808 Bits

Connection Speed Chart (also see the detailed connection speed chart)
Internet Technology	Data Rate (per sec)	Data Rate (per sec)	Data Rate (per sec)	Data Rate (per sec)
28.8K Modem	28.8 Kbps	28,800 Bits	3,600 Bytes	3.5 Kilobytes
36.6K Modem	36.6 Kbps	36,600 Bits	4,575 Bytes	4.4 Kilobytes
56K Modem	56 Kbps	56,000 Bits	7,000 Bytes	6.8 Kilobytes
ISDN	128 Kbps	128,000 Bits	16,000 Bytes	15 Kilobytes
T1	1.544 Mbps	1,544,000 Bits	193,000 Bytes	188 Kilobytes
DSL	512 Kbps to 8 Mbps*	8,000,000 Bits	1,000,000 Bytes	976 Kilobytes
Cable Modem	512 Kbps to 52 Mbps*	53,000,000 Bits	6,625,000 Bytes	6,469 Kilobytes (6.3MB/sec)
T3	44.736 Mbps	44,736,000 Bits	5,592,000 Bytes	5,460 Kilobytes (5.3MB/sec)
Gigabit Ethernet	1 Gbps	1,000,000,000 Bits	125,000,000 Bytes	122,070 Kilobytes (119MB/sec)
OC-256	13.271 Gbps	13,271,000,000 Bits	1,658,875,000 Bytes	1,619,995 Kilobytes (1.5GB/sec)

Data Comparison Chart
Kilobits (Kbps)	Bits (bps)	Megabits (Mbps)	Bytes (Bps)	Kilobytes (KBps)	Megabytes (MBps)
28	28,000	0.028	3,500	3.41	0.00334
30	30,000	0.03	3,750	3.66	0.00358
56	56,000	0.056	7,000	6.83	0.00668
80	80,000	0.08	10,000	9.76	0.00954
100	100,000	0.1	12,500	12.20	0.01192
150	150,000	0.15	18,750	18.31	0.01788
200	200,000	0.2	25,000	24.41	0.02384
300	300,000	0.3	37,500	36.62	0.03576
500	500,000	0.5	62,500	61.03	0.05960
800	800,000	0.8	100,000	97.65	0.09537
900	900,000	0.9	112,500	109.86	0.10729
1,000	1,000,000	1	125,000	122.07	0.11921
2,000	2,000,000	2	250,000	244.14	0.23842
4,000	4,000,000	4	500,000	488.28	0.47684
5,000	5,000,000	5	625,000	610.35	0.59605
10,000	10,000,000	10	1,250,000	1,220.70	1.19209
15,000	15,000,000	15	1,875,000	1,831.05	1.78814
30,000	30,000,000	30	3,750,000	3,662.10	3.57628

* This is a range of capable speeds
http://testmy.net/tools/conversion_table.php

Using weights to influence BGP routing

2012-06-14T11:54:00.001+07:00

Applying a route map to a neighborDefining a route mapDefining an access listBGP weight attributeVerifying BGPBGP ConfigurationVerification of initial configurationInitial configurationsIP AddressesDynagen topologyDynagen topology

Today I’m expanding on to our previous BGP lab, “Configuring Basic BGP“. We’re going to demonstrate how we can use BGP’s weight attribute to influence routing out of an autonomous system (AS). We’ve got a new network topology consisting of four routers arranged in a “square”:

Dynagen topology

Here’s what our .net file for Dynagen looks like for this lab:

autostart = False

[localhost:7200]

      workingdir = /home/jlgaddis/dynamips/working/bgp

      [[3640]]
              image = /home/jlgaddis/dynamips/ios/c3640-js-mz.124-17.img
              idlepc = 0x604c37fc
              ram = 128
              disk0 = 8
              disk1 = 0
              mmap = true
              ghostios = true

      [[router R1]]
              model = 3640
              console = 2000
              slot0 = NM-4T
              s0/0 = R2 s0/0
              s0/1 = R4 s0/1

      [[router R2]]
              model = 3640
              console = 2001
              slot0 = NM-4T
              s0/1 = R3 s0/1

      [[router R3]]
              model = 3640
              console = 2002
              slot0 = NM-4T
              s0/0 = R4 s0/0

      [[router R4]]
              model = 3640
              console = 2003
              slot0 = NM-4T

IP Addresses

To better illustrate the IP addressing used within the lab, here’s a handy dandy table for you as well:

Device	Interface	IP Address	Subnet Mask
R1	Loopback 0	192.168.1.1	255.255.255.0
	Serial 0/0	192.168.0.1	255.255.255.252
	Serial 0/1	192.168.0.14	255.255.255.252
R2	Loopback 0	192.168.2.2	255.255.255.0
	Serial 0/0	192.168.0.2	255.255.255.252
	Serial 0/1	192.168.0.5	255.255.255.252
R3	Loopback 0	192.168.3.3	255.255.255.0
	Serial 0/0	192.168.0.9	255.255.255.252
	Serial 0/1	192.168.0.6	255.255.255.252
R4	Loopback 0	192.168.4.4	255.255.255.0
	Serial 0/0	192.168.0.10	255.255.255.252
	Serial 0/1	192.168.0.13	255.255.255.252

Each router will advertise the /24 network of its Loopback 0 interface into BGP.

Initial configurations

Using the IP addressing schema from the table above, let’s go ahead and configure the loopback0, serial0/0, and serial0/1 interfaces on each router:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# interface serial 0/0
R1(config-if)# ip address 192.168.0.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# interface serial 0/1
R1(config-if)# ip address 192.168.0.14 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end
R1#

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# interface serial 0/0
R2(config-if)# ip address 192.168.0.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# interface serial 0/1
R2(config-if)# ip address 192.168.0.5 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# end
R2#

R3# configure terminal
R3(config)# interface loopback 0
R3(config-if)# ip address 192.168.3.3 255.255.255.0
R3(config-if)# interface serial 0/0
R3(config-if)# ip address 192.168.0.9 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# interface serial 0/1
R3(config-if)# ip address 192.168.0.6 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# end
R3#

R4# configure terminal
R4(config)# interface loopback 0
R4(config-if)# ip address 192.168.4.4 255.255.255.0
R4(config-if)# interface serial 0/0
R4(config-if)# ip address 192.168.0.10 255.255.255.252
R4(config-if)# no shutdown
R4(config-if)# interface serial 0/1
R4(config-if)# ip address 192.168.0.13 255.255.255.252
R4(config-if)# no shutdown
R4(config-if)# end
R4#

Verification of initial configuration

Let’s verify that we have full connectivity between our devices:

R1# ping 192.168.0.2

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

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/42/112 ms
R1#

R2# ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/21/28 ms
R2# ping 192.168.0.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/37/100 ms
R2#

R3# ping 192.168.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/24 ms
R3# ping 192.168.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms
R3#

R4# ping 192.168.0.9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms
R4# ping 192.168.0.14

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
R4#

Alright, looks like we’re good to go!

BGP Configuration

Now we can get started on configuring BGP. Each router has two BGP neighbors that are directly connected via the serial 0/0 and serial 0/1 interfaces. On each router, we’re going to advertise into BGP the network of the loopback 0 interface (“192.168.x.0/24″):

R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# network 192.168.1.0 mask 255.255.255.0
R1(config-router)# neighbor 192.168.0.2 remote-as 65002
R1(config-router)# neighbor 192.168.0.13 remote-as 65004
R1(config-router)# end
R1#

R2# configure terminal
R2(config)# router bgp 65002
R2(config-router)# network 192.168.2.0 mask 255.255.255.0
R2(config-router)# neighbor 192.168.0.1 remote-as 65001
R2(config-router)# neighbor 192.168.0.6 remote-as 65003
R2(config-router)# end
R2#

R3# configure terminal
R3(config)# router bgp 65003
R3(config-router)# network 192.168.3.0 mask 255.255.255.0
R3(config-router)# neighbor 192.168.0.5 remote-as 65002
R3(config-router)# neighbor 192.168.0.10 remote-as 65004
R3(config-router)# end
R3#

R4# configure terminal
R4(config)# router bgp 65004
R4(config-router)# network 192.168.4.0 mask 255.255.255.0
R4(config-router)# neighbor 192.168.0.9 remote-as 65003
R4(config-router)# neighbor 192.168.0.14 remote-as 65001
R4(config-router)# end
R4#

Shortly after configuring BGP (above), we should see syslog messages letting us know that the adjacencies have formed. For example:

R1#
*Mar  1 00:15:03.791: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 Up
R1#
*Mar  1 00:19:50.823: %BGP-5-ADJCHANGE: neighbor 192.168.0.13 Up
R1#

Verifying BGP

Let’s take a look at our BGP table on R1:

R1# show ip bgp
BGP table version is 5, local router ID is 192.168.1.1
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
*> 192.168.1.0      0.0.0.0                  0         32768 i
*  192.168.2.0      192.168.0.13                           0 65004 65003 65002 i
*>                  192.168.0.2              0             0 65002 i
*  192.168.3.0      192.168.0.13                           0 65004 65003 i
*>                  192.168.0.2                            0 65002 65003 i
*  192.168.4.0      192.168.0.2                            0 65002 65003 65004 i
*>                  192.168.0.13             0             0 65004 i
R1#

We can see that we have two routes to each of: 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24. All things being equal, BGP will choose the shortest path to each network. We can see this evidenced by the fact that BGP has chosen to send traffic for 192.168.2.0/24 to AS 65002 (R2) and traffic for 192.168.4.0/24 to AS 65004 (R4). Notice, however, that while there are two routes to 192.168.3.0/24 (AS 65003), BGP has chosen to send traffic for that network through AS 65002 (R2). The path through R2 was chosen because it is the “more stable” route (R1′s adjacency with R2 was formed before R1′s adjacency with R4).

Let’s assume, however, that (for whatever reason) we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest (but not always best) way to do this is by using BGP’s weight attribute.

BGP weight attribute

Note that in the output of “show ip bgp” above, the weights assigned to each route to 192.168.3.0 are 0:

*  192.168.3.0      192.168.0.13                           0 65004 65003 i
*>                  192.168.0.2                            0 65002 65003 i

Zero is the default value. When multiple routes to the same destination exist, BGP will prefer the route with the highest weight. To influence traffic to 192.168.3.0 to take the path through AS 65004 (R4), we need to modify the weight assigned to the route received from R4. There are a few ways of doing this, but we’re going to use a route map (probably the most common method).

Just for verification, let’s look at what is currently in our routing table for 192.168.3.0/24:

R1# show ip route | include 192.168.3.0
B    192.168.3.0/24 [20/0] via 192.168.0.2, 00:17:31
R1#

We are, indeed, routing traffic to 192.168.3.0/24 via R2 (192.168.0.2).

Defining an access list

We are actually receiving multiple routes from R4, but only want to influence routing for one route so we are going to use route maps in conjunction with an IP access list to achieve our desired outcome. First, we need to define an access list that matches 192.168.3.0/24:

R1# configure terminal
R1(config)# access-list 3 permit 192.168.3.0 0.0.0.255
R1(config)# end
R1#

Defining a route map

With our access list now matching the networks we want to manipulate, we can now create our route map (which we’ll call “NET3″). Our route map will be configured to match traffic defined by access list 3 and will set the weight to 100:

R1# configure terminal
R1(config)# route-map NET3 permit 10
R1(config-route-map)# match ip address 3
R1(config-route-map)# set weight 100
R1(config-route-map)# route-map NET3 permit 20
R1(config-route-map)# end
R1#

You may be wondering about the “route-map NET3 permit 20″ statement, since it doesn’t appear to do anything. From Cisco:

“It is proper behavior to not accept any autonomous system path not matching the match clause of the route map. This means that you will not set the metric and the Cisco IOS software will not accept the route. However, you can configure the software to accept autonomous system paths not matched in the match clause of the route map command by using multiple maps of the same name, some without accompanying set commands.”

That’s exactly what we did in this case. If we had left out the “route-map NET3 permit 20″ statement, any other routes from R4 would not be accepted. Although we are only going to be manipulating the route to 192.168.3.0/24 from R4, we still need to accept all other routes from R4 into our BGP table.

Applying a route map to a neighbor

With our route map configured, we now need to instruct R1 to apply the route-map to any updates received from our neighbor, R4. Easy enough:

R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# neighbor 192.168.0.13 route-map NET3 in
R1(config-router)# end
R1#

We’re pretty much set at this point. The changes won’t take effect immediately, however. We need to restart the BGP process in order for our changes to take effect. Let’s restart:

R1# clear ip bgp 65004

If we take a look at our BGP table, we should see that the route for 192.168.3.0/24 that came from R4 (AS 65004) should now have a weight of 100 assigned to it, and it does:

R1# show ip bgp
BGP table version is 13, local router ID is 192.168.1.1
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
*> 192.168.1.0      0.0.0.0                  0         32768 i
*  192.168.2.0      192.168.0.13                           0 65004 65003 65002 i
*>                  192.168.0.2              0             0 65002 i
*> 192.168.3.0      192.168.0.13                         100 65004 65003 i
*                   192.168.0.2                            0 65002 65003 i
*> 192.168.4.0      192.168.0.13             0             0 65004 i
*                   192.168.0.2                            0 65002 65003 65004 i
R1#

Subsequently, we should see that the “new” route to 192.168.3.0/24 (via 192.168.0.13 in AS 65004) was installed into our routing table:

R1# show ip route | include 192.168.3.0
B    192.168.3.0/24 [20/0] via 192.168.0.13, 00:01:56
R1#

And that’s all there it is to it!

http://evilrouters.net/2008/11/30/using-weights-to-influence-bgp-routing/

Advertising a default route over BGP

2012-06-14T11:41:00.000+07:00

After a little hiatus, I’m back with another post. Today (or tonight, in my neck of the woods), I’m writing about how to advertise a default route to a BGP peer. Our topology looks like this:

This is a typical hub-and-spoke frame-relay network, with R3 having a point-to-point connection to each of R4 and R5. For this scenario, let’s assume that R3 is an ISP router and that R4 and R5 each belong to a customer that is single-homed to the ISP. For whatever reason, R4 and R5 has chosen to use BGP for routing, but they do not need (or perhaps cannot handle) the full routing table.

I’m including the initial configurations of the routers for clarity and those who wish to follow along. Explaining them, however, is outside the scope of this article. If you do not understand the frame-relay configurations, you may want to read through my “Basic Frame Relay Lab“.

Let’s get started by configuring the frame-relay connections on the three routers:

R3# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)# interface serial 0/0
R3(config-if)# no ip address
R3(config-if)# encapsulation frame-relay
R3(config-if)# no frame-relay inverse-arp
R3(config-if)# no shutdown
R3(config-if)# interface serial 0/0.4 point-to-point
R3(config-subif)# frame-relay interface-dlci 304
R3(config-fr-dlci)# ip address 172.16.34.3 255.255.255.0
R3(config-subif)# interface serial 0/0.5 point-to-point
R3(config-subif)# frame-relay interface-dlci 305
R3(config-fr-dlci)# ip address 172.16.35.3 255.255.255.0

R4# conf t
R4(config)# interface serial 0/0
R4(config-if)# no ip address
R4(config-if)# encapsulation frame-relay
R4(config-if)# no frame-relay inverse-arp
R4(config-if)# no shutdown
R4(config-if)# interface serial 0/0.3 point-to-point
R4(config-subif)# frame-relay interface-dlci 403
R4(config-fr-dlci)# ip address 172.16.34.4 255.255.255.0

R5# conf t
R5(config)# interface serial 0/0
R5(config-if)# no ip address
R5(config-if)# encapsulation frame-relay
R5(config-if)# no frame-relay inverse-arp
R5(config-if)# no shutdown
R5(config-if)# interface serial 0/0.3 point-to-point
R5(config-subif)# frame-relay interface-dlci 503
R5(config-fr-dlci)# ip address 172.16.35.5 255.255.255.0

Verify reachability:

R3# ping 172.16.34.4

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

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

In addition to the physical networks (172.16.34.0/24 and 172.16.35.0/24), we’re also going to advertise the loopback addresses into BGP, so let’s configure those interfaces now:

R3(config)# interface loopback 0
R3(config-if)# ip address 172.16.33.1 255.255.255.0

R4(config)# interface loopback 0
R4(config-if)# ip address 172.16.44.1 255.255.255.0

R5(config)# interface loopback 0
R5(config-if)# ip address 172.16.55.1 255.255.255.0

Now that we have the basics out of the way, we can bring up our BGP adjacencies. We’re not going to advertise any routes yet, just get the connections up:

R3(config)# router bgp 33
R3(config-router)# neighbor 172.16.34.4 remote-as 44
R3(config-router)# neighbor 172.16.35.5 remote-as 55

R4(config)# router bgp 44
R4(config-router)# neighbor 172.16.34.3 remote-as 33

R5(config)# router bgp 55
R5(config-router)# neighbor 172.16.35.3 remote-as 33

After a moment, you should see syslog messages showing that the adjacencies have come up. Let’s take a look:

R3# sh ip bgp summary
BGP router identifier 172.16.33.1, local AS number 33
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.34.4     4    44       7       7        1    0    0 00:03:46        0
172.16.35.5     4    55       5       5        1    0    0 00:01:28        0

Looks like we’re good so far. Let’s advertise the physical networks as well as our loopbacks on each router:

R3(config)# router bgp 33
R3(config-router)# network 172.16.33.0 mask 255.255.255.0
R3(config-router)# network 172.16.34.0 mask 255.255.255.0
R3(config-router)# network 172.16.35.0 mask 255.255.255.0

R4(config)# router bgp 44
R4(config-router)# network 172.16.44.0 mask 255.255.255.0

R5(config)# router bgp 55
R5(config-router)# network 172.16.55.0 mask 255.255.255.0

Give it a moment and let the updates get sent out, then take a look at the BGP tables on R4 and R5:

R4# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.33.0/24   172.16.34.3              0             0 33 i
r> 172.16.34.0/24   172.16.34.3              0             0 33 i
*> 172.16.35.0/24   172.16.34.3              0             0 33 i
*> 172.16.44.0/24   0.0.0.0                  0         32768 i
*> 172.16.55.0/24   172.16.34.3                            0 33 55 i

R5# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.33.0/24   172.16.35.3              0             0 33 i
*> 172.16.34.0/24   172.16.35.3              0             0 33 i
r> 172.16.35.0/24   172.16.35.3              0             0 33 i
*> 172.16.44.0/24   172.16.35.3                            0 33 44 i
*> 172.16.55.0/24   0.0.0.0                  0         32768 i

So we can see that our routes are being propagated via BGP. Notice something, though? Every (non-directly connected) route on R4 and R5 is through R3. Since we have to go through R3 to get to any routes (that aren’t internal), we might as well use R3 as our default gateway and save our router some work, yeah? We can easily replace a few of these routes with a default route (which is the whole point of this article anyway), so let’s do it.

To accomplish this, we tell R3 to originate a default route and advertise it to both R4 and R5. This is easily done with the “neighbor a.b.c.d default-originate” command.

R3(config)# router bgp 33
R3(config-router)# neighbor 172.16.34.4 default-originate
R3(config-router)# neighbor 172.16.35.5 default-originate

Let’s look at our BGP tables on R4 and R5 now:

R4# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          172.16.34.3                            0 33 i
*> 172.16.33.0/24   172.16.34.3              0             0 33 i
r> 172.16.34.0/24   172.16.34.3              0             0 33 i
*> 172.16.35.0/24   172.16.34.3              0             0 33 i
*> 172.16.44.0/24   0.0.0.0                  0         32768 i
*> 172.16.55.0/24   172.16.34.3                            0 33 55 i

R5# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          172.16.35.3                            0 33 i
*> 172.16.33.0/24   172.16.35.3              0             0 33 i
*> 172.16.34.0/24   172.16.35.3              0             0 33 i
r> 172.16.35.0/24   172.16.35.3              0             0 33 i
*> 172.16.44.0/24   172.16.35.3                            0 33 44 i
*> 172.16.55.0/24   0.0.0.0                  0         32768 i

Well, there’s our default route … wait, why are those other routes still there? Well, they are still being advertised by R3 so they end up in our BGP tables. We need to prevent them from getting there in the first place. One way to do this is to filter the routes as they come in (on R4 and R5). This is inefficient, however, as the ISP is still advertising them to us and our router must still receive and process them (before ultimately discarding them). A much better way to handle this is to have the ISP not advertise those routes to us in the first place.

There are (at least) two ways of doing this, from the R3 (ISP) side. The first is to use an as-path filter and the other involves a route-map.

We’ll use “ip as-path” to filter out all routes from being advertised to R4 (note that this does not affect a default route) then clear the BGP connection:

R3(config)# ip as-path access-list 1 deny .*
R3(config)# router bgp 33
R3(config-router)# neighbor 172.16.34.4 filter-list 1 out
R3(config-router)# do clear ip bgp 172.16.34.4

Give the adjacency time to re-establish, then take another look at the BGP table:

R4# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          172.16.34.3                            0 33 i
*> 172.16.44.0/24   0.0.0.0                  0         32768 i

Let’s verify that we can ping R5′s loopback (172.16.55.1) from R4′s (172.16.44.1):

R4# ping 172.16.55.1 source 172.16.44.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.55.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.44.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

Now, let’s get rid of all those “extras” routes we’re advertising to R5 as well. This time, however, we’ll use an access-list and a route-map to do the job. First, though, let’s verify what routes R3 is actually sending to R5:

R3# sh ip bgp neighbor 172.16.35.5 advertised-routes
BGP table version is 8, local router ID is 172.16.33.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

  Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.33.0/24   0.0.0.0                  0         32768 i
*> 172.16.34.0/24   0.0.0.0                  0         32768 i
*> 172.16.35.0/24   0.0.0.0                  0         32768 i
*> 172.16.44.0/24   172.16.34.4              0             0 44 i

We can easily see that a total of four BGP routes as well as a default route (“Originating default network 0.0.0.0″) are being advertised. Let’s cut that down to just the default route:

R3(config)# access-list 1 deny any
R3(config)# route-map FILTER_ALL_R5 permit 10
R3(config-route-map)# match ip address 1
R3(config-route-map)# router bgp 33
R3(config-router)# neighbor 172.16.35.5 route-map FILTER_ALL_R5 out
R3(config-router)# do clear ip bgp 172.16.35.5

Again, wait for the adjacency to come up and then let’s take a look at what routes R3 is sending to R5:

R3# sh ip bgp neighbor 172.16.35.5 advertised-routes
BGP table version is 10, local router ID is 172.16.33.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

  Network          Next Hop            Metric LocPrf Weight Path

Well, lookie there, with the exception of the default route, no routes are being advertised to R5. Let’s take a look at the BGP table from R5′s point of view:

R5# sh ip bgp | be Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          172.16.35.3                            0 33 i
*> 172.16.55.0/24   0.0.0.0                  0         32768 i

As you can see, the only routes in the BGP table are the (locally originated) route for 172.16.55.0/24 and the default route. Just for good measure, let’s take a look at the whole routing table:

R5# sh ip route | be Gateway
Gateway of last resort is 172.16.35.3 to network 0.0.0.0

    172.16.0.0/24 is subnetted, 2 subnets
C       172.16.55.0 is directly connected, Loopback0
C       172.16.35.0 is directly connected, Serial0/0.3
B*   0.0.0.0/0 [20/0] via 172.16.35.3, 00:03:07

And there you have it — our directly connected routes and our default route (received via BGP). Let’s verify that we can still have connectivity between R4 and R5′s loopbacks:

R5# ping 172.16.44.1 source 172.16.55.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.44.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.55.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

Refer to http://evilrouters.net/

BGP load sharing, dual-homed to one SP

2012-06-14T11:35:00.000+07:00

Here’s another lab that I just made up using dynamips and dynagen. There is a download link to the .net file I used (modify it as needed) at the bottom of this post.

NOTE: See the video demonstration below!

For this lab, here’s the topology we’re working with:

Our scenario here is pretty basic. We are AS 65065 and are dual-homed to our service provider, AS 65001. We have two T-1 connections: R1 to R2 and R1 to R3. We’re running BGP with our service provider and we would like to load share our outgoing traffic over these two T-1 connections. Fortunately, Cisco provides us with an easy way to do this.

As you may already know, BGP will, by default, only install the one best path into the routing table. In our case, that means that we would only be utilizing one connection at a given time. That’s not exactly the best use of our available bandwidth. The “maximum-paths” command is our friend.

From the Cisco IOS IP Command Reference:

“To configure the maximum number of parallel routes that an IP routing protocol will install into the routing table, use the maximum-paths command in router configuration or address family configuration mode. To restore the default value, use the no form of this command.”

Here are our starting configurations for R2 and R3:

R2:

interface fastethernet 0/0
ip address 172.16.23.2 255.255.255.0
no shutdown
interface serial 1/1
ip address 172.16.12.2 255.255.255.0
no shutdown
router bgp 65001
network 172.16.12.0 mask 255.255.255.0
network 172.16.23.0 mask 255.255.255.0
neighbor 172.16.12.1 remote-as 65065
neighbor 172.16.23.3 remote-as 65001
neighbor 172.16.23.3 next-hop-self
end

R3:

interface fastethernet 0/0
ip address 172.16.23.3 255.255.255.0
no shutdown
interface serial 1/0
ip address 172.16.13.3 255.255.255.0
no shutdown
router bgp 65001
network 172.16.13.0 mask 255.255.255.0
network 172.16.23.0 mask 255.255.255.0
neighbor 172.16.13.1 remote-as 65065
neighbor 172.16.23.2 remote-as 65001
neighbor 172.16.23.2 next-hop-self
end

The interface configuration for R1 is pretty standard and simple, with perhaps one exception:

interface serial 1/0
ip address 172.16.13.1 255.255.255.0
ip load-sharing per-packet
no shutdown
interface serial 1/1
ip address 172.16.12.1 255.255.255.0
ip load-sharing per-packet
no shutdown

Note the use of “ip load-sharing per-packet”. Cisco’s default is to use per-destination load sharing. You’ll want to evaluate your network to decide which is best for you.

Now, let’s configure BGP on R1 and we’re practically done:

router bgp 65065
maximum-paths 2
neighbor 172.16.12.2 remote-as 65001
neighbor 172.16.13.3 remote-as 65001

The only thing left to do is test and verify. See how I did it in the video below:

Download the dynagen .NET file

Refer to http://evilrouters.net/

Configuring MD5 Authentication for BGP Peers

2012-06-14T11:24:00.000+07:00

I got an e-mail recently from a reader who asked me about how to set up MD5 authentication between a pair of BGP peers, so I thought I’d do a quick write-up and example.

Setting up MD5 authentication is really simple. For our example, we’ll use a pair of routers connected over their serial 0/0 interfaces:

In addition to the addressing information in the diagram:

we’ll configure R5′s loopback 0 interface with IP address 5.5.5.5/24,
we’ll configure R7′s loopback 0 interface with IP address 7.7.7.7/24,
we’ll advertise both of those networks in BGP,
R5 is in AS 65005 and R7 is in AS 65007, and
we’ll use a password of “8F3NHBrisX”.

This is nearly identical to a previous write-up, “Configuring Basic BGP“, with the authentication added in.

First, let’s configure the loopback 0 interfaces:

R5# configure terminal
R5(config)# interface loopback 0
R5(config-if)# ip address 5.5.5.5 255.255.255.0

R7# configure terminal
R7(config)# interface loopback 0
R7(config-if)# ip address 7.7.7.7 255.255.255.0

Now bring up the connection between R5 and R7:

R5(config)# interface serial 0/0
R5(config-if)# ip address 172.16.57.5 255.255.255.0
R5(config-if)# no shutdown

R7(config-if)# interface serial 0/0
R7(config-if)# ip address 172.16.57.7 255.255.255.0
R7(config-if)# no shutdown

Make sure we have connectivity:

R5(config-if)# do ping 172.16.57.7

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

Now we can begin configuring BGP. R5 will be in AS 65005, advertise the 5.5.5.0/24 network, and peer with 172.16.57.7 (AS 65007) using our password “8F3NHBrisX”:

R5(config-if)# router bgp 65005
R5(config-router)# network 5.5.5.0 mask 255.255.255.0
R5(config-router)# neighbor 172.16.57.7 remote-as 65007
R5(config-router)# neighbor 172.16.57.7 password 8F3NHBrisX

We’ll configure R7 in a similar manner. It is in AS 65007, will advertise the 7.7.7.0/24 network, and peer with 172.16.57.5 (AS 65005) using the same password:

R7(config-if)# router bgp 65007
R7(config-router)# network 7.7.7.0 mask 255.255.255.0
R7(config-router)# neighbor 172.16.57.5 remote-as 65005
R7(config-router)# neighbor 172.16.57.5 password 8F3NHBrisX

We’ll see the BGP adjacency come up…

R7(config-router)#
*Mar  1 00:05:31.191: %BGP-5-ADJCHANGE: neighbor 172.16.57.5 Up

…and can see that we’re exchanging routes:

R7(config-router)# do show ip route bgp
    5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [20/0] via 172.16.57.5, 00:01:07

We should now be able to ping loopback to loopback:

R7(config-router)# do ping 5.5.5.5 source 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Using BGP communities to influence routing

2012-06-14T10:27:00.000+07:00

Previously I’ve covered using weight, local preference, and AS path prepending to influence routing between autonomous systems running BGP. Today we’ll look at one of the common methods for influencing routing, and that is BGP community values.

BGP communities are simply values attached to a route that is sent to BGP peers. This values have special meanings to the peers and cause specific actions to be taken, depending upon the values assigned. A customer who is multi-homed to a service provider can often use communities to tell the service provider how to route traffic to the customer autonomous system (AS).

For this example, let’s assume the following topology:

We are the customer (AS 65065) and R1 is our router. We are multi-homed to our service provider (AS 65001) with a 100 Mbit/s connection to R2 and a T-1 connection to R3. R2 and R3 are connected over a 100 Mbit/s connection as well.

Since the IP addresses being used are not illustrated in the diagram, here is a table with the IP addresses we are using:

ROUTER    INTERFACE    IP/MASK
--------------------------------------

R1        Fa0/0        172.16.12.1/24
         Se1/0        172.16.13.1/24
R2        Fa0/0        172.16.12.2/24
         Fa1/0        172.16.23.2/24
R3        Fa0/0        172.16.23.3/24
         Se1/0        172.16.13.3/24

In addition, our router (R1) has four loopback interfaces (Loopback0, Loopback1, Loopback2, and Loopback3) with the following IP addresses assigned, respectively: 172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24.

Okay, so let’s get our loopbacks configured and IP connectivity up between R1/R2 and R1/R3:

R1# conf t
R1(config)# interface loopback 0
R1(config-if)# ip address 172.31.0.1 255.255.255.0
R1(config-if)# interface loopback 1
R1(config-if)# ip address 172.31.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 172.31.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 172.31.3.1 255.255.255.0
R1(config-if)# interface fa0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# interface se1/0
R1(config-if)# ip address 172.16.13.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

Let’s make sure we can ping both R2 and R3:

R1# ping 172.16.12.2

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

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

Alright, so far, so good. We have four networks that we want to advertise into BGP — the four /24 subnets assigned to our loopback interfaces. Before we do this, however, let’s take another look at our topology. Recall that we have connections into AS 65001: a 100 Mbit/s connection to 172.16.12.2 and a 1.544 Mbit/s connection to 172.16.13.3. Sure would be nice if we could tell AS 65001 to send our traffic over that 100 Mbit/s connection, wouldn’t it? Well, we can!

Our service provider, AS 65001, allows us to use the communities attribute of BGP to influence how they route our traffic. In this (simplified) example, there are three different communities we can use:

200: set local preference to 200
500: set local preference to 500

If we send routes to AS 65001 with a community of 65001:200, the SP’s routers will set the local preference on those routes to 200. If we send routes to AS 65001 with a community of 65001:500, the SP’s routers will set the local preference on those routes to 500. How handy is that?

Because of how the BGP best path selection algorithm works, we want our SP’s routers to assign a higher local preference to the routes it receives from us over that 100 Mbit/s connection, so we’ll send those routes with a community of 65001:500. Just for good measure, we’ll attach community 65001:200 to the routers we send to 172.16.13.3 over the T-1 connection as well.

Let’s go ahead and set up BGP, but don’t start advertising any routes just yet:

R1(config)# ip bgp-community new-format
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 next-hop-self
R1(config-router)# neighbor 172.16.12.2 send-community
R1(config-router)# neighbor 172.16.13.3 remote-as 65001
R1(config-router)# neighbor 172.16.13.3 next-hop-self
R1(config-router)# neighbor 172.16.13.3 send-community

We are all set to begin advertising our routes, with the appropriate communities attached. The next thing we need to do is create a pair of route maps. We’ll apply these route maps outbound to the BGP peers and these are what we will use to attach our communities to the routes:

R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500

Lookin’ good so far, right? Let’s apply those route map to our BGP peers:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# neighbor 172.16.13.3 route-map LOCAL_PREF_200 out

That was easy enough. Now, let’s advertise those loopbacks:

R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0

Let’s take a look at how the SP sees our routes:

R2# sh ip bgp | in 65065
*> 172.31.0.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    500      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    500      0 65065 i

R3# sh ip bgp | in 65065
*>i172.31.0.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.1.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.2.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i
*>i172.31.3.0/24    172.16.23.2              0    500      0 65065 i
*                   172.16.13.1              0    200      0 65065 i

If we ping/traceroute from R3 to one of R1′s loopbacks, we should see that traffic first passes to R2 before being sent to R1 (which is our goal):

R3# ping 172.31.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/36 ms
R3# traceroute 172.31.0.1

Type escape sequence to abort.
Tracing the route to 172.31.0.1

 1 172.16.23.2 4 msec 12 msec 16 msec
 2 172.16.12.1 16 msec *  32 msec

Success!

Refer to http://evilrouters.net/

Using BGP’s MED to influence inbound routing

2012-06-14T10:00:00.001+07:00

If you remember how BGP’s best path selection algorithm works, you’ll likely remember hearing about the multi-exit discriminator, or MED. The MED is an optional, non-transitive attribute of BGP. When we have multiple entry points (connections) to another AS, this allows us to tell the other AS how we would like them to route traffic to us. Remember that, unlike weight and local preference, lower MEDs are preferred over higher MEDs.

For this lab, we have three routers set up in the following topology:

R1 (AS 65065) is our router and R2 and R3 (AS 65001) belong to our ISP. We’re going to assume that the connection between R1 and R2 is a 1.544 Mbps and that the connection between R1 and R3 is 768 kbps. We would like AS 65001 to use the faster connection (R1-R2) when sending traffic to us, and only use the R1-R3 connection as a backup. The IP network 1.1.1.0/24 has been assigned to us, and we will advertise that into BGP on R1.

First, I’ve configured a number of things previously:

all connections between routers
BGP on R2 and R3 (including the iBGP peering)
the loopback0 interface on R1 (with IP address 1.1.1.1/24)

With all this already configured, we can jump straight into the basic BGP configuration on R1:

R1(config)# router bgp 65065
R1(config-router)# network 1.1.1.0 mask 255.255.255.0
R1(config-router)# neighbor 172.16.12.1 remote-as 65001
R1(config-router)# neighbor 172.16.12.5 remote-as 65001

In a moment (remember, BGP is slooow to converge), we’ll see our neighbor relationships come up:

*Mar  1 03:52:45.519: %BGP-5-ADJCHANGE: neighbor 172.16.12.1 Up
*Mar  1 03:52:49.515: %BGP-5-ADJCHANGE: neighbor 172.16.12.5 Up

Now, let’s take a look at the BGP tables on both R2 and R3:

R2# sh ip bgp
BGP table version is 2, local router ID is 172.16.12.9
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
* i1.1.1.0/24       172.16.12.10             0    100      0 65065 i
*>                  172.16.12.2              0             0 65065 i

R3# sh ip bgp
BGP table version is 2, local router ID is 172.16.12.10
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
* i1.1.1.0/24       172.16.12.9              0    100      0 65065 i
*>                  172.16.12.6              0             0 65065 i

We can see that R3 is taking the direct path to R1 and R2 is taking the path through R3. This is contrary to what we stated earlier, “We would like AS 65001 to use the faster connection (R1-R2) when sending traffic to us …”. Let’s look into manipulating the MED to achieve our desired result.

The first thing we should do is begin creating an access list that matches the networks we are advertising into BGP. Since (for the sake of this example), our only network is 1.1.1.0/24, this is very simple and can be accomplished with just one access list entry:

R1(config-router)# exit
R1(config)# ip access-list standard BGP_NETWORKS
R1(config-std-nacl)# permit 1.1.1.0 0.0.0.255

Now we have an access list named BGP_NETWORKS that matches our 1.1.1.0/24 network. Next, we need to create a route-map that we can use to set the MED value, which is 0 by default. Since the lowest MED wins, all we need to do is ensure that we are sending a MED higher than 0 to R3. This will ensure that R2 has a lower MED than R3 and therefore AS 65001 will use R2 when sending traffic to us (AS 65065). Let’s create that route-map, have it match on our BGP\_NETWORKS access list, and set the MED to 100:

R1(config-std-nacl)# route-map MED_100 permit 10
R1(config-route-map)# match ip address BGP_NETWORKS
R1(config-route-map)# set metric 100

With our MED_100 route-map in place, we just need to apply it to our neighbor R3, and clear the BGP process:

R1(config-router)# neighbor 172.16.12.5 route-map MED_100 out
R1(config-router)# do clear ip bgp *

In short order, we’ll see our BGP adjacencies go down and then come back up:

*Mar  1 04:06:05.014: %BGP-5-ADJCHANGE: neighbor 172.16.12.1 Down User reset
*Mar  1 04:06:05.014: %BGP-5-ADJCHANGE: neighbor 172.16.12.5 Down User reset
*Mar  1 04:06:43.766: %BGP-5-ADJCHANGE: neighbor 172.16.12.5 Up
*Mar  1 04:06:48.154: %BGP-5-ADJCHANGE: neighbor 172.16.12.1 Up

Let’s take a look at the BGP tables on R3 now:

R3# sh ip bgp
BGP table version is 6, local router ID is 172.16.12.10
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
*>i1.1.1.0/24       172.16.12.9              0    100      0 65065 i
*                   172.16.12.6            100             0 65065 i

We can see that R3 is receiving the 1.1.1.0/24 route from R2 (172.16.12.9) with a metric of 0 and from R1 (172.16.12.6) with a metric of 100. Also, note that BGP has now decided the best path to the 1.1.1.0/24 network is through R2.

Refer to http://evilrouters.net/

Using AS path prepending to influence inbound routing

2012-06-14T09:31:00.001+07:00

As you may remember, the BGP Best Path Algorithm decides how the best path to an autonomous system is selected. Probably the most common value that is used to determine the best path is the AS Path length. When two or more routes exist to reach a particular prefix the default in BGP is to prefer the route with the shortest AS Path length.

If we are a multi-homed customer of one or more service providers, we may prefer that incoming traffic take a particular path to reach our network. Perhaps we have two connections, but one costs only half as much as the other. Or, we may have one fast connection and another, much slower connection that we really only want to use a “backup” if our primary connection is down. Regardless of your reasons, AS path prepending is probably the easiest method that one can use to influence inbound routing to your autonomous system.

Consider the following topology:

In this example, we are AS 67. We are multi-homed to our service providers, AS 88 and AS 99, and have a T1 connection to each. AS 88 and AS 99 also peer directly with each other, and have a 100 Mbit/s connection between them. Because we have been experiencing growth, we have added a third connection, a 100 Mbit/s link between R7 and R8

Due to this huge increase in bandwidth, we would prefer that all (or, at least, the majority) of our incoming traffic come in over this much faster Ethernet connection. Since we have a connection directly to R9, however, this results in a very short AS Path in the BGP table to our prefixes. AS 99 will, by default, send any traffic for AS 67 over this 1.5 Mbit/s T1 connection.

How can we cause R9 to, instead, send any traffic destined to AS 67 over the 100 Mbit/s connection to AS 88? In addition, how can we cause AS 88 to send any traffic destined to AS 67 over the 100 Mbit/s connection to R7 in AS 67? Remember that BGP, unlike some other routing protocols (e.g. EIGRP), does not take bandwidth into consideration when deciding on the best path.

The answer is to use AS Path prepending. When using AS Path prepending, we artificially lengthen the AS Path that we advertise to a neighbor to make them think that the path much longer than it actually is.

I’ve included here the initial configurations for each of the routers to get us to the point where we have established connectivity between all routers. Instead of explaining all these configurations, however, I’ll be jumping straight to the good stuff. It is assumed that, if you are playing with AS Path prepending, you have the requisite knowledge for understand the initial configurations.

Since the IP addresses being used are not illustrated in the diagram, here is a table with the IP addresses we are using:

ROUTER    INTERFACE    IP/MASK
--------------------------------------

R6        Fa0/0        172.31.67.6/24
        Se1/0        172.31.68.6/24
R7        Fa0/0        172.31.67.7/24
        Fa0/1        172.31.78.7/24
        Se1/0        172.31.79.7/24
R8        Fa0/0        172.31.89.8/24
        Fa0/1        172.31.78.8/24
        Se1/0        172.31.68.8/24
R9        Fa0/0        172.31.89.9/24
        Se1/0        172.31.79.9/24

In addition, each router has a loopback address (with a /24 mask). These /24 networks are being advertised into BGP. The loopback addresses are what we’ll use for testing and verifying proper operation.

Okay, so now that we have basic connectivity, we can get down to the fun stuff. First, let’s get out iBGP adjacency between R6 and R7 up and running and start advertising our loopbacks:

R6(config)# router bgp 67
R6(config-router)# network 172.16.66.0 mask 255.255.255.0
R6(config-router)# neighbor 172.31.67.7 remote-as 67
R6(config-router)# neighbor 172.31.67.7 next-hop-self
R6(config-router)# neighbor 172.31.67.7 soft-reconfiguration inbound

R7(config)# router bgp 67
R7(config-router)# network 172.16.67.0 mask 255.255.255.0
R7(config-router)# neighbor 172.31.67.6 remote-as 67
R7(config-router)# neighbor 172.31.67.6 next-hop-self
R7(config-router)# neighbor 172.31.67.6 soft-reconfiguration inbound

Verification:

R6# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.66.0/24   0.0.0.0                  0         32768 i
*>i172.16.67.0/24   172.31.67.7              0    100      0 i

R7# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*>i172.16.66.0/24   172.31.67.6              0    100      0 i
*> 172.16.67.0/24   0.0.0.0                  0         32768 i

Let’s go ahead and get the eBGP adjacency between R8 and R9 in place:

R8(config)# router bgp 88
R8(config-router)# network 172.16.88.0 mask 255.255.255.0
R8(config-router)# neighbor 172.31.89.9 remote-as 99
R8(config-router)# neighbor 172.31.89.9 soft-reconfiguration inbound

R9(config)# router bgp 99
R9(config-router)# network 172.16.99.0 mask 255.255.255.0
R9(config-router)# neighbor 172.31.89.8 remote-as 88
R9(config-router)# neighbor 172.31.89.8 soft-reconfiguration inbound

Now, let’s establish eBGP between R6 and R8 over the T1 connection:

R6(config)# router bgp 67
R6(config-router)# neighbor 172.31.68.8 remote-as 88
R6(config-router)# neighbor 172.31.68.8 soft-reconfiguration inbound

R8(config)# router bgp 88
R8(config-router)# neighbor 172.31.68.6 remote-as 67
R8(config-router)# neighbor 172.31.68.6 soft-reconfiguration inbound

At this point, if we take a look at R9′s BGP tables, we can see that it now has routes for all of the loopback networks:

R9# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.66.0/24   172.31.89.8                            0 88 67 i
*> 172.16.67.0/24   172.31.89.8                            0 88 67 i
*> 172.16.88.0/24   172.31.89.8              0             0 88 i
*> 172.16.99.0/24   0.0.0.0                  0         32768 i

We can verify that we have connectivity between R6 and R9. First, we’ll ping, then a traceroute:

R9# ping 172.16.67.1 source 172.16.99.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.67.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.99.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
R9# traceroute 172.16.67.1 source 172.16.99.1

Type escape sequence to abort.
Tracing the route to 172.16.67.1

1 172.31.89.8 4 msec 4 msec 4 msec
2 172.31.68.6 8 msec 8 msec 12 msec
3 172.31.67.7 4 msec *  20 msec

Make a note of how the 172.16.66.0/24 and 172.16.67.0/24 networks appear in R9′s BGP table, specifically, the AS Path (we’ll be coming back to that shortly):

R9# sh ip bgp | in 172.16.6
*> 172.16.66.0/24   172.31.89.8                            0 88 67 i
*> 172.16.67.0/24   172.31.89.8                            0 88 67 i

In order for R9 to reach R7, it must pass traffic off to R8 (in AS 88). R8 then passes the traffic to R6 (in AS 67) and R6 will deliver it on to R7. Let’s bring up BGP over the T1 between R7 and R9 and see what happens:

R7(config)# router bgp 67
R7(config-router)# neighbor 172.31.79.9 remote-as 99
R7(config-router)# neighbor 172.31.79.9 soft-reconfiguration inbound

R9(config)# router bgp 99
R9(config-router)# neighbor 172.31.79.7 remote-as 67
R9(config-router)# neighbor 172.31.79.7 soft-reconfiguration inbound

Now’s let look at the same routes (172.16.66.0/24 and 172.16.67.0/24) in R9′s BGP table:

R9# sh ip bgp | in 172.16.6
*> 172.16.66.0/24   172.31.79.7                            0 67 i
*> 172.16.67.0/24   172.31.79.7              0             0 67 i

Notice the difference in the AS Path? Previously, the best (albeit, only) path R9 had to get to the 172.16.66.0/24 and 172.16.67.0/24 networks was through AS 88. Now there is a direct connection between AS 67 and AS 99 and this new path is shorter (direct, as opposed to traversing AS 88). Because the new path is shorter, it has been identified as the best path. Let’s run that traceroute again and see the difference:

R9# traceroute 172.16.67.1 source 172.16.99.1

Type escape sequence to abort.
Tracing the route to 172.16.67.1

1 172.31.79.7 4 msec *  28 msec

Now, let’s bring up BGP on the 100 Mbit/s connection between R7 and R8:

R7(config)# router bgp 67
R7(config-router)# neighbor 172.31.78.8 remote-as 88
R7(config-router)# neighbor 172.31.78.8 soft-reconfiguration inbound

R8(config)# router bgp 88
R8(config-router)# neighbor 172.31.78.7 remote-as 67
R8(config-router)# neighbor 172.31.78.7 soft-reconfiguration inbound

All of our BGP adjacencies are up at this point, and traffic is flowing normally. Now it’s time to start making it flow the way we want! Let’s take a look at R8′s BGP table, since it is receiving routes over three connections:

R8# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*  172.16.66.0/24   172.31.78.7                            0 67 i
*                   172.31.89.9                            0 99 67 i
*>                  172.31.68.6              0             0 67 i
*  172.16.67.0/24   172.31.78.7              0             0 67 i
*                   172.31.89.9                            0 99 67 i
*>                  172.31.68.6                            0 67 i
*> 172.16.88.0/24   0.0.0.0                  0         32768 i
*  172.16.99.0/24   172.31.78.7                            0 67 99 i
*                   172.31.68.6                            0 67 99 i
*>                  172.31.89.9              0             0 99 i

Note that AS 88 has two direct paths to AS 67′s advertised networks (172.16.66.0/24 and 172.16.67.0/24). This is evidenced by the AS Path’s for these two routes (“67 i”). AS 88 has picked the path with a next hop of 172.31.68.6, however. Recall that this is the direct T1 connection between R6 and R8. Why did it choose this path instead of the faster (100 Mbit/s) path?

Earlier I stated “…BGP, unlike some other routing protocols (e.g. EIGRP), does not take bandwidth into consideration when deciding on the best path.” Since the two paths are of the same length, R8 continues its way through the “Best Path Selection Algorithm” and eventually chooses the path that was received first. As we were configuring our BGP sessions earlier, we brought up the T1 connection first. AS 88, therefore, received the path from R6 before it did R7. We could bypass this by bringing up the 100 Mbit/s connection first, however this is not always under our control (think about when a router reloads — which connection will come up first? We really don’t know.)

Our best method, then, to influence the routing of traffic coming into our AS (and, indeed, the whole point of this article) is to manipulate the AS Path that we advertise to BGP neighbors. By causing AS 88 to think that the path to AS 67 over the T1 connection is much longer, we can get it to select the path via the 100 Mbit/s connection. We’ll also need to do the same thing to R9 in AS 99. Remember, we want AS 88 to send us traffic over that 100 Mbit/s connection, and we want AS 99 to send us traffic via AS 88.

This is much easier to configure than it might sound. We’ll use a route-map applied to (certain) outbound BGP sessions from AS 67 to do this for us. We’ll create a route-map named “PREPEND” on both R6 and R7 that will prepend our AS number twice to outgoing route advertisements, then apply it to the BGP sessions over the T1 connections (R6 to R8 and R7 to R9):

R6(config)# route-map PREPEND permit 10
R6(config-route-map)# set as-path prepend 67 67
R6(config-route-map)# router bgp 67
R6(config-router)# neighbor 172.31.68.8 route-map PREPEND out

R7(config)# route-map PREPEND permit 10
R7(config-route-map)# set as-path prepend 67 67
R7(config-route-map)# router bgp 67
R7(config-router)# neighbor 172.31.79.9 route-map PREPEND out

That’s all there is to it! Let’s examine R8′s BGP table now:

R8# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.66.0/24   172.31.78.7                            0 67 i
*                   172.31.68.6              0             0 67 67 67 i
*> 172.16.67.0/24   172.31.78.7              0             0 67 i
*                   172.31.68.6                            0 67 67 67 i
*> 172.16.88.0/24   0.0.0.0                  0         32768 i
*  172.16.99.0/24   172.31.78.7                            0 67 99 i
*                   172.31.68.6                            0 67 67 67 99 i
*>                  172.31.89.9              0             0 99 i

Look at the paths for 172.16.66.0/24 and 172.16.67.0/24. Note that the path received from 172.31.68.6 is much longer than the path received from 172.31.78.7. There are three AS numbers in the routes received from 172.31.68.6, even though it is the same AS number. Because this path is now much longer, the shorter path via 172.31.78.7 (our 100 Mbit/s connection) will now be the preferred way to get there.

Let’s see how R9 was affected by all of this:

R9# sh ip bgp | be Network
 Network          Next Hop            Metric LocPrf Weight Path
*  172.16.66.0/24   172.31.79.7                            0 67 67 67 i
*>                  172.31.89.8                            0 88 67 i
*  172.16.67.0/24   172.31.79.7              0             0 67 67 67 i
*>                  172.31.89.8                            0 88 67 i
*  172.16.88.0/24   172.31.79.7                            0 67 67 67 88 i
*>                  172.31.89.8              0             0 88 i
*> 172.16.99.0/24   0.0.0.0                  0         32768 i

We can see that R9 has received updated routing information as well, evidenced by the paths that are prepended. Now, instead of preferring the direct T1 connection into AS 67, R9 will send any traffic destined for AS 67 to 172.31.89.8 in AS 88. We already know from looking at R8′s BGP table that it will pass the traffic on to AS 67 over the 100 Mbit/s link. Let’s run traceroutes from R9 to verify:

R9# traceroute 172.16.66.1 source 172.16.99.1

Type escape sequence to abort.
Tracing the route to 172.16.66.1

1 172.31.89.8 4 msec 8 msec 8 msec
2 172.31.78.7 4 msec 8 msec 8 msec
3 172.31.67.6 12 msec *  36 msec
R9# traceroute 172.16.67.1 source 172.16.99.1

Type escape sequence to abort.
Tracing the route to 172.16.67.1

1 172.31.89.8 4 msec 4 msec 8 msec
2 172.31.78.7 4 msec *  36 msec

This shows us that traffic is behaving exactly as we intended. The first hop after leaving R9 is 172.31.89.8 (R8). It leaves R8 over the 100 Mbit/s connection arrives at 172.31.78.7 (R7). From there it is sent over R7′s 100 Mbit/s connection to R6 (172.31.67.6).

Success! Our job here is done!

Note: One thing that isn’t apparent from this exercise is the path that traffic from R6 (in AS 67) takes to get to R9 (in AS 99). To illustrate, let’s take a look at a traceroute from R6′s loopback to R9′s loopback:

R6# traceroute 172.16.99.1 source 172.16.66.1

Type escape sequence to abort.
Tracing the route to 172.16.99.1

1 172.31.67.7 4 msec 4 msec 8 msec
2 172.31.79.9 8 msec *  48 msec

Notice anything weird there? Yeah, traffic from R6 is first going to R7, then to R9 over that T1 connection, NOT the much faster 100 Mbit/s connection! How can we change that? The next article will continue on from here and we’ll change the configuration of our routers in AS 67 to address that.

Refer to http://evilrouters.net/

Monitoring and Troubleshooting Site-to-Site IPSec VPNs

2012-05-17T17:20:00.000+07:00

Cisco ASA comes with many show commands to check the health and status of the IPSec tunnels. For troubleshooting purposes, Cisco ASA provides a rich set of debug commands to isolate the IPSec-related issues.

Monitoring Site-to-Site VPNs

If you want to check the status of the IPSec tunnels, you can start by looking at Phase 1 SA state. You can type show crypto isakmp sa detail, as demonstrated in Example 15-30. If the ISAKMP negotiations are successful, you should see the state as MM_ACTIVE. It also displays the type of the IPSec tunnel and the negotiated Phase 1 policy.

Example 15-30. Output of show crypto isakmp sa detail

Chicago# show crypto isakmp sa detail

  Active SA: 1

   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: 209.165.201.1

   Type    : L2L             Role    : responder

   Rekey   : no              State   : MM_ACTIVE

   Encrypt : aes-256         Hash    : MD5

   Auth    : preshared       Lifetime: 86400

   Lifetime Remaining: 36536

You can also check the status of the IPSec SA by using the show crypto ipsec sa command, as shown in Example 15-31. It displays the negotiated proxy identities along with the actual number of packets encrypted and decrypted by the IPSec engine.

Example 15-31. Output of show crypto ipsec sa

Chicago# show crypto ipsec sa

interface: outside

   Crypto map tag: IPSec_map, local addr: 209.165.200.225



     local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)

     remote ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)

     current_peer: 209.165.201.1

     #pkts encaps: 2023, #pkts encrypt: 2023, #pkts digest: 2023

     #pkts decaps: 2112, #pkts decrypt: 2112, #pkts verify: 2112

     #pkts compressed: 0, #pkts decompressed: 0

     #pkts not compressed: 2023, #pkts comp failed: 0, #pkts decomp failed: 0

     #send errors: 0, #recv errors: 0



     local crypto endpt.: 209.165.200.225, remote crypto endpt.: 209.165.201.1



     path mtu 1500, ipsec overhead 60, media mtu 1500

     current outbound spi: 0B77BCE7



   inbound esp sas:

     spi: 0x4FEDC46D (1340982381)

        transform: esp-aes-256 esp-sha-hmac

        in use settings ={L2L, Tunnel, }

        slot: 0, conn_id: 1, crypto-map: IPSec_map

        sa timing: remaining key lifetime (kB/sec): (9276/28646)

        IV size: 16 bytes

        replay detection support: Y

   outbound esp sas:

     spi: 0x0B77BCE7 (192396519)

        transform: esp-aes-256 esp-sha-hmac

        in use settings ={L2L, Tunnel, }

        slot: 0, conn_id: 1, crypto-map: IPSec_map

        sa timing: remaining key lifetime (kB/sec): (9276/28644)

        IV size: 16 bytes

        replay detection support: Y

If a hardware encryption card is installed in the security Cisco ASA and you want to look at the counter information to monitor how many packets have gone through the card, you can type the show crypto accelerator statistics command, as demonstrated in Example 15-32.

Example 15-32. Output of show crypto accelerator statistics

Chicago# show crypto accelerator statistics

Crypto Accelerator Status

-------------------------

[Capability]

  Supports hardware crypto: True

  Supports modular hardware crypto: False

  Max accelerators: 1

  Max crypto throughput: 100 Mbps

  Max crypto connections: 750

[Global Statistics]

  Number of active accelerators: 1

  Number of non-operational accelerators: 0

  Input packets: 14606

  Input bytes: 3364752

  Output packets: 3648

  Output error packets: 0

  Output bytes: 3828341

[Accelerator 0]

  Status: OK

  Software crypto engine

  Slot: 0

  Active time: 286241 seconds

  Total crypto transforms: 7

[Accelerator 0]

  Status: OK

  Software crypto engine

  Slot: 0

  Active time: 286241 seconds

[Accelerator 1]

  Status: OK

  Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)

                            Boot microcode   : ?CNlite-MC-Boot-Cisco-1.2

                            SSL/IKE microcode: ?CNlite-MC-IPSEC-Admin-3.03

                            IPSec microcode  : ?CNlite-MC-IPSECm-MAIN-2.03

  Slot: 1

  Active time: 286242 seconds

  Total crypto transforms: 186516

  Total dropped packets: 0

  [Input statistics]

     Input packets: 14606

     Input bytes: 3364752

     Input hashed packets: 13060

     Input hashed bytes: 1165772

     Decrypted packets: 14606

     Decrypted bytes: 2655536

  [Output statistics]

     Output packets: 3648

     Output bad packets: 0

     Output bytes: 3828341

     Output hashed packets: 455

     Output hashed bytes: 61880

     Encrypted packets: 3648

     Encrypted bytess: 3747517

Troubleshooting Site-to-Site VPNs

If the IPSec tunnel is not working for some reason, make sure that you have the proper debug turned on. The two most important debug commands to look at are the following:

debug crypto isakmp [debug level 1-255]

and

debug crypto ipsec [debug level 1-255]

By default, the debug level is set to 1. You can increase the debug level up to 255 to get detailed logs. However, in most cases, setting the logging level to 127 gives enough information to determine the root cause of an issue.

Refer to Figure 15-1 for a site-to-site tunnel between the ASA in Chicago and London. To enforce learning, the ISAKMP and IPSec negotiations are discussed on the security Cisco ASA in Chicago. The following debug commands are enabled on the security Cisco ASA.

debug crypto isakmp 127

and

debug crypto ipsec 127

As mentioned in Chapter 1, the tunnel negotiations begin by exchanging the ISAKMP proposals. If the proposal is acceptable, the ASA displays the IKE SA proposal transform acceptable message, as shown in Example 15-33.

Example 15-33. Debugs to Show ISAKMP Proposal Is Acceptable

[IKEv1 DEBUG], IP = 209.165.201.1, processing SA payload

[IKEv1 DEBUG], IP = 209.165.201.1, Oakley proposal is acceptable

.....

[IKEv1 DEBUG], IP = 209.165.201.1, IKE SA Proposal # 1, Transform # 1 acceptable

 Matches global IKE entry # 5

Note

The VPN debugs messages on the security Cisco ASA are very similar to the log messages generated on the VPN 3000 Series Concentrators.

During the ISAKMP SA negotiations, the security Cisco ASA matches the IP address of the VPN peer with the tunnel group. If it finds a match, it displays a "Connection landed on tunnel group" message, as shown in Example 15-34, and continues with the rest of the negotiations (shown as ...). The Cisco ASA displays a "Phase 1 completed" message when the ISAKMP SA is successfully negotiated.

Example 15-34. Debugs to Show Phase 1 Negotiations Are Completed

[IKEv1]: IP = 209.165.201.1, Connection landed on tunnel_group 209.165.201.1

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, PHASE 1 COMPLETED

After completing Phase 1 negotiations, the security Cisco ASA maps the remote VPN peer to a static crypto map sequence number and checks the IPSec Phase 2 proposal sent by the remote VPN peers. If the received proxy identities and the IPSec Phase 2 proposals match on the security Cisco ASA, it displays an "IPSec SA proposal transform acceptable" message, as demonstrated in Example 15-35.

Example 15-35. Debugs to Show Proxy Identities and Phase 2 Proposals Are Accepted

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.30.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received remote IP Proxy Subnet

data in ID Payload:   Address  192.168.30.0, Mask 255.255.255.0, Protocol 0, Port 0

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, Processing ID

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.10.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received local IP Proxy Subnet

data in ID Payload:   Address  192.168.10.0, Mask 255.255.255.0, Protocol 0, Port 0

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map

IPSec_map, seq = 10 is a successful match

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, IKE Remote Peer configured for

SA: IPSec_map

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, processing IPSEC SA

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, IPSec SA Proposal # 1,

Transform # 1 acceptable Matches global IPSec SA entry # 10

After accepting the transform set, both VPN devices agree on the inbound and outbound IPSec SAs, as shown in Example 15-36. Once the IPSec SAs have been created, both VPN devices should be able to pass traffic bidirectionally across the tunnel.

Example 15-36. Debugs Showing IPSec SAs Are Activated

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, loading all IPSEC SAs

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Security negotiation complete

 for LAN-to-LAN Group (209.165.201.1) Responder, Inbound SPI = 0xf798f8e5,

 Outbound SPI = 0x56029210

The following four scenarios discuss how to troubleshoot the common issues related to IPSec tunnels. The debug messages are shown if debug crypto isakmp 127 is enabled on the security Cisco ASA.

ISAKMP Proposal Unacceptable

In this scenario, if the ISAKMP proposals are mismatched between the two VPN devices, the Cisco ASA Cisco ASA displays an "All SA proposals found unacceptable" message after processing the first main mode packet, as shown in Example 15-37.

Example 15-37. Debugs to Show Mismatched ISAKMP Policies

[IKEv1 DEBUG]: IP = 209.165.201.1,, processing SA payload

[IKEv1]: IP = 209.165.201.1, IKE DECODE SENDING Message (msgid=0) with payloads :

 HDR + NOTIFY (11) + NONE (0) total length : 96

[IKEv1 DEBUG]: IP = 209.165.201.1, All SA proposals found unacceptable

Mismatched Preshared keys

If the preshared key is mismatched between the VPN devices, the Cisco ASA Cisco ASA displays a "Error, had problems decrypting packet, probably due to mismatched pre-shared key" message after processing the fourth main mode packet. This is shown in Example 15-38.

Example 15-38. Debugs to Show Mismatched Preshared Keys

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1Received encrypted Oakley Main

 Mode packet with invalid payloads, MessID = 0

[IKEv1]: IP = 209.165.201.1, IKE DECODE SENDING Message (msgid=0) with payloads :

 HDR + NOTIFY (11) + NONE (0) total length : 104

IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, ERROR, had problems decrypting

 packet, probably due to mismatched pre-shared key.  Aborting

Incompatible IPSec Transform Set

The security Cisco ASA displays an "All IPSec SA proposals found unacceptable" if the IPSec transform set is mismatched between the VPN devices. In this case, the Phase 1 SA gets established and the VPN devices fail to negotiate the IPSec SA. The Cisco ASA checks the validity of the crypto map before rejecting the IPSec SA, as shown in Example 15-39.

Example 15-39. Debugs When Incompatible IPSec Transform Set Is used

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

 checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map

 IPSec_map, seq = 10 is a successful match

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, IKE Remote Peer configured for

 SA: IPSec_map

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, processing IPSEC SA

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, All IPSec SA proposals found

 unacceptable!

Mismatched Proxy Identities

If the encryption ACL on the security Cisco ASA does not match the encryption ACL offered by the other end of the VPN tunnel, the Cisco ASA rejects the IPSec SA and displays a "Crypto Map Policy not found" error with the associated local and remote subnets that the remote VPN device offered. In Example 15-40, the VPN peer 209.165.201.1 wants to negotiate IPSec SAs between 192.168.20.0 and 192.168.30.0, which the security Cisco ASA rejects because the received identities do not match the configured crypto ACL.

Example 15-40. Debugs to Show Mismatched Proxy Identities

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.30.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received remote IP Proxy Subnet

 data in ID Payload:  Address 192.168.30.0,  Mask 255.255.255.0, Protocol 0, Port 0

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, Processing ID

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.20.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received local IP Proxy Subnet

 data in ID Payload:  Address 192.168.20.0,  Mask 255.255.255.0, Protocol 0, Port 0

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

 checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map =

 IPSec_map, seq = 10, ACL does not match proxy IDs src:192.168.30.0

 dst:192.168.20.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Tunnel rejected: Crypto Map

 Policy not found for Src:192.168.30.0, Dst: 192.168.20.0!

Summary

Everyday, more and more organizations are deploying IPSec site-to-site tunnels to cut costs on traditional WAN links. It is a responsibility of the security professional to design and implement an IPSec solution that will fit the needs of an organization. If the other end of the IPSec VPN tunnel is managed by a different security professional, make sure that you consult with them before configuring the ISAKMP and IPSec attributes in the ASA. This chapter discussed the configuration guide on how to implement the site-to-site tunnels and discussed the two deployment scenarios. If you implement the solution, and the IPSec tunnel is not working as expected, use the appropriate show commands and monitor the status of the SAs. You can also turn on the ISAKMP and IPSec debugs to help narrow down the issue.

Undocumented Cisco Commands

2012-05-10T21:04:00.002+07:00

The data in this document has been gathered from a variety of sources:

Project DOTU
Undocumented IOS and Catalyst Commands on Heinz Ulm's web site
Undocumented IOS commands at www.i-n-t.de (site no longer available)
cisco-nsp and cisco-nas mailing lists
Cisco.com
contributions from Cisco users
...and some which I can't remember

If you have any suggestions or additions to this list please contact him at lf@elemental.net.

Index
[no] ip spd queue {min-threshold \| max-threshold} (IOS)	show banff-reset (XID/CatOS, Catalyst 5000 series with NFFC)
[no] spd enable (IOS)	show caller (IOS)
aaa accounting delay-start (IOS)	show chunk [summary] (IOS)
aaa authorization console (IOS (>= 12.1(10.6)))	show controller switch (Cat 2900XL/3500XL, IOS)
aaa pod server [port ] [auth-type {any \| all \| session-key}] server-key (IOS (>= 11.3(7)AA))	show epc ... (IOS)
ais-enable (IOS)	show epc acl lookup {in\|out} ... (IOS (Cat 2948G-L3, 4908G-L3, 8540))
arap logging debug-extensions (IOS)	show epc acl tcam2acl interface {in\|out} (IOS (Cat 2948G-L3, 4908G-L3, 8540))
bgp common-administration (IOS)	show epc ip-address interface all-entries (IOS (Cat 2948G-L3))
bgp maxas-limit <1 - 2000> (IOS)	show epc patricia ipucast detail (IOS)
bgp redistribute-internal (IOS)	show epc patricia mac (IOS (Cat 2948G-L3, 4908G-L3))
bridge-group subscriber-loop-control (IOS)	show idb (IOS)
clear ip eigrp [] events (IOS)	show inband (XID/CatOS)
clear ip eigrp [] logging (IOS)	show interface cable /0 privacy statistic (IOS)
clock source free-running\|line primary (IOS)	show interfaces [] stats (IOS)
csim (IOS)	show interfaces [] switching (IOS)
debug buffer (IOS)	show ip cef [ []] internal (IOS)
debug crypto isakmp detail (IOS)	show ip eigrp events [] [] [] (IOS)
debug crypto isakmp packet (IOS)	show ip eigrp sia-event (IOS)
debug dialer detailed (IOS)	show ip eigrp timers [] (IOS)
debug dialer holdq (IOS)	show ip ospf bad-checksum (IOS)
debug ip ospf monitor (IOS)	show ip ospf delete-list (IOS)
debug ip packet [detail] [] dump (IOS)	show ip ospf events (IOS)
debug isdn q931 l3 (IOS)	show ip ospf maxage-list (IOS)
debug mica {tx\|rx} / (IOS)	show ip ospf statistic (IOS)
debug modem csm (IOS)	show ip route hash (IOS)
debug oir (IOS)	show ip route profile (IOS)
debug parser mode (IOS)	show ip spd (IOS)
debug sanity (IOS)	show isdn memory detail (IOS)
dialer disable-multiencaps (IOS)	show isdn service [ \| ] detail (IOS)
dialer mult-map-same-name (IOS)	show isdn status detail (IOS)
eigrp event-log-site (IOS)	show isis private (IOS)
eigrp event-logging (IOS)	show isis timers (IOS)
eigrp kill-everyone (IOS)	show isis tree (IOS)
eigrp log-event-type [dual] [xmit] [transport] (IOS)	show list [none] (IOS)
enable engineer (XDI/CatOS)	show mbuf (XID/CatOS)
frame-relay fecn-create (IOS)	show memory big (IOS)
gdb {kernel \| pid \| {examine \| debug} } (IOS)	show mls nfde (XID/CatOS)
h323 h245 tunnel defer (IOS)	show mls status (Cat 6000 Native IOS)
if-console [console\|debug] (7000/7500 Series, IOS)	show mmc np5400 [config\|flows\|get\|indications\|ports\|queue\|registers\|stat\|send] [...] (IOS (Cat 2948G-L3, 4908G-L3))
ip cache-ager (IOS (>=10.3(8) and >=11.0(3)))	show mpls interfaces internal all (IOS)
ip cache-invalidate-delay (IOS (>=10.3(8) and >=11.0(3)))	show msfc (IOS (Cat 6k hybrid))
ip ospf interface-retry (IOS)	show msfc (CatOS (Cat 6k hybrid))
ip route profile (IOS)	show msfc nvram (IOS (Cat 6k hybrid))
ipc-console (Catalyst 6000/6500 Series, IOS)	show parser modes (IOS)
ipx sap-interval {\|passive} (IOS (>=11.2))	show parser unresolved (IOS)
ipx server-split-horizon-on-server-paths (IOS)	show polaris fibmgr usage (CatOS (Cat 6k hybrid))
ipx update interval {rip \| sap} passive (IOS (>=11.3(1.3)))	show region (IOS)
isdn incoming progress [validate\|accept] (IOS (>= 12.1(3.3)T))	show region address (IOS)
modem-mgmt csm debug rbs (IOS)	show slip (IOS)
mpls traffic-eng multicast-intact (IOS)	show snmp chassis (IOS)
multilink queuing bypass-fifo (IOS)	show snmp community (IOS)
neighbor don't-capability-negotiate (IOS)	show snmp host (IOS)
no logging snmp-authfail (IOS)	show snmp location (IOS)
no ppp microcode (IOS)	show snmp mib (IOS)
no snmp-server sparse-tables (IOS)	show snmp newcom (IOS)
ppp dnis [ ...] (IOS)	show snmp notify (IOS)
ppp ipcp accept-address (IOS)	show sum (IOS)
ppp ipcp dns\|wins {accept \| a.b.c.d [e.f.g.h] [accept]} (IOS)	show sum (IOS)
ppp ipcp ignore-map (IOS)	show tcam ... (Cat 6000 Native IOS)
ppp ipcp unique-address (IOS)	snmp-server priority {low \| normal \| high} (IOS)
ppp max-configure (IOS)	spd headroom (IOS)
priv ()	tcam priority high\|low\|medium (Cat 6000 Native IOS)
ps -c (XDI/CatOS)	test aaa group radius (IOS)
radius send service-type call-check (IOS (>= 12.1(4)T))	test aim eeprom slot (IOS)
radius-server authorization default Framed-Protocol ppp (IOS)	test crash (IOS)
radius-server authorization permit missing Service-Type (IOS)	test mbus power on\|off (GSR IOS)
radius-server unique-ident (IOS)	test ppp echotimeout (IOS)
service download-fl (GSR IOS)	test transmit (IOS)
service internal (IOS)	tracy_close (XID/CatOS with WS-X6608-T1 or WS-X6608-E1)
service log backtrace (IOS)	tracy_start (XID/CatOS with WS-X6608-T1 or WS-X6608-E1)
service unsupported-transceiver (IOS)	traffic-shape fecn-create (IOS)
service-policy classify-per-feature (IOS)	ttcp (Cisco 7200/7500, IOS)
set trace (XID/CatOS)	tx-queue-limit (IOS)
set trace monitor {enable\|disable} (XID/CatOS)	virtual-template pre-clone (IOS)
show acl stats (XID/CatOS)	vpdn ip udp ignore checksum (IOS)
show alignment (IOS)	vpdn {l2f\|l2tp} session table-size (IOS)

The BGP Neighbor Process

2012-04-13T17:04:00.001+07:00

Like TCP, BGP is connection-oriented. An underlying connection between two BGP speakers is established before any routing information is exchanged. This connection takes place on TCP port 179. As with EIGRP and OSPF, keepalive messages are sent out by the BGP speakers in order to keep this relationship alive.

Once the connection is established, the BGP speakers exchange routes and synchronize their tables. After this initial exchange, a BGP speaker will only send further updates upon a change in the network topology.

The IGP protocols that use Autonomous Systems, IGRP and EIGRP, require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. The BGP neighbors do not have to be directly connected, and often are not, but do need to be able to reach the IP addresses they use in their neighbor statements.

A BGP peer that is in the same AS is referred to as an Internal BGP (iBGP) Peer, where a BGP peer in another AS is an External BGP (eBGP) Peer.

A sample iBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 100

A sample eBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 200

Cisco recommends that eBGP peers be directly connected, where iBGP peers generally will not be.

Before we get too much farther into BGP theory, let's get a configuration started. You'll use the router bgp command to configure a router as a BGP speaker. Right after that, the neighbor command will be used to identify this BGP speaker's potential neighbors. (The terms "peer" and "neighbor" are interchangeable in BGP, but it's the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.)

R1(config-router)#neighbor 172.12.123.3 remote-as 200

While almost all of the neighbor options are just that -- optional -- you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. Remember, BGP speakers do not have to be in the same AS to become peers. To verify that the remote BGP speaker has become a peer, run show ip bgp neighbor.

R1#show ip bgp neighbor

BGP neighbor is 172.12.123.3, remote AS 200, external link

BGP version 4, remote router ID 0.0.0.0

BGP state = Active

Last read 00:01:39, hold time is 180, keepalive interval is 60 seconds

Received 0 messages, 0 notifications, 0 in queue

Sent 0 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 30 seconds

The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means that a BGP peer connection does not yet exist with the prospective neighbor.

So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that's not as good as it sounds. Of course, the reason the peer relationship hasn't been established is that we haven't configured R3 yet!

R3(config)#router bgp 200 R3(config-router)#neighbor 172.12.123.1 remote-as 100

Verify the peer establishment with show ip bgp neighbor:

R3#show ip bgp neighbor

BGP neighbor is 172.12.123.1, remote AS 100, external link

BGP version 4, remote router ID 172.12.123.1

BGP state = Established, up for 00:01:18

Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds

Local host: 172.12.123.3, Local port: 179 (BGP uses TCP Port 179)

Foreign host: 172.12.123.1, Foreign port: 11007 The peer relationship between R1 and R3 has been established.

Now that you know how the neighbor relationship itself is built, you need to start learning the many options of the neighbor command. You'll have to master these to become a CCNP and CCIE!

About the Author
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (http://www.thebryantadvantage.com), home of free CCNP and CCNA tutorials! For my FREE "How To Pass The CCNA" or "CCNP" ebook, visit the website and download your copies. Pass your CCNP exam with The Bryant Advantage!

Introduction to BGP

2012-04-13T17:03:00.000+07:00

Cisco certification candidates are introduced to BGP at the CCNP level, but the reaction to its introduction always reminds me of something I see often at the CCNA level.

Whenever I teach distance-vector protocols in my class, I make sure my students understand the many rules of distance-vector routing thoroughly. After that, we move on to OSPF and link-state routing.

And what do I tell my students before we move on to OSPF and link-state? "Take all that great stuff you just learned about distance-vector routing and put it aside, because none of it applies here!"

That's about the time I get astonished looks and a few things thrown at me. :)

What's this got to do with BGP? Well, when you start studying BGP, you have to put a lot of preconceptions aside. It sounds like just another routing protocol, like RIP or OSPF, but it's not.

So... before we start studying BGP and looking at some of its many features, let's take a look at what BGP is and what it's not.

What BGP Does and Who Uses It?
If you're in a position where you're used to seeing or working with routing protocols such as EIGRP and OSPF, you're probably now working with BGP. BGP is not a protocol you're going to configure at the office LAN. BGP is used to connect autonomous systems, which are very large "collections" of networks. (Those of you who have studied IGRP and EIGRP are familiar with the concepts of an AS.)

As opposed to routing protocols such as EIGRP and OSPF, BGP is an exterior routing protocol. BGP is not used to find a specific network instead, it's used to find the AS where that given network can be found.

A good way to look at it is that networks are contained in Autonomous Systems BGP helps you find the AS where a given network is found. Routing protocols such as OSPF and EIGRP take it from there.

BGP Terminology
You'll be happy to know that BGP has a terminology all its own. Well, you might not be happy about it, but it does! I'm not going to throw a bunch of terms at you right now, since these terms are better introduced to you when you can see what they do. Having said that, here are a couple of basic BGP terms that will help you make the transition from IGPs to BGP.

aggregation - This is just the BGP term for summarization. You're familiar with route summarization from your CCNA studies, and if not, it's time for a review. I told you you'd be using those skills for a long time!

IGP - Interior Gateway Protocol. These are routing protocols that run within an Autonomous System, such as OSPF and EIGRP.

EGP - Exterior Gateway Protocol. Remember from your CCNA studies that EIGRP routes are indicated by the letter "D" in your routing table? Ever wonder why? EGP, that's why. Run show ip route and take a look at the routing table key. EGP was BGP's predecessor, and is still in the routing table. EGP was there before EIGRP, so that's why "E" in the routing table doesn't indicate an EIGRP route.

We'll be adding to this list a great deal in the next few weeks.

Now that you've got a grasp on the differences between BGP and the IGPs you've been working with up to this point, it's time to start looking at some basic BGP concepts and configurations.

To your success,
Chris Bryant
CCIE #12933

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (http://www.thebryantadvantage.com), home of free CCNA and CCNP tutorials, The Ultimate CCNA Study Package, and Ultimate CCNP Study Packages. Video courses and training, binary and subnetting help, and corporate training are also available. Pass the CCNA exam with Chris Bryant, CCIE #12933! For a copy of his FREE "How To Pass The CCNA" or "How To Pass The CCNP" ebook, write to chris@thebryantadvantage.com!

IP Default-network vs. Default Static Routes

2012-04-13T15:04:00.001+07:00

One point of confusion for some CCNA and CCNP candidates is the difference between configuring a static default route and using the Cisco routing command ip default-network.

At first glance, they appear to do the same thing. Both configure a destination to which packets should be routed if there is no more specific route in the routing table.

The major difference between these two options is that configuring a static default route only defines a default route for the router you're configuring it on, while ip default-network will propagate the route via its routing protocol.

Let's examine the routing tables of a hub-and-spoke network using the ip default-network command. R1 is the hub and R2 and R3 are the spokes. They are directly connected via the network 172.12.123.0 /24, and each has a loopback with a 32-bit mask that are numbered according to the router number (1.1.1.1, etc.) RIP is running on all three routers and the loopbacks are advertised.

R1 has another serial interface with the IP address 10.1.1.1 /24, and this network has been flagged as a default network with the command ip default-network 10.0.0.0 . It is not being advertised by RIP.

The routing protocol will then advertise this route. With RIP, the default network is advertised as 0.0.0.0 . (With IGRP, it appears as the network number, but is marked as an IGRP External route. ) This route has been designated a candidate default route on R1, as we see with the asterisk next to the 10.0.0.0 /24 network (code table removed for brevity):

R1#show ip route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
R 2.0.0.0/8 [120/1] via 172.12.123.2, 00:00:11, Serial0
R 3.0.0.0/8 [120/1] via 172.12.123.3, 00:00:11, Serial0
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.12.21.0/30 is directly connected, BRI0
C 172.12.123.0/24 is directly connected, Serial0
* 10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial1

On R2 and R3, a default RIP route is now seen (code tables again deleted):

R2#show ip route
Gateway of last resort is 172.12.123.1 to network 0.0.0.0

R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:00, Serial0.213
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
R 3.0.0.0/8 [120/2] via 172.12.123.1, 00:00:00, Serial0.213
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.12.21.0/30 is directly connected, BRI0
C 172.12.123.0/24 is directly connected, Serial0.213
R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:00, Serial0.213

R3#show ip route
Gateway of last resort is 172.12.123.1 to network 0.0.0.0

R 1.0.0.0/8 [120/1] via 172.12.123.1, 00:00:27, Serial0.31
R 2.0.0.0/8 [120/2] via 172.12.123.1, 00:00:28, Serial0.31
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
172.12.0.0/24 is subnetted, 1 subnets
C 172.12.123.0 is directly connected, Serial0.31
R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:28, Serial0.31

And the default route works, since we can ping 10.1.1.1 from both R2 and R3. Since they have no other match in their routing tables, they use the default route. R2#ping 10.1.1.1

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

R3#ping 10.1.1.1

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

When deciding whether to use a default static route or a default network, keep in mind that if you want the routing protocol to propagate the default route, the ip default-network command will do that for you. But if you want only the local router to have the default route, a static IP route is the way to go.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, the home of the world's clearest, most concise, most comprehensive CCNA Study Guide available today. He offers free CCNA, CCNP, and Home Lab Setup Tutorials on the website, as well as online boot camps, Video courses and training, and binary/subnetting help. Join the revolution against overpriced and incomplete CCNA and CCNP study guides - visit www.thebryantadvantage.com today!

Route Redistribution And The Seed Metric

2012-04-13T14:51:00.001+07:00

In the first part of this free CCNP / BSCI tutorial, we looked at how leaving one simple word out of our route redistribution configuration - "subnets" - resulted in an incomplete routing table when redistributing routes from RIP to OSPF. (If you missed that part of the tutorial, visit my website's "Free Tutorials" section.) Today, we'll look at redistributing OSPF routes into RIP and identify another common redistribution error.

We are using a three-router network. R5 is running RIP, R1 is serving as a hub between R5 and R3 and is running RIP and OSPF, and R3 is running OSPF.

To begin this lab, we'll add three loopbacks to R3 and advertise them to R1 via OSPF.

R3(config)#int loopback33

R3(config-if)#ip address 33.3.3.3 255.255.255.255

R3(config-if)#int loopback34

R3(config-if)#ip address 34.3.3.3 255.255.255.255

R3(config-if)#int loopback35

R3(config-if)#ip address 35.3.3.3 255.255.255.255

R3(config-if)#router ospf 1

R3(config-router)#network 33.3.3.3 0.0.0.0 area 1

R3(config-router)#network 34.3.3.3 0.0.0.0 area 1

R3(config-router)#network 35.3.3.3 0.0.0.0 area 1

R1 sees all three of these routes in its routing table.

R1#show ip route ospf

34.0.0.0/32 is subnetted, 1 subnets

O IA 34.3.3.3 [110/65] via 172.12.123.3, 00:00:55, Serial0

35.0.0.0/32 is subnetted, 1 subnets

O IA 35.3.3.3 [110/65] via 172.12.123.3, 00:00:45, Serial0

33.0.0.0/32 is subnetted, 1 subnets

O IA 33.3.3.3 [110/65] via 172.12.123.3, 00:00:55, Serial0

We'll now redistribute these routes into RIP on R1. Remember the "subnets" option we talked about in the first part of this tutorial? There is no such option when redistributing OSPF routes into RIP, as IOS Help shows us.

R1(config)#router rip

R1(config-router)#redistribute ospf 1 ?

match Redistribution of OSPF routes

metric Metric for redistributed routes

route-map Route map reference

vrf VPN Routing/Forwarding Instance

R1(config-router)#redistribute ospf 1

The routes have been redistributed into RIP with the redistribute ospf 1 command. (The "1" is the OSPF process number.) Let's look at R5 and see the results.

R5#show ip route rip

R5#

The routes aren't there, but we didn't get a warning from the router that we needed to do anything else. What is the problem?

The problem is that RIP requires a seed metric to be specified when redistributing routes into that protocol. A seed metric is a "starter metric" that gives the RIP process a metric it can work with. The OSPF metric of cost is incomprehensible to RIP, since RIP's sole metric is hop count. We've got to give RIP a metric it understands when redistributing routes into that protocol, so let's go back to R1 and do so.

R1(config)#router rip

R1(config-router)#no redistribute ospf 1

R1(config-router)#redistribute ospf 1 metric 2

R5 now sees the routes. Note that the metric contained in the brackets is the seed metric.

R5#show ip route rip

34.0.0.0/32 is subnetted, 1 subnets

R 34.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

35.0.0.0/32 is subnetted, 1 subnets

R 35.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

33.0.0.0/32 is subnetted, 1 subnets

R 33.3.3.3 [120/2] via 100.1.1.1, 00:00:24, Ethernet0

If you read the previous tutorial, you may have noticed that we did not specify a seed metric for OSPF. OSPF does not require a seed metric to be set during redistribution. You also noticed that the router did tell us that there might be a problem when we left the "subnets" option out of RIP>OSPF redistribution, but the router didn't tell us anything about a seed metric when we performed OSPF>RIP redistribution. This is a detail you must know by heart in order to make your route redistribution successful!

About the Author:
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the CCNA exam with Chris Bryant!

Troubleshooting Route Redistribution

2012-04-13T14:47:00.001+07:00

If there's one CCNP / BSCI topic that looks so easy but can lead to a real headache, it's route redistribution. I'm not even talking about the routing loops and suboptimal routing that can result when route redistribution is done without proper planning - I'm talking about the basic commands themselves. Leaving out one single command option, or forgetting what else needs to be redistributed when redistributing dynamically discovered routes, can leave you with a routing table that looks complete but does not result in full IP connectivity.

In this free CCNP / BSCI tutorial series, we'll take a look at three common errors in route redistribution configurations, and how to fix them. We'll use three routers, R1, R3, and R5. R1 and R5 are in a RIPv2 domain and R1 and R3 are in an OSPF domain. R1 will be performing two-way route redistribution.

R5 is advertising its loopback, 5.5.5.5/24, into the RIPv2 domain. R1 sees this route in its RIP routing table:

R1#show ip route rip

5.0.0.0/24 is subnetted, 1 subnets

R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:01, Ethernet0

For R3 to see this route, route redistribution must be configured on R1. We'll use the redistribute rip command to do so.

R1(config)#router ospf 1
R1(config-router)#redistribute rip
% Only classful networks will be redistributed

The router immediately gives us a message that "only classful networks will be redistributed". What does this mean? Let's go to R3 and see if that router is receiving this route.

R3#show ip route ospf

< no output >

When we get no result from a show command, that means there's nothing to show. The only routes that will be successfully redistributed with the current configuration on R1 are classful networks, and 5.5.5.0/24 is a subnet.

To further illustrate the point, a classful network has been added to R5. This network is 16.0.0.0 /8, and is now being advertised by RIP. R1 sees this network as classful...

R1#show ip route rip

R 16.0.0.0/8 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

5.0.0.0/24 is subnetted, 1 subnets

R 5.5.5.0 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

... and R3 is receiving the route through redistribution.

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:08, Serial0.31

To redistribute both classful and classless networks, the option "subnets" must be added to the redistribute command on R1.

R1(config)#router ospf 1

R1(config-router)#no redistribute rip

R1(config-router)#redistribute rip subnets

R3 will now see both the classful and classless networks being redistributed into OSPF. (100.1.1.0 is the network connecting R1 and R5.)

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

100.0.0.0/24 is subnetted, 1 subnets

O E2 100.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

5.0.0.0/24 is subnetted, 1 subnets

O E2 5.5.5.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

This is one of the most common errors made during route redistribution, but now you know what to look out for! In the next part of this free CCNP / BSCI tutorial, we'll take a look at another such error.

About the Author:
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the CCNA exam with Chris Bryant!

OSPF And Passive Interfaces

2012-04-13T14:44:00.001+07:00

Your BSCI exam may well be the most challenging of the four exams you must pass to become a CCNP, so you have to have the details of every protocol on the exam mastered! Today, we'll look at the passive-interface command as it relates to OSPF.

Passive interfaces accept routing updates, but do not send them. Regarding OSPF, even though OSPF does not sent "routing updates" in the form that RIP, IGRP, and EIGRP do, you can still configure an OSPF-enabled interface as passive in order to prevent OSPF traffic from exiting that interface. No OSPF adjacency can be formed if one of the interfaces involved is a passive interface, and if you configure an OSPF-enabled interface as passive where an adjacency already exists, the adjacency will drop almost immediately.

In the following example, R1 and R2 have an existing OSPF adjacency over their Ethernet interfaces. In an effort to reduce routing traffic, R1's e0 interface is configured as passive. The adjacency drops right away.

R1(config)#router ospf 1

R1(config-router)#passive-interface ethernet0

R1(config-router)#

18:31:11: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Interface down or detached

That's a pretty important detail to keep in mind when you're using the passive-interface command, wouldn't you say?

You may well have a router that you want to configure most interfaces as passive. There's no longer a need to configure each interface as passive in that case - As of IOS version 12.0, you can now set all interfaces on a router as passive for a given protocol with the passive-interface default command. You can then configure each interface that you do NOT want to be passive with the "no passive-interface" command.

R3(config)#router ospf 1

R3(config-router)#passive-interface default

To set the interfaces back to their default, just use the no passive-interface default command.

R3(config-router)#no passive-interface default

The passive interface is a simple topic, but it can get a little tricky when you start changing the default and then start configuring interfaces on an individual level. Just be careful with this command on exam day and in the real world, and you'll succeed in the BSCI exam room and on real-world networks as well!

About the Author:
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the CCNA exam with Chris Bryant!