Master in Networking

SNMP Interoperability

2008-12-23T06:20:00.000-08:00

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and bilingual network-management systems.

SNMP Proxy Agents

An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:

An SNMPv2 NMS issues a command intended for an SNMPv1 agent.
The NMS sends the SNMP message to the SNMPv2 proxy agent.
The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.
GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent.

The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.

SNMP Security

2008-12-23T06:19:00.001-08:00

SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading occurrences, modification of information, message sequence and timing modifications, and disclosure. Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity. Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations. Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity. Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents. Because SNMP does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility.

SNMP Management

2008-12-23T06:18:00.000-08:00

SNMP is a distributed-management protocol. A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query manage devices and provide a summary of the information learned, or that it report locally stored management information.

SNMP Version 2

2008-12-23T06:16:00.000-08:00

SNMP version 2 (SNMPv2) is an evolution of the initial version, SNMPv1. Originally, SNMPv2 was published as a set of proposed Internet standards in 1993; currently, it is a draft standard. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). In theory, SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations.

SNMPv2 and Structure of Management Information

The Structure of Management Information (SMI) defines the rules for describing management information, using ASN.1.

The SNMPv2 SMI is described in RFC 1902. It makes certain additions and enhancements to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of addresses as well. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit counters are defined.

SMI Information Modules

The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist: MIB modules, compliance statements, and capability statements. MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. An NMS can adjust its behavior toward agents according to the capabilities statements associated with each agent.

SNMPv2 Protocol Operations

The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. However, SNMPv2 adds and enhances some protocol operations. The SNMPv2 Trap operation, for example, serves the same function as that used in SNMPv1, but it uses a different message format and is designed to replace the SNMPv1 Trap.

SNMPv2 also defines two new protocol operations: GetBulk and Inform. The GetBulk operation is used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as will fit. The Inform operation allows one NMS to send trap information to another NMS and to then receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.

SNMP Version 1

2008-12-23T06:14:00.000-08:00

SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. It is described in Request For Comments (RFC) 1157 and functions within the specifications of the Structure of Management Information (SMI). SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.

SNMPv1 and Structure of Management Information

The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv1 SMI is defined in RFC 1155. The SMI makes three key specifications: ASN.1 data types, SMI-specific data types, and SNMP MIB tables.

SNMPv1 and ASN.1 Data Types

The SNMPv1 SMI specifies that all managed objects have a certain subset of Abstract Syntax Notation One (ASN.1) data types associated with them. Three ASN.1 data types are required: name, syntax, and encoding. The name serves as the object identifier (object ID). The syntax defines the data type of the object (for example, integer or string). The SMI uses a subset of the ASN.1 syntax definitions. The encoding data describes how information associated with a managed object is formatted as a series of data items for transmission over the network.

SNMPv1 and SMI-Specific Data Types

The SNMPv1 SMI specifies the use of a number of SMI-specific data types, which are divided into two categories: simple data types and application-wide data types.

Three simple data types are defined in the SNMPv1 SMI, all of which are unique values: integers, octet strings, and object IDs. The integer data type is a signed integer in the range of –2,147,483,648 to 2,147,483,647. Octet strings are ordered sequences of 0 to 65,535 octets. Object IDs come from the set of all object identifiers allocated according to the rules specified in ASN.1.

Seven application-wide data types exist in the SNMPv1 SMI: network addresses, counters, gauges, time ticks, opaques, integers, and unsigned integers. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. Gauges are non-negative integers that can increase or decrease but that retain the maximum value reached. A time tick represents a hundredth of a second since some event. An opaque represents an arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI. An integer represents signed integer-valued information. This data type edefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. An unsigned integer represents unsigned integer-valued information and is useful when values are always non-negative. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

SNMP MIB Tables

The SNMPv1 SMI defines highly structured tables that are used to group the instances of a tabular object (that is, an object that contains multiple variables). Tables are composed of zero or more rows, which are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext, or Set command.

SNMPv1 Protocol Operations

SNMP is a simple request/response protocol. The network-management system issues a request, and managed devices return responses. This behavior is implemented by using one of four protocol operations: Get, GetNext, Set, and Trap. The Get operation is used by the NMS to retrieve the value of one or more object instances from an agent. If the agent responding to the Get operation cannot provide values for all the object instances in a list, it does not provide any values. The GetNext operation is used by the NMS to retrieve the value of the next object instance in a table or a list within an agent. The Set operation is used by the NMS to set the values of object instances within an agent. The Trap operation is used by agents to asynchronously inform the NMS of a significant event.

SNMP and Data Representation

2008-12-23T06:12:00.001-08:00

SNMP must account for and adjust to incompatibilities between managed devices. Different computers use different data representation techniques, which can compromise the capability of SNMP to exchange information between managed devices. SNMP uses a subset of Abstract Syntax Notation One (ASN.1) to accommodate communication between diverse systems.

SNMP Management Information Base

2008-12-23T06:08:00.000-08:00

SNMP Management Information Base

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables.

Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance.

Tabular objects define multiple related object instances that are grouped in MIB tables.

An example of a managed object is atInput, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface.

An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. Below figure illustrates the MIB tree.
The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations.

Vendors can define private branches that include managed objects for their own products. MIBs that have not been standardized typically are positioned in the experimental branch.

The managed object atInput can be uniquely identified either by the object name—iso.identified-organization.dod.internet.private.enterprise.cisco.temporary variables.AppleTalk.atInput—or by the equivalent object descriptor, 1.3.6.1.4.1.9.3.3.1.

SNMP Basic Commands

2008-12-23T05:08:00.000-08:00

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations.

The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices.

The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.

SNMP Basic Components

2008-12-23T05:04:00.000-08:00

An SNMP-managed network consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.

An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.

An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.

SNMP Introduction

2008-12-23T05:01:00.000-08:00

Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. Two versions of SNMP exist: SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2). Both versions have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of yet another version of SNMP—SNMP Version 3 (SNMPv3)—is pending. This chapter provides descriptions of the SNMPv1 and SNMPv2 protocol operations. Below figure illustrates a basic network managed by SNMP.

show ip bgp injected-paths

2008-11-11T07:31:00.000-08:00

show ip bgp injected-paths

To display all the injected paths in the BGP routing table, use the show ip bgp injected-paths command in EXEC mode.

show ip bgp injected-paths

Syntax Description: This command has no arguments or keywords.

Command Modes EXEC

show ip bgp

2008-11-11T07:29:00.000-08:00

show ip bgp

To display entries in the Border Gateway Protocol (BGP) routing table, use the show ip bgp command in EXEC command.

show ip bgp [network] [network-mask] [longer-prefixes] [prefix-list prefix-list-name | route-map
route-map-name] [shorter prefixes mask-length]

Syntax

network (Optional) Network number, entered to display a particular network in the BGP routing table.
network-mask (Optional) Displays all BGP routes matching the address and mask pair.
longer-prefixes (Optional) Displays the route and more specific routes.
prefix-list | route-map (Optional) Displays selected routes from a BGP routing table based on the contents of a prefix list or route map.
prefix-list-name | route-map-name (Optional) The name of the route map or prefix list that is specified for the above argument.
shorter prefixes mask-length (Optional) Displays learned prefixes that are longer than the maximum length but shorter than the specified mask for the prefix.

Command Modes : EXEC

bgp inject-map exist-map

2008-11-11T07:27:00.000-08:00

bgp inject-map exist-map

To inject a more specific route into a Border Gateway Protocol (BGP) routing table, use the bgp inject-map exist-map command in address family or router configuration mode. To disable the conditional injection of a selected route, use the no form of this command.

bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]
no bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]

Syntax: inject-map-name
Description: Defines the prefixes that will be created and installed to the local BGP table.

Syntax: exist-map-name
Description: Specifies the prefix that the BGP speaker will track.

Syntax: copy-attributes
Description: (Optional) Configures the injected route to inherit the attributes of the aggregate route.

Defaults: The BGP Conditional Route Injection feature is not enabled by default.

Command Modes: Address family configuration, Router configuration

Usage Guidelines:
If the copy-attributes keyword is not specified when the bgp inject-map command is used, thecomponents will use the default attributes for locally originated routes. If the copy-attribute keyword is used, the components will inherit the same attributes as the aggregate route.

To enable conditional route injection, the exist-map must contain both the match ip address prefix-list and match ip route-source prefix-list match clauses in the route map paragraph.

Examples:

The following example configures the router for conditional route injection:

(config-router)# bgp inject-map map1 exist-map map2 copy-attributes

Related Commands:

ip prefix-list -> Displays information about a prefix list or prefix list entries.
neighbor remote-as -> Adds an entry to the BGP or multiprotocol BGP neighbor table.
route-map (IP) -> Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.
show ip bgp -> Displays entries in the BGP routing table.
show ip bgp injected-paths -> Displays injected paths in the BGP routing table.

BGP Configuration Examples

2008-11-11T07:26:00.000-08:00

This following configuration example configures conditional route injection for the inject-map named ORIGINATE and the exist-map named LEARNED_PATH:

router bgp 109
bgp inject-map ORIGINATE exist-map LEARNED_PATH
!
route-map LEARNED_PATH permit 10
match ip address prefix-list ROUTE
match ip route-source prefix-list ROUTE_SOURCE
!
route-map ORIGINATE permit 10
set ip address prefix-list ORIGINATED_ROUTES
set community 14616:555 additive
!
ip prefix-list ROUTE permit 10.1.1.0/24
!
ip prefix-list ORIGINATED_ROUTES permit 10.1.1.0/25
ip prefix-list ORIGINATED_ROUTES permit 10.1.1.128/25
!
ip prefix-list ROUTE_SOURCE permit 10.2.1.1/32

BGP Troubleshooting

2008-11-11T07:25:00.000-08:00

The BGP Conditional Route Injection feature is based on the injection of a more specific prefix into theBGP routing table when a less specific prefix is present. If conditional route injection is not workingproperly, check the following:

If conditional route injection is configured but does not occur, check for the existence of the aggregate prefix in the BGP routing table. The existence (or not) of the tracked prefix in the BGP

routing table can be verified with the show ip bgp command.

If the aggregate prefix exists but conditional route injection does not occur, verify that the aggregate prefix is being received from the correct neighbor and the prefix list identifying that neighbor is a /32 match.

Verify the injection (or not) of the more specific prefix using the show ip bgp injected-paths command.

Verify that the prefix that is being injected is not outside of the scope of the aggregate prefix.

Ensure that the inject route map is configured with the set ip address command and not the match ip address command.

Monitoring and Maintaining BGP Conditional Route Injection

To display BGP conditional advertisement information, use the following commands in EXEC mode, as needed:

Command: Router# show ip bgp
Purpose: Displays entries in the BGP routing table.

Command: Router# show ip bgp injected-paths
Purpose: Displays paths in the BGP routing table that were conditionally injected.

Command: Router# show ip bgp neighbors
Purpose: Displays information about the TCP and BGP connections to neighbors.

Verifying BGP Conditional Route Injection

2008-11-11T07:24:00.000-08:00

To verify that the BGP Conditional Route Injection feature is configured correctly, use the show ip bgp or show ip bgp injected-paths command.

The following sample output is similar to the output that will be displayed when the show ip bgp
command is entered:

Router# show ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/8, version 13
Paths:(2 available, best #1, table Default-IP-Routing-Table)
Flag:0x200
Not advertised to any peer
Local, (injected path from 172.16.0.0/8)
10.0.0.2 from 10.0.0.2 (2.2.2.2)
Origin incomplete, localpref 100, valid, external, best
Community:957874231
200
10.0.0.2 from 10.0.0.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, external

The following sample output is similar to the output that will be displayed when the show ip bgp
injected-routes command is entered:

Router# show ip bgp injected-paths
BGP table version is 11, local router ID is 10.0.0.1
Status codes:s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes:i - IGP, e - EGP, ? - incomplete

	Network	Next Hop	Metric	LocPrf	Weight	Path
*>	172.16.0.0	10.0.0.2			0	?
*>	172.17.0.0/16	10.0.0.2			0	?

Configuring BGP Conditional Route Injection

2008-11-11T07:21:00.000-08:00

The BGP Conditional Route Injection feature is supported by all platforms in Cisco IOS Release 12.2(14)S that support BGP:

• Cisco 7200 series
• Cisco 7400 series
• Cisco 7500 series

Determining Platform Support Through Cisco Feature Navigator Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature. Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

See the following section for configuration tasks for the BGP Conditional Route Injection feature. Each task in the list is identified as either required or optional.

• Configuring BGP Conditional Route Injection (required)
• Verifying BGP Conditional Route Injection (optional)

To configure the BGP Conditional Route Injection feature, use the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	Router(config)# router bgp as-number	Places the router in router configuration mode, and configures the router to run a BGP process.
Step 2	Router(config-router)# bgp inject-map ORIGINATE exist-map LEARNED_PATH	Configures the inject-map named ORIGINATE and the exist-map named LEARNED_PATH for conditional route injection.
Step 3	Router(config-router)# exit	Exits router configuration mode, and enters global configuration mode.
Step 4	Router(config)# route-map LEARNED_PATH permit sequence-number	Configures the route map named LEARNED_PATH.
Step 5	Router(config-route-map)# match ip address prefix-list ROUTE	Specifies the aggregate route to which a more specific route will be injected.
Step 6	Router(config-route-map# match ip route-source prefix-list ROUTE_SOURCE	Configures the prefix list named ROUTE_SOURCE to redistribute the source of the route. Note: The route source is the neighbor address that is configured with the neighbor remote-as command. The tracked prefix must come from this neighbor in order for conditional route injection to occur.
Step 7	Router(config-route-map)# exit	Exits route-map configuration mode, and enters global configuration mode.
Step 8	Router(config)# route-map ORIGINATE permit 10	Configures the route map named ORIGINATE.
Step 9	Router(config-route-map)# set ip address prefix-list ORIGINATED_ROUTES	Specifies the routes to be injected.
Step 10	Router(config-route-map)# set community community-attribute additive	Configures the community attribute of the injected routes.
Step 11	Router(config-route-map)# exit	Exits route-map configuration mode, and enters global configuration mode.
Step 12	Router(config)# ip prefix-list ROUTE permit 10.1.1.0/24	Configures the prefix list named ROUTE to permit routes from network 10.1.1.0/24.
Step 13	Router(config)# ip prefix-list ORIGINATED_ROUTES permit 10.1.1.0/25	Configures the prefix list named ORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.
Step 14	Router(config)# ip prefix-list ORIGINATED_ROUTES permit 10.1.1.128/25	Configures the prefix list named ORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.
Step 15	Router(config)# ip prefix-list ROUTE_SOURCE permit 10.2.1.1/32	Configures the prefix list named ROUTE_SOURCE to permit routes from network 10.2.1.1/32. Note: The route source prefix list must be configured with a /32 mask in order for conditional route injection to occur.
Note: To enable conditional route injection, the exist-map must contain both the match ip address prefix-list and match ip route-source prefix-list match clauses in the route map paragraph.

BGP Route Flap Dampening

2008-11-11T07:20:00.000-08:00

Route dampening (introduced in Cisco IOS version 11.0) is a mechanism to minimize the instability caused by route flapping and oscillation over the network. To accomplish this, criteria are defined to identify poorly behaved routes. A route which is flapping gets a penalty for each flap (1000). As soon as the cumulative penalty reaches a predefined "suppress−limit", the advertisement of the route will be suppressed. The penalty will be exponentially decayed based on a preconfigured "half−time". Once the penalty decreases below a predefined "reuse−limit", the route advertisement will be un−suppressed.

Routes, external to an AS, learned via IBGP will not be dampened. This is to avoid the IBGP peers having higher penalty for routes external to the AS.

The penalty will be decayed at a granularity of 5 seconds and the routes will be un−suppressed at a granularity of 10 seconds. The dampening information is kept until the penalty becomes less than half of "reuse−limit" , at that point the information is purged from the router.

Initially, dampening will be off by default. This might change if there is a need to have this feature enabled by default. The following are the commands used to control route dampening:

bgp dampening (will turn on dampening)
no bgp dampening (will turn off dampening)
bgp dampening (will change the half−life−time)

A command that sets all parameters at the same time is:

bgp dampening
(range is 1−45 min, current default is 15 min)
(range is 1−20000, default is 750)
(range is 1−20000, default is 2000)
(maximum duration a route can be suppressed, range is 1−255, default is 4 times half−life−time)

RTB#
hostname RTB
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router bgp 100
bgp dampening
network 203.250.15.0
neighbor 192.208.10.5 remote−as 300

RTD#
hostname RTD
interface Loopback0
ip address 192.208.10.174 255.255.255.192
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.6 remote−as 100

RTB is configured for route dampening with default parameters. Assuming the EBGP link to RTD is stable, RTB's BGP table would look like this:

RTB#show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i − internal Origin
codes: i − IGP, e − EGP, ? − incomplete

	Network	Next Hop	Metric	LocPrf	Weight	Path
*>	192.208.10.0	192.208.10.5	0		0	300 i
*>	203.250.15.0	0.0.0.0	0		32768	i

In order to simulate a route flap, use clear ip bgp 192.208.10.6 on RTD. RTB's BGP table will look like this:

RTB#show ip bgp
BGP table version is 24, local router ID is 203.250.15.2 Status codes: s
suppressed, d damped, h history, * valid, > best, i − internal Origin
codes: i − IGP, e − EGP, ? − incomplete

	Network	Next Hop	Metric	LocPrf	Weight	Path
h	192.208.10.0	192.208.10.5	0		0	300 i
*>	203.250.15.0	0.0.0.0	0		32768	i

The BGP entry for 192.208.10.0 has been put in a "history" state. Which means that we do not have a best path to the route but information about the route flapping still exists.

RTB#show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 25
Paths: (1 available, no best path)
300 (history entry)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, external
Dampinfo: penalty 910, flapped 1 times in 0:02:03

The route has been given a penalty for flapping but the penalty is still below the "suppress limit" (default is 2000). The route is not yet suppressed. If the route flaps few more times we will see the following:

RTB#show ip bgp
BGP table version is 32, local router ID is 203.250.15.2 Status codes:
s suppressed, d damped, h history, * valid, > best, i − internal Origin codes:
i − IGP, e − EGP, ? − incomplete

	Network	Next Hop	Metric	LocPrf	Weight	Path
*d	192.208.10.0	192.208.10.5	0		0	300 i
*>	203.250.15.0	0.0.0.0	0		32768	i

RTB#show ip bgp 192.208.10.0
BGP routing table entry for 192.208.10.0 255.255.255.0, version 32
Paths: (1 available, no best path)
300, (suppressed due to dampening)
192.208.10.5 from 192.208.10.5 (192.208.10.174)
Origin IGP, metric 0, valid, external
Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00

The route has been dampened (suppressed). The route will be reused when the penalty reaches the "reuse value", in our case 750 (default).The dampening information will be purged when the penalty becomes less than half of the reuse−limit, in our case (750/2=375). The following are the commands used to show and clear flap statistics information:

show ip bgp flap−statistics (displays flap statistics for all the paths)
show ip bgp−flap−statistics regexp (displays flap statistics for all paths that match the regexp)
show ip bgp flap−statistics filter−list (displays flap statistics for all paths that pass the filter)
show ip bgp flap−statistics A.B.C.D m.m.m.m (displays flap statistics for a single entry)
show ip bgp flap−statistics A.B.C.D m.m.m.m longer−prefixes (displays flap statistics for more specific entries)
show ip bgp neighbor [dampened−routes] | [flap−statistics] (displays flap statistics for all paths from a neighbor)
clear ip bgp flap−statistics (clears flap statistics for all routes)
clear ip bgp flap−statistics regexp (clears flap statistics for all the paths that match the regexp)
clear ip bgp flap−statistics filter−list (clears flap statistics for all the paths that pass the filter)
clear ip bgp flap−statistics A.B.C.D m.m.m.m (clears flap statistics for a single entry)
clear ip bgp A.B.C.D flap−statistics (clears flap statistics for all paths from a neighbor)

BGP RR and Conventional BGP Speakers

2008-11-11T07:18:00.000-08:00

It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP speakers to coexist. These routers could be either members of a client group or a non−client group. This would allow easy and gradual migration from the current IBGP model to the route reflector model. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers. Then more clusters could be created gradually.

In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that would have to be upgraded.

The following is the configuration of RTD and RTC:

RTD#
router bgp 100
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 3.3.3.3 remote−as 100
neighbor 2.2.2.2 remote−as 100
neighbor 1.1.1.1 remote−as 100
neighbor 13.13.13.13 remote−as 300

RTC#
router bgp 100
neighbor 4.4.4.4 remote−as 100
neighbor 2.2.2.2 remote−as 100
neighbor 1.1.1.1 remote−as 100
neighbor 14.14.14.14 remote−as 400

When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA and RTB become clients of RTC.

Avoiding Looping of Routing Information

We have mentioned so far two attributes that are used to prevent potential information looping:

originator−id and cluster−list. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps.

The set clause for out−bound route−maps does not affect routes reflected to IBGP peers.

More restrictions are also put on nexthop−self, which is a per neighbor configuration option. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed.

BGP Multiple RRs within a Cluster

2008-11-11T07:17:00.000-08:00

Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router ID of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than one RR. All RRs in the same cluster need to be configured with a 4 byte cluster−id so that a RR can recognize updates from RRs in the same cluster.

A cluster−list is a sequence of cluster−ids that the route has passed. When a RR reflects a route from its clients to non−clients outside of the cluster, it will append the local cluster−id to the cluster−list. If this update has an empty cluster−list the RR will create one. Using this attribute, a RR can identify if the routing information is looped back to the same cluster due to poor configuration. If the local cluster−id is found in the cluster−list, the advertisement will be ignored.

In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:

RTH#
router bgp 100
neighbor 4.4.4.4 remote−as 100
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100
neighbor 9.9.9.9 remote−as 300
bgp route−reflector 10 (This is the cluster−id)

RTD#
router bgp 100
neighbor 10.10.10.10 remote−as 100
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100
neighbor 11.11.11.11 remote−as 400
bgp route−reflector 10 (This is the cluster−id)

RTF#
router bgp 100
neighbor 10.10.10.10 remote−as 100
neighbor 4.4.4.4 remote−as 100
neighbor 13.13.13.13 remote−as 500

RTC#
router bgp 100
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 route−reflector−client
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−reflector−client
neighbor 4.4.4.4 remote−as 100
neighbor 7.7.7.7 remote−as 100
neighbor 10.10.10.10 remote−as 100
neighbor 8.8.8.8 remote−as 200

Note that we did not need the cluster command for RTC because only one RR exists in that cluster. An important thing to note, is that peer−groups were not used in the above configuration. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR, peer−goups should not be used. If peer groups were to be configured, then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.

The router sub−command bgp client−to−client reflection is enabled by default on the RR. If BGP client−to−client reflection were turned off on the RR and redundant BGP peering was made between the clients, then using peer groups would be alright.

BGP Route Reflectors

2008-11-11T07:16:00.001-08:00

Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR).

As demonstrated in the Internal BGP section, a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. By relaxing this restriction a bit and by providing additional control, we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. This will reduce the number of IBGP peers within an AS.

In normal cases, a full IBGP mesh should be maintained between RTA, RTB and RTC within AS100. By utilizing the route reflector concept, RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB. Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB.

neighbor route−reflector−client

The router with the above command would be the RR and the neighbors pointed at would be the clients of that RR. In our example, RTC would be configured with the neighbor route−reflector−client command pointing at RTA and RTB's IP addresses. The combination of the RR and its clients is called a cluster. RTA, RTB and RTC above would form a cluster with a single RR within AS100.

Other IBGP peers of the RR that are not clients are called non−clients.

An autonomous system can have more than one route reflector; a RR would treat other RRs just like any other IBGP speaker. Other RRs could belong to the same cluster (client group) or to other clusters. In a simple configuration, the AS could be divided into multiple clusters, each RR will be configured with other RRs as non−client peers in a fully meshed topology. Clients should not peer with IBGP speakers outside their cluster.

Consider the above diagram. RTA, RTB and RTC form a single cluster with RTC being the RR. According to RTC, RTA and RTB are clients and anything else is a non−client. Remember that clients of an RR are pointed at using the neighbor route−reflector−client command. The same RTD is the RR for its clients RTE and RTF; RTG is a RR in a third cluster. Note that RTD, RTC and RTG are fully meshed but routers within a cluster are not. When a route is received by a RR, it will do the following depending on the peer type:

Route from a non−client peer: reflect to all the clients within the cluster.
Route from a client peer: reflect to all the non−client peers and also to the client peers.
Route from an EBGP peer: send the update to all client and non−client peers.

The following is the relative BGP configuration of routers RTC, RTD and RTB:

RTC#
router bgp 100
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−reflector−client
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 4.4.4.4 remote−as 100
neighbor 8.8.8.8 remote−as 200

RTB#
router bgp 100
neighbor 3.3.3.3 remote−as 100
neighbor 12.12.12.12 remote−as 300

RTD#
router bgp 100
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100

As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route Reflector scheme has a few methods to avoid this:

Originator−id: this is an optional, non transitive BGP attribute that is four bytes long and is created by a RR. This attribute will carry the router−id (RID) of the originator of the route in the local AS. Thus, due to poor configuration, if the routing information comes back to the originator, it will be ignored.
Cluster−list: this will be discussed in the next section.

BGP Confederation

2008-11-11T07:13:00.000-08:00

BGP confederation is implemented in order to reduce the IBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information are preserved. To the outside world, the confederation (the group of ASs) will look like a single AS.

To configure a BGP confederation use the following:

bgp confederation identifier autonomous−system

The confederation identifier will be the AS number of the confederation group. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier.

Peering within the confederation between multiple ASs is done via the following command:

bgp confederation peers autonomous−system [autonomous−system]

The following is an example of confederation:

Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.

By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.

Let's look at a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.

RTC#
router bgp 50
bgp confederation identifier 500
bgp confederation peers 60 70
neighbor 128.213.10.1 remote−as 50 (IBGP connection within AS50)
neighbor 128.213.20.1 remote−as 50 (IBGP connection within AS50)
neighbor 129.210.11.1 remote−as 60 (BGP connection with confederation peer 60)
neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)
neighbor 5.5.5.5 remote−as 100 (EBGP connection to external AS100)

RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote−as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote−as 50(BGP connection with confederation peer 50)
neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)
neighbor 6.6.6.6 remote−as 600 (EBGP connection to external AS600)

RTA#
router bgp 100
neighbor 5.5.5.4 remote−as 500 (EBGP connection to confederation 500)

BGP CIDR

2008-11-11T07:12:00.001-08:00

CIDR and Aggregate Addresses

One of the main enhancements of BGP4 over BGP3 is Classless Interdomain Routing (CIDR). CIDR or supernetting is a new way of looking at IP addresses. There is no notion of classes anymore (class A, B or C).

For example, network 192.213.0.0 which used to be an illegal class C network is now a legal supernet represented by 192.213.0.0/16 where the 16 is the number of bits in the subnet mask counting from the far left of the IP address. This is similar to 192.213.0.0 255.255.0.0.

Aggregates are used to minimize the size of routing tables. Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. In the example below, RTB is generating network 160.10.0.0. We will configure RTC to propagate a supernet of that route 160.0.0.0 to RTA.

RTB#
router bgp 200
neighbor 3.3.3.1 remote−as 300
network 160.10.0.0

#RTC
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
network 170.10.0.0

aggregate−address 160.0.0.0 255.0.0.0

RTC will propagate the aggregate address 160.0.0.0 to RTA.

Aggregate Commands

There is a wide range of aggregate commands. It is important to understand how each one works in order to have the desired aggregation behavior.

The first command is the one used in the previous example:

aggregate−address address mask

This will advertise the prefix route, and all of the more specific routes. The command aggregate−address 160.0.0.0 will propagate an additional network 160.0.0.0 but will not prevent 160.10.0.0 from being also propagated to RTA. The outcome of this is that both networks 160.0.0.0 and 160.10.0.0 have been propagated to RTA. This is what we mean by advertising the prefix and the more specific route.

Please note that you can not aggregate an address if you do not have a more specific route of that address in the BGP routing table.

For example, RTB can not generate an aggregate for 160.0.0.0 if it does not have a more specific entry of 160.0.0.0 in its BGP table. The more specific route could have been injected into the BGP table via incoming updates from other ASs, from redistributing an IGP or static into BGP or via the network command (network 160.10.0.0).

In case we would like RTC to propagate network 160.0.0.0 only and NOT the more specific route then we would have to use the following:

aggregate−address address mask summary−only

This will a advertise the prefix only; all the more specific routes are suppressed.

The command aggregate 160.0.0.0 255.0.0.0 summary−only will propagate network 160.0.0.0 and will suppress the more specific route 160.10.0.0.

Please note that if we are aggregating a network that is injected into our BGP via the network statement (ex: network 160.10.0.0 on RTB) then the network entry is always injected into BGP updates even though we are using "the aggregate summary−only" command. The upcoming CIDR example discusses this situation.

aggregate−address address mask as−set

This advertises the prefix and the more specific routes but it includes as−set information in the path information of the routing updates.

aggregate 129.0.0.0 255.0.0.0 as−set

This command will be discussed in an example by itself in the following sections.

In case we would like to suppress more specific routes when doing the aggregation we can define a route map and apply it to the aggregates. This will allow us to be selective about which more specific routes to suppress.

aggregate−address address−mask suppress−map map−name

This advertises the prefix and the more specific routes but it suppresses advertisement according to a route−map. In the previous diagram, if we would like to aggregate 160.0.0.0 and suppress the more specific route 160.20.0.0 and allow 160.10.0.0 to be propagated, we can use the following route map:

route−map CHECK permit 10
match ip address 1
access−list 1 permit 160.20.0.0 0.0.255.255
access−list 1 deny 0.0.0.0 255.255.255.255

By definition of the suppress−map, any packets permitted by the access list would be suppressed from the updates.

Then we apply the route−map to the aggregate statement.

RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 remote−as 100
network 170.10.0.0
aggregate−address 160.0.0.0 255.0.0.0 suppress−map CHECK

Another variation is the:

aggregate−address address mask attribute−map map−name

This allows us to set the attributes (such as metric) when aggregates are sent out. The following route map when applied to the aggregate attribute−map command will set the origin of the aggregates to IGP.

route−map SETMETRIC
set origin igp
aggregate−address 160.0.0.0 255.0.0.0 attribute−map SETORIGIN

CIDR Example 1

Request: Allow RTB to advertise the prefix 160.0.0.0 and suppress all the more specific routes.

The problem here is that network 160.10.0.0 is local to AS200, meaning AS200 is the originator of 160.10.0.0. You cannot have RTB generate a prefix for 160.0.0.0 without generating an entry for 160.10.0.0 even if you use the aggregate summary−only command because RTB is the originator of 160.10.0.0. There are two solutions to this problem.

The first solution is to use a static route and redistribute it into BGP. The outcome is that RTB will advertise the aggregate with an origin of incomplete (?).

RTB#
router bgp 200
neighbor 3.3.3.1 remote−as 300
redistribute static (This will generate an update for 160.0.0.0 with the origin path as *incomplete*)
ip route 160.0.0.0 255.0.0.0 null0

In the second solution, in addition to the static route we add an entry for the network command. This has the same effect except that the origin of the update will be set to IGP.

RTB#
router bgp 200
network 160.0.0.0 mask 255.0.0.0 (this will mark the update with origin IGP)
neighbor 3.3.3.1 remote−as 300
redistribute static

ip route 160.0.0.0 255.0.0.0 null0

CIDR Example 2 (as−set)

AS−SETS are used in aggregation to reduce the size of the path information by listing the AS number only once, regardless of how many times it may have appeared in multiple paths that were aggregated. The as−set aggregate command is used in situations were aggregation of information causes loss of information regarding the path attribute. In the following example RTC is getting updates about 160.20.0.0 from RTA and updates about 160.10.0.0 from RTB. Suppose RTC wants to aggregate network 160.0.0.0/8 and send it to RTD. RTD would not know what the origin of that route is. By adding the aggregate as−set statement we force RTC to generate path information in the form of a set {}. All the path information is included in that set irrespective of which path came first.

RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote−as 300
RTA#
router bgp 100
network 160.20.0.0
neighbor 2.2.2.1 remote−as 300

Case 1:

RTC does not have an as−set statement. RTC will send an update 160.0.0.0/8 to RTD with path information (300) as if the route has originated from AS300.

RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 4.4.4.4 remote−as 400
aggregate 160.0.0.0 255.0.0.0 summary−only
!−− this causes RTC to send RTD updates about 160.0.0.0/8 with no indication
!−− that 160.0.0.0 is actually coming from two different autonomous
!−− systems, this may create loops if RT4 has an entry back into AS100.

Case 2:

RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 4.4.4.4 remote−as 400
aggregate 160.0.0.0 255.0.0.0 summary−only
aggregate 160.0.0.0 255.0.0.0 as−set
!−− causes RTC to send RTD updates about 160.0.0.0/8 with an
!−− indication that 160.0.0.0 belongs to a set {100 200}.

BGP Peer Groups

2008-11-11T07:10:00.000-08:00

A BGP peer group, is a group of BGP neighbors with the same update policies. Update policies are usually set by route maps, distribute−lists and filter−lists, etc. Instead of defining the same policies for each separate neighbor, we define a peer group name and we assign these policies to the peer group.

Members of the peer group inherit all of the configuration options of the peer group. Members can also be configured to override these options if these options do not affect outbound updates; you can only override options set on the inbound.

To define a peer group use the following:

neighbor peer−group−name peer−group

In the following example we will see how peer groups are applied to internal and external BGP neighbors.

RTC#
router bgp 300
neighbor internalmap peer−group
neighbor internalmap remote−as 300
neighbor internalmap route−map SETMETRIC out
neighbor internalmap filter−list 1 out
neighbor internalmap filter−list 2 in
neighbor 5.5.5.2 peer−group internalmap
neighbor 6.6.6.2 peer−group internalmap
neighbor 3.3.3.2 peer−group internalmap
neighbor 3.3.3.2 filter−list 3 in

In the above configuration, we have defined a peer group named internalmap and we have defined some policies for that group, such as a route map SETMETRIC to set the metric to 5 and two different filter lists 1 and 2. We have applied the peer group to all internal neighbors RTE, RTF and RTG. We have defined a separate filter−list 3 for neighbor RTE, and this will override filter−list 2 inside the peer group. Note that we could only override options that affect inbound updates.

Now, let us look at how we can use peer groups with external neighbors. In the same diagram we will configure RTC with a peer−group externalmap and we will apply it to external neighbors.

RTC#
router bgp 300
neighbor externalmap peer−group
neighbor externalmap route−map SETMETRIC
neighbor externalmap filter−list 1 out
neighbor externalmap filter−list 2 in
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 peer−group externalmap
neighbor 4.4.4.2 remote−as 600
neighbor 4.4.4.2 peer−group externalmap
neighbor 1.1.1.2 remote−as 200
neighbor 1.1.1.2 peer−group externalmap
neighbor 1.1.1.2 filter−list 3 in

Note that in the above configs we have defined the remote−as statements outside of the peer group because we have to define different external ASs. Also we did an override for the inbound updates of neighbor 1.1.1.2 by assigning filter−list 3.

BGP Neighbors

2008-11-11T07:09:00.000-08:00

BGP Neighbors and Route Maps

The neighbor command can be used in conjunction with route maps to perform either filtering or parameter setting on incoming and outgoing updates.

Route maps associated with the neighbor statement have no affect on incoming updates when matching based on the IP address:

neighbor ip−address route−map route−map−name

Assume in the above diagram we want RTC to learn from AS200 about networks that are local to AS200 and nothing else. Also, we want to set the weight on the accepted routes to 20. We can achieve this with a combination of neighbor and as−path access lists.

RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote−as 200
neighbor 3.3.3.3 route−map stamp in
route−map stamp
match as−path 1
set weight 20
ip as−path access−list 1 permit ^200$

Any updates that originate from AS200 have a path information that starts with 200 and ends with 200 and will be permitted. Any other updates will be dropped.

Assume that we want the following:

Updates originating from AS200 to be accepted with weight 20.
Updates originating from AS400 to be dropped.
Other updates to have a weight of 10.

RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote−as 200
neighbor 3.3.3.3 route−map stamp in
route−map stamp permit 10
match as−path 1
set weight 20
route−map stamp permit 20
match as−path 2
set weight 10
ip as−path access−list 1 permit ^200$
ip as−path access−list 2 permit ^200 600 .*

The above statement will set a weight of 20 for updates that are local to AS200, and will set a weight of 10 for updates that are behind AS400 and will drop updates coming from AS400.

Use of set as−path prepend Command

In some situations we are forced to manipulate the path information in order to manipulate the BGP decision process. The command that is used with a route map is:

set as−path prepend ...

Suppose in the above diagram that RTC is advertising its own network 170.10.0.0 to two different ASs:

AS100 and AS200. When the information is propagated to AS600, the routers in AS600 will have network reachability information about 150.10.0.0 via two different routes, the first route is via AS100 with PATH (100, 300) and the second one is via AS400 with PATH (400, 200,300). Assuming that all other attributes are the same AS600 will pick the shortest path and will choose the route via AS100.

AS300 will be getting all its traffic via AS100. If we want to influence this decision from the AS300 end we can make the PATH through AS100 look like it is longer than the PATH going through AS400. We can do this by prepending autonomous system numbers to the existing path info advertised to AS100. A common practice is to repeat our own AS number using the following:

RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−map SETPATH out
route−map SETPATH
set as−path prepend 300 300

Because of the above configuration, AS600 will receive updates about 170.10.0.0 via AS100 with a PATH information of: (100, 300, 300, 300) which is longer than (400, 200, 300) received from AS100.

BGP AS−Regular Expression

2008-11-11T07:07:00.000-08:00

A regular expression is a pattern to match against an input string. By building a regular expression we specify a string that input must match. In case of BGP we are specifying a string consisting of path information that an input should match.

In the previous example we specified the string ^200$ and wanted path information coming inside updates to match it in order to perform a decision.

The regular expression is composed of the following:

Range

A range is a sequence of characters contained within left and right square brackets. ex: [abcd]

Atom

An atom is a single character, such as the following:

. (Matches any single character)
^ (Matches the beginning of the input string)
$ (Matches the end of the input string)
\ (Matches the character)
− (Matches a comma (,), left brace ({), right brace (}), the beginning of the input string, the end of the input string, or a space.

Piece

A piece is an atom followed by one of the following symbols:

* (Matches 0 or more sequences of the atom)
+ (Matches 1 or more sequences of the atom)
? (Matches the atom or the null string)

Branch

A branch is a 0 or more concatenated pieces.

Examples of regular expressions follow:

a* (Any occurrence of the letter "a", including none)
a+ ( At least one occurrence of the letter "a" should be present)
ab?a (This matches "aa" or "aba")
_100_ (Via AS100)
^100$ (Origin AS100)
^100 .* (Coming from AS100)
^$ (Originated from this AS)

BGP Community Filtering

We would like RTB above to set the community attribute to the BGP routes it is advertising such that RTC would not propagate these routes to its external peers. The no−export community attribute is used:

RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote−as 300
neighbor 3.3.3.1 send−community
neighbor 3.3.3.1 route−map setcommunity out
route−map setcommunity
match ip address 1
set community no−export
access−list 1 permit 0.0.0.0 255.255.255.255

Note that we have used the route−map setcommunity command in order to set the community to no−export. Note also that we had to use the neighbor send−community command in order to send this attribute to RTC.

When RTC gets the updates with the attribute no−export, it will not propagate them to its external peer RTA.

In the example below, RTB has set the community attribute to 100 200 additive. The value 100 200 will be added to any existing community value before being sent to RTC.

RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote−as 300
neighbor 3.3.3.1 send−community
neighbor 3.3.3.1 route−map setcommunity out

route−map setcommunity
match ip address 2
set community 100 200 additive
access−list 2 permit 0.0.0.0 255.255.255.255

A community list is a group of communities that we use in a match clause of a route map which allows us to do filtering or setting attributes based on different lists of community numbers.

ip community−list community−list−number {permit|deny} community−number

For example we can define the following route map, match−on−community:

route−map match−on−community
match community 10 (10 is the community−list number)
set weight 20
ip community−list 10 permit 200 300
!−− 200 300 is the community number

We can use the above in order to filter or set certain parameters like weight and metric based on the community value in certain updates. In example two above, RTB was sending updates to RTC with a community of 100 200. If RTC wants to set the weight based on those values we could do the following:

RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 3.3.3.3 route−map check−community in
route−map check−community permit 10
match community 1
set weight 20
route−map check−community permit 20
match community 2 exact
set weight 10
route−map check−community permit 30
match community 3
ip community−list 1 permit 100
ip community−list 2 permit 200
ip community−list 3 permit internet

In the above example, any route that has 100 in its community attribute will match list 1 and will have the weight set to 20. Any route that has only 200 as community will match list 2 and will have weight 20. The keyword exact states that community should consist of 200 only and nothing else. The last community list is here to make sure that other updates are not dropped. Remember that anything that does not match, will be dropped by default. The keyword internet means all routes because all routes are members of the internet community.

BGP Filtering

2008-11-11T07:05:00.000-08:00

Sending and receiving BGP updates can be controlled by using a number of different filtering methods. BGP updates can be filtered based on route information, on path information or on communities. All methods will achieve the same results, choosing one over the other depends on the specific network configuration.

Route Filtering

In order to restrict the routing information that the router learns or advertises, you can filter BGP based on routing updates to or from a particular neighbor. In order to achieve this, an access−list is defined and applied to the updates to or from a neighbor. Use the following command in the router configuration mode:

neighbor {ip−address|peer−group−name} distribute−list access−list−number {in | out}

In the following example, RTB is originating network 160.10.0.0 and sending it to RTC. If RTC wanted to stop those updates from propagating to AS100, we would have to apply an access−list to filter those updates and apply it when talking to RTA:

RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 distribute−list 1 out
access−list 1 deny 160.10.0.0 0.0.255.255
access−list 1 permit 0.0.0.0 255.255.255.255
!−− filter out all routing updates about 160.10.x.x

Using access−lists is a bit tricky when you are dealing with supernets that might cause some conflicts.

Assume in the above example that RTB has different subnets of 160.10.X.X and our goal is to filter updates and advertise only 160.0.0.0/8 (this notation means that we are using 8 bits of subnet mask starting from the far left of the IP address; this is equivalent to 160.0.0.0 255.0.0.0).

The command access−list 1 permit 160.0.0.0 0.255.255.255 permits 160.0.0.0/8,160.0.0.0/9 and so on. In order to restrict the update to only 160.0.0.0/8 we have to use an extended access list of the following format:

access−list 101 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0. This list permits 160.0.0.0/8 only.

Another type of filtering is path filtering, which is described in the next section.

Path Filtering

You can specify an access list on both incoming and outgoing updates based on the BGP autonomous system paths information. In the above figure we can block updates about 160.10.0.0 from going to AS100 by defining an access list on RTC that prevents any updates that have originated from AS200 from being sent to AS100. To do this use the following statements.

ip as−path access−list access−list−number {permit|deny} as−regular−expression
neighbor {ip−address|peer−group−name} filter−list access−list−number {in|out}

The following example stops RTC from sending RTA updates about 160.10.0.0

RTC#
router bgp 300
neighbor 3.3.3.3 remote−as 200
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 filter−list 1 out
!−− the 1 is the access list number below
ip as−path access−list 1 deny ^200$
ip as−path access−list 1 permit .*

In the above example, access−list 1 states: deny any updates with path information that start with 200 (^) and end with 200 ($). The ^200$ is called a regular expression, with ^ meaning "starts with" and $ meaning "ends with". Since RTB sends updates about 160.10.0.0 with path information starting with 200 and ending with 200, this update matches the access list and will be denied.

The .* is another regular expression with the period meaning "any character" and the * meaning "the repetition of that character". So .* is actually any path information, which is needed to permit all other updates to be sent.

What would happen if instead of using ^200$ we have used ^200? If you have an AS400 (see figure above), updates originated by AS400 will have path information of the form (200, 400) with 200 being first and 400 being last. Those updates will match the access list ^200 because they start with 200 and will be prevented from being sent to RTA which is not the required behavior.

A good way to check whether we have implemented the correct regular expression is to use the show ip bgp regexp regular expression> command. This shows all the paths that have matched the configured regular expression.

BGP Synchronization

2008-11-11T07:03:00.001-08:00

Before we discuss synchronization let us look at the following scenario. RTC in AS300 is sending updates about 170.10.0.0. RTA and RTB are running IBGP, so RTB will get the update and will be able to reach 170.10.0.0 via next hop 2.2.2.1 (remember that the next hop is carried via IBGP). In order to reach the next hop, RTB will have to send the traffic to RTE.

Assume that RTA has not redistributed network 170.10.0.0 into IGP, so at this point RTE has no idea that 170.10.0.0 even exists.

If RTB starts advertising to AS400 that he can reach 170.10.0.0 then traffic coming from RTD to RTB with destination 170.10.0.0 will flow in and get dropped at RTE.

Synchronization states: If your autonomous system is passing traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.

BGP will wait until IGP has propagated the route within the AS and then will advertise it to external peers. This is called synchronization.

In the above example, RTB will wait to hear about 170.10.0.0 via IGP before it starts sending the update to RTD. We can fool RTB into thinking that IGP has propagated the information by adding a static route in RTB pointing to 170.10.0.0. Care should be taken to make sure that other routers can reach 170.10.0.0 otherwise we will have a problem reaching that network.

Disabling Synchronization

In some cases you do not need synchronization. If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.

Disabling synchronization is not automatic, if you have all your routers in the AS running BGP and you are not running any IGP, the router has no way of knowing that, and your router will be waiting forever for an IGP update about a certain route before sending it to external peers. You have to disable synchronization manually in this case for routing to work correctly:

router bgp 100
no synchronization

(Make sure you do a clear ip bgp address to reset the session.)

RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote−as 400
neighbor 3.3.3.3 remote−as 100
no synchronization
!−− RTB puts 170.10.0.0 in its IP routing table and advertises it to
!−− RTD even if it does not have an IGP path to 170.10.0.0)

RTD#
router bgp 400
neighbor 1.1.1.1 remote−as 100
network 175.10.0.0

RTA#
router bgp 100
network 150.10.0.0
neighbor 3.3.3.4 remote−as 100

BGP Backdoor Attribute

2008-11-11T07:00:00.000-08:00

Consider the above diagram, RTA and RTC are running EBGP, and RTB and RTC are running EBGP. RTA and RTB are running some kind of IGP (RIP, IGRP, etc.). By definition, EBGP updates have a distance of 20 which is lower than the IGP distances. Default distance is 120 for RIP, 100 for IGRP, 90 for EIGRP and 110 for OSPF.

RTA will receive updates about 160.10.0.0 via two routing protocols:

EBGP with a distance of 20 and IGP with a distance higher than 20.

By default, BGP has the following distances, but that could be changed by the distance command:

distance bgp external−distance internal−distance local−distance

external−distance:20
internal−distance:200
local−distance:200

RTA will pick EBGP via RTC because of the lower distance.

If we want RTA to learn about 160.10.0.0 via RTB (IGP), then we have two options:

Change EBGP's external distance or IGP's distance, which is not recommended.
Use BGP backdoor.

BGP backdoor makes the IGP route the preferred route.

Use the following network address backdoor command.

The configured network is the network that we would like to reach via IGP. For BGP this network will be treated as a locally assigned network except it will not be advertised in BGP updates.

RTA#
router eigrp 10
network 160.10.0.0
router bgp 100
neighbor 2.2.2.1 remote−as 300
network 160.10.0.0 backdoor

Network 160.10.0.0 is treated as a local entry, but is not advertised as a normal network entry.

RTA learns 160.10.0.0 from RTB via EIGRP with distance 90, and also learns it from RTC via EBGP with distance 20. Normally EBGP is preferred, but because of the backdoor command EIGRP is preferred.

BGP Weight Attribute

2008-11-11T06:59:00.000-08:00

BGP Weight Attribute

The weight attribute is a Cisco defined attribute. The weight is used for a best path selection process. The weight is assigned locally to the router. It is a value that only makes sense to the specific router and which is not propagated or carried through any of the route updates. A weight can be a number from 0 to 65535. Paths that the router originates have a weight of 32768 by default and other paths have a weight of zero.

Routes with a higher weight are preferred when multiple routes exist to the same destination. Let us study the above example. RTA has learned about network 175.10.0.0 from AS4 and will propagate the update to RTC. RTB has also learned about network 175.10.0.0 from AS4 and will propagate it to RTC. RTC has now two ways for reaching 175.10.0.0 and has to decide which way to go. If on RTC we can set the weight of the updates coming from RTA to be higher than the weight of updates coming from RTB, then we will force RTC to use RTA as a next hop to reach 175.10.0.0. This is achieved by using multiple methods:

Using the neighbor command: neighbor {ip−address|peer−group} weight weight.
Using AS path access−lists: ip as−path access−list access−list−number {permit|deny} as−regular−expression neighbor ip−address filter−list access−list−number weight weight.
Using route−maps.

RTC#
router bgp 300
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 weight 200
!−− route to 175.10.0.0 from RTA has 200 weight
neighbor 2.2.2.2 remote−as 200
neighbor 2.2.2.2 weight 100
!−− route to 175.10.0.0 from RTB will have 100 weight

Routes with higher weight are preferred when multiple routes exist to the same destination. RTA is preferred as the next hop.

The same outcome can be achieved using IP as−path and filter lists.

RTC#
router bgp 300
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 filter−list 5 weight 200
neighbor 2.2.2.2 remote−as 200
neighbor 2.2.2.2 filter−list 6 weight 100
...
ip as−path access−list 5 permit ^100$
!−− this only permits path 100
ip as−path access−list 6 permit ^200$
...
The same outcome as above can be achieved by using routemaps.
RTC#
router bgp 300
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 route−map setweightin in
neighbor 2.2.2.2 remote−as 200
neighbor 2.2.2.2 route−map setweightin in
...
ip as−path access−list 5 permit ^100$
...
route−map setweightin permit 10
match as−path 5
set weight 200
!−− anything that applies to access−list 5, such as packets from AS100, have weight 200
route−map setweightin permit 20
set weight 100
!−− anything else would have weight 100

BGP Community Attribute

2008-11-11T06:58:00.000-08:00

Community Attribute

The community attribute is a transitive, optional attribute in the range 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions (accept, prefer, redistribute, etc.) according to those communities.

We can use route maps to set the community attributes. The route map set command has the following syntax:

set community community−number [additive]

A few predefined well known communities (community−number) are:

no−export (Do not advertise to EBGP peers)
no−advertise (Do not advertise this route to any peer)
internet (Advertise this route to the internet community, any router belongs to it)

An example of route maps where community is set is:

route−map communitymap
match ip address 1
set community no−advertise

route−map setcommunity
match as−path 1
set community 200 additive

If the additive keyword is not set, 200 replaces any old community that already exits; if we use the keyword additive then the 200 is added to the community. Even if we set the community attribute, this attribute is not sent to neighbors by default. In order to send the attribute to our neighbor we have to use the following:

neighbor {ip−address|peer−group−name} send−community

Here's an example:

RTA#
router bgp 100
neighbor 3.3.3.3 remote−as 300
neighbor 3.3.3.3 send−community
neighbor 3.3.3.3 route−map setcommunity out

BGP Metric Attribute

2008-11-11T06:56:00.000-08:00

The metric attribute which is also called Multi_exit_discriminator, MED (BGP4) or Inter−As (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.

Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.

Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always−compare−med" should be configured on the router.

In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.

Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).

In order to force RTA to compare the metrics we have to add bgp always−compare−med to RTA. This is illustrated in the configs below:

RTA#
router bgp 100
neighbor 2.2.2.1 remote−as 300
neighbor 3.3.3.3 remote−as 300
neighbor 4.4.4.3 remote−as 400
....

RTC#
router bgp 300
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−map setmetricout out
neighbor 1.1.1.2 remote−as 300
route−map setmetricout permit 10
set metric 120

RTD#
router bgp 300
neighbor 3.3.3.2 remote−as 100
neighbor 3.3.3.2 route−map setmetricout out
neighbor 1.1.1.1 remote−as 300
route−map setmetricout permit 10
set metric 200

RTB#
router bgp 400
neighbor 4.4.4.4 remote−as 100
neighbor 4.4.4.4 route−map setmetricout out
route−map setmetricout permit 10
set metric 50

With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:

RTA#
router bgp 100
neighbor 2.2.21 remote−as 300
neighbor 3.3.3.3 remote−as 300
neighbor 4.4.4.3 remote−as 400
bgp always−compare−med

In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.
Metric can also be set while redistributing routes into BGP using the default−metric number command.

Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:

RTB#
router bgp 400
redistribute static
default−metric 50
ip route 180.10.0.0 255.255.0.0 null 0
!−− Causes RTB to send out 180.10.0.0 with a metric of 50

BGP Local Preference Attribute

2008-11-11T06:55:00.000-08:00

Local Preference Attribute

Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network. A path with a higher local preference is more preferred. The default value for local preference is 100.

Unlike the weight attribute which is only relevant to the local router, local preference is an attribute that is exchanged among routers in the same AS.

Local preference is set via the bgp default local−preference value> command or with route−maps as will be demonstrated in the following example:

The bgp default local−preference command will set the local preference on the updates out of the router going to peers in the same AS. In the above diagram, AS256 is receiving updates about 170.10.0.0 from two different sides of the organization. Local preference will help us determine which way to exit AS256 in order to reach that network. Let us assume that RTD is the preferred exit point. The following configuration will set the local preference for updates coming from AS300 to 200 and those coming from AS100 to 150.

RTC#
router bgp 256
neighbor 1.1.1.1 remote−as 100
neighbor 128.213.11.2 remote−as 256
bgp default local−preference 150

RTD#
router bgp 256
neighbor 3.3.3.4 remote−as 300
neighbor 128.213.11.1 remote−as 256
bgp default local−preference 200

In the above configuration RTC will set the local preference of all updates to 150. The same RTD
will set the local preference of all updates to 200. Since local preference is exchanged within AS256, both RTC and RTD will realize that network 170.10.0.0 has a higher local preference when coming from AS300 rather than when coming from AS100. All traffic in AS256 addressed to that network will be sent to RTD as an exit point.

More flexibility is provided by using route maps. In the above example, all updates received by RTD will be tagged with local preference 200 when they reach RTD. This means that updates coming from AS34 will also be tagged with the local preference of 200. This might not be needed. This is why we can use route maps to specify what specific updates need to be tagged with a specific local preference as shown below:

RTD#
router bgp 256
neighbor 3.3.3.4 remote−as 300
neighbor 3.3.3.4 route−map setlocalin in
neighbor 128.213.11.1 remote−as 256
....
ip as−path access−list 7 permit ^300$
...
route−map setlocalin permit 10
match as−path 7
set local−preference 400
route−map setlocalin permit 20
set local−preference 150

With this configuration, any update coming from AS300 will be set with a local preference of 200. Any other updates such as those coming from AS34 will be set with a value of 150.

BGP Nexthop Attribute

2008-11-11T06:54:00.000-08:00

The BGP nexthop attribute is the next hop IP address that is going to be used to reach a certain destination.

For EBGP, the next hop is always the IP address of the neighbor specified in the neighbor command. In the above example, RTC will advertise 170.10.0.0 to RTA with a next hop of 170.10.20.2 and RTA will advertise 150.10.0.0 to RTC with a next hop of 170.10.20.1. For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. Because of that rule, RTA will advertise 170.10.0.0 to its IBGP peer RTB with a next hop of 170.10.20.2. So according to RTB, the next hop to reach 170.10.0.0 is 170.10.20.2 and not 150.10.30.1.

You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to 170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC so BGP is only exchanged.

RTA#
router bgp 100
neighbor 170.10.20.2 remote−as 300
neighbor 150.10.50.1 remote−as 100
network 150.10.0.0

RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100

RTC#
router bgp 300
neighbor 170.10.20.1 remote−as 100
network 170.10.0.0

*RTC will advertise 170.10.0.0 to RTA with a NextHop 170.10.20.2
*RTA will advertise 170.10.0.0 to RTB with a NextHop= 170.10.20.2
(The external NextHop via EBGP is sent via IBGP)

BGP Nexthop (Multiaccess Networks)

The following example shows how the nexthop will behave on a multiaccess network such as ethernet.

Assume that RTC and RTD in AS300 are running OSPF. RTC is running BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA regarding 180.20.0.0 it will use as next hop 170.10.20.3 and not its own IP address (170.10.20.2). This is because the network between RTA, RTC and RTD is a multiaccess network and it makes more sense for RTA to use RTD as a next hop to reach 180.20.0.0 rather than making an extra hop via RTC.

*RTC will advertise 180.20.0.0 to RTA with a NextHop 170.10.20.3.

If the common media to RTA, RTC and RTD was not multiaccess, but NBMA (Non Broadcast Media Access) then further complications will occur.

BGP Nexthop (NBMA)

If the common media as you see in the shaded area above is a frame relay or any NBMA cloud then the exact behavior will occur as if we were connected via ethernet. RTC will advertise 180.20.0.0 to RTA with a next hop of 170.10.20.3.

The problem is that RTA does not have a direct PVC to RTD, and cannot reach the next hop. In this case routing will fail.

In order to remedy this situation a command called NextHopself is created.

Nexthopself

Because of certain situations with the nexthop as we saw in the previous example, a command called next−hop−self is created. The syntax is:

neighbor {ip−address|peer−group−name} next−hop−self

The next−hop−self command allows us to force BGP to use a specified IP address as the next hop rather than letting the protocol choose the next hop.

In the previous example, the following configuration solves our problem:

RTC#
router bgp 300
neighbor 170.10.20.1 remote−as 100
neighbor 170.10.20.1 next−hop−self

RTC advertises 180.20.0.0 with a NextHop = 170.10.20.2

BGP Origin Attribute

2008-11-11T06:53:00.000-08:00

Origin Attribute

The origin is a mandatory attribute that defines the origin of the path information. The origin attribute can assume three values:

IGP: Network Layer Reachability Information (NLRI) is interior to the originating AS. This normally happens when we use the bgp network command or when IGP is redistributed into BGP, then the origin of the path info will be IGP. This is indicated with an "i" in the BGP table.

EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is indicated with an "e" in the BGP table.

INCOMPLETE: NLRI is unknown or learned via some other means. This usually occurs when we redistribute a static route into BGP and the origin of the route will be incomplete. This is indicated with an "?" in the BGP table.

RTA#
router bgp 100
neighbor 190.10.50.1 remote−as 100
neighbor 170.10.20.2 remote−as 300
network 150.10.0.0
redistribute static
ip route 190.10.0.0 255.255.0.0 null0

RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100
network 190.10.50.0

RTE#
router bgp 300
neighbor 170.10.20.1 remote−as 100
network 170.10.0.0

RTA will reach 170.10.0.0 via: 300 i (which means the next AS path is 300 and the origin of the route is IGP).

RTA will also reach 190.10.50.0 via: i (which means, the entry is in the same AS and the origin is IGP).

RTE will reach 150.10.0.0 via: 100 i (the next AS is 100 and the origin is IGP).
RTE will also reach 190.10.0.0 via: 100 ? (the next AS is 100 and the origin is incomplete "?", coming from a static route).

BGP As_path Attribute

2008-11-11T06:51:00.000-08:00

As_path Attribute

Whenever a route update passes through an AS, the AS number is prepended to that update. The AS_path attribute is actually the list of AS numbers that a route has traversed in order to reach a destination.

An AS−SET is an ordered mathematical set {} of all the ASs that have been traversed. An example of AS−SET is given later.

In the above example, network 190.10.0.0 is advertised by RTB in AS200, when that route traverses AS300 and RTC will append its own AS number to it. So when 190.10.0.0 reaches RTA it will have two AS numbers attached to it: first 200 then 300. So as far as RTA is concerned the path to reach 190.10.0.0 is (300,200).

The same applies for 170.10.0.0 and 180.10.0.0. RTB will have to take path (300,100) i.e. traverse AS300 and then AS100 in order to reach 170.10.0.0. RTC will have to traverse path (200) in order to reach 190.10.0.0 and path (100) in order to reach 170.10.0.0.

iBGP

2008-11-11T06:50:00.000-08:00

iBGP is used if an AS wants to act as a transit system to other ASs. You might ask, why can't we do the same thing by learning via eBGP redistributing into IGP and then redistributing again into another AS? We can, but iBGP offers more flexibility and more efficient ways to exchange information within an AS; for example iBGP provides us with ways to control what is the best exit point out of the AS by using local preference.

RTA#
router bgp 100
neighbor 190.10.50.1 remote−as 100
neighbor 170.10.20.2 remote−as 300
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote−as 100
neighbor 175.10.40.1 remote−as 400
network 190.10.50.0
RTC#
router bgp 400
neighbor 175.10.40.2 remote−as 100
network 175.10.0.0

Note: An important point to remember, is that when a BGP speaker receives an update from other BGP speakers in its own AS (IBGP), the receiving BGP speaker will not redistribute that information to other BGP speakers in its own AS. The receiving BGP speaker will redistribute that information to other BGP speakers outside of its AS. That is why it is important to sustain a full mesh between the IBGP speakers within an AS.

In the above diagram, RTA and RTB are running iBGP and RTA and RTD are running iBGP also. The BGP updates coming from RTB to RTA will be sent to RTE (outside of the AS) but not to RTD (inside of the AS).

This is why an iBGP peering should be made between RTB and RTD in order not to break the flow of the updates.

BGP Static Routes

2008-11-11T06:48:00.000-08:00

Static Routes and Redistribution

You could always use static routes to originate a network or a subnet. The only difference is that BGP will consider these routes as having an origin of incomplete (unknown). In the above example the same could have been accomplished by doing:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default−metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote−as 300
redistribute static
...
ip route 175.220.0.0 255.255.255.0 null0
....

The null 0 interface means disregard the packet. So if I get the packet and there is a more specific match than 175.220.0.0 (which exists of course) the router will send it to the specific match otherwise it will disregard it.

This is a nice way to advertise a supernet.

We have discussed how we can use different methods to originate routes out of our autonomous system.

Please remember that these routes are generated in addition to other BGP routes that BGP has learned via neighbors (internal or external). BGP passes on information that it learns from one peer to other peers. The difference is that routes generated by the network command, or redistribution or static, will indicate your AS as the origin for these networks.

Injecting BGP into IGP is always done by redistribution.

RTA#
router bgp 100
neighbor 150.10.20.2 remote−as 300
network 150.10.0.0
RTB#
router bgp 200
neighbor 160.10.20.2 remote−as 300
network 160.10.0.0
RTC#
router bgp 300
neighbor 150.10.20.1 remote−as 100
neighbor 160.10.20.1 remote−as 200
network 170.10.00

Note that you do not need network 150.10.0.0 or network 160.10.0.0 in RTC unless you want RTC to also generate these networks on top of passing them on as they come in from AS100 and AS200. Again the difference is that the network command will add an extra advertisement for these same networks indicating that AS300 is also an origin for these routes.

An important point to remember is that BGP will not accept updates that have originated from its own AS. This is to insure a loop free interdomain topology.

For example, assume AS200 above had a direct BGP connection into AS100. RTA will generate a route 150.10.0.0 and will send it to AS300 then RTC will pass this route to AS200 with the origin kept as AS100, RTB will pass 150.10.0.0 to AS100 with origin still AS100. RTA will notice that the update has originated from its own AS and will ignore it.

BGP Network Command

2008-11-11T05:02:00.000-08:00

Network Command

The format of the network command follows:

network network−number [mask network−mask]

The network command controls what networks are originated by this box. This is a different concept from what you are used to configuring with IGRP and RIP. With this command we are not trying to run BGP on a certain interface, rather we are trying to indicate to BGP what networks it should originate from this box. The mask portion is used because BGP4 can handle subnetting and supernetting. A maximum of 200 entries of the network command are accepted. The network command will work if the network you are trying to advertise is known to the router, whether connected, static or learned dynamically.

An example of the network command follows:

RTA#
router bgp 1
network 192.213.0.0 mask 255.255.0.0
ip route 192.213.0.0 255.255.0.0 null 0

The above example indicates that router A, will generate a network entry for 192.213.0.0/16. The /16 indicates that we are using a supernet of the class C address and we are advertizing the first two octets (the first 16 bits).

Note that we need the static route to get the router to generate 192.213.0.0 because the static route will put a matching entry in the routing table.

Redistribution

The network command is one way to advertise your networks via BGP. Another way is to redistribute your IGP (IGRP, OSPF, RIP, EIGRP, etc.) into BGP. This sounds scary because now you are dumping all of your internal routes into BGP, some of these routes might have been learned via BGP and you do not need to send them out again. Careful filtering should be applied to make sure you are sending to the internet only routes that you want to advertise and not everything you have. Let us look at the example below.

RTA is announcing 129.213.1.0 and RTC is announcing 175.220.0.0. Look at RTC's configuration:

If you use a network command you will have:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default−metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote−as 300
network 175.220.0.0 mask 255.255.0.0 (this will limit the networks originated by your AS to 175.220.0.0)

If you use redistribution instead you will have:

RTC#
router eigrp 10
network 175.220.0.0
network 175.220.0.0
redistribute bgp 200
default−metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote−as 300
redistribute eigrp 10 (eigrp will inject 129.213.1.0 again into BGP)

This will cause 129.213.1.0 to be originated by your AS. This is misleading because you are not the source of 129.213.1.0 but AS100 is. So you would have to use filters to prevent that network from being sourced out by your AS. The correct configuration would be:

RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default−metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote−as 300
neighbor 1.1.1.1 distribute−list 1 out
redistribute eigrp 10
access−list 1 permit 175.220.0.0 0.0.255.255

The access−list is used to control what networks are to be originated from AS200.

BGP Route Maps

2008-11-11T04:59:00.000-08:00

Route Maps

At this point I would like to introduce route maps because they will be used heavily with BGP. In the BGP context, route map is a method used to control and modify routing information. This is done by defining conditions for redistributing routes from one routing protocol to another or controlling routing information when injected in and out of BGP. The format of the route map follows:

route−map map−tag [[permit | deny] | [sequence−number]]

The map−tag is just a name you give to the route−map. Multiple instances of the same route map (same name−tag) can be defined. The sequence number is just an indication of the position a new route map is to have in the list of route maps already configured with the same name.

For example, if I define two instances of the route map, let us call it MYMAP, the first instance will have a sequence−number of 10, and the second will have a sequence number of 20.

route−map MYMAP permit 10
(first set of conditions goes here.)

route−map MYMAP permit 20
(second set of conditions goes here.)

When applying route map MYMAP to incoming or outgoing routes, the first set of conditions will be applied via instance 10. If the first set of conditions is not met then we proceed to a higher instance of the route map. match and set configuration commands. Each route map will consist of a list of match and set configuration.

The match will specify a match criteria and set specifies a set action if the criteria enforced by the match command are met.

For example, I could define a route map that checks outgoing updates and if there is a match for IP address 1.1.1.1 then the metric for that update will be set to 5. The above can be illustrated by the following commands:

match ip address 1.1.1.1
set metric 5

Now, if the match criteria are met and we have a permit then the routes will be redistributed or controlled as specified by the set action and we break out of the list.

If the match criteria are met and we have a deny then the route will not be redistributed or controlled and we break out of the list.

If the match criteria are not met and we have a permit or deny then the next instance of the route map (instance 20 for example) will be checked, and so on until we either break out or finish all the instances of the route map. If we finish the list without a match then the route we are looking at will not be accepted nor forwarded.

One restriction on route maps is that when used for filtering BGP updates (as we will see later) rather than when redistributing between protocols, you can NOT filter on the inbound when using a "match" on the ip address. Filtering on t he outbound is OK.

The related commands for match are:

match as−path
match community
match clns
match interface
match ip address
match ip next−hop
match ip route−source
match metric
match route−type
match tag

The related commands for set are:

set as−path
set clns
set automatic−tag
set community
set interface
set default interface
set ip default next−hop
set level
set local−preference
set metric
set metric−type
set next−hop
set origin
set tag
set weight

Let's look at some route−map examples:

Example 1:

Assume RTA and RTB are running rip; RTA and RTC are running BGP. RTA is getting updates via BGP and redistributing them to rip. If RTA wants to redistribute to RTB routes about 170.10.0.0 with a metric of 2 and all other routes with a metric of 5 then we might use the following configuration:

RTA#
router rip
network 3.0.0.0
network 2.0.0.0
network 150.10.0.0
passive−interface Serial0
redistribute bgp 100 route−map SETMETRIC
router bgp 100
neighbor 2.2.2.3 remote−as 300
network 150.10.0.0
route−map SETMETRIC permit 10
match ip−address 1
set metric 2
route−map SETMETRIC permit 20
set metric 5
access−list 1 permit 170.10.0.0 0.0.255.255

In the above example if a route matches the IP address 170.10.0.0 it will have a metric of 2 and then we break out of the route map list. If there is no match then we go down the route map list which says, set everything else to metric 5. It is always very important to ask the question, what will happen to routes that do not match any of the match statements because they will be dropped by default.

Example 2:

Suppose in the above example we did not want AS100 to accept updates about 170.10.0.0. Since route maps cannot be applied on the inbound when matching based on an ip address, we have to use an outbound route map on RTC:

RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−map STOPUPDATES out
route−map STOPUPDATES permit 10
match ip address 1
access−list 1 deny 170.10.0.0 0.0.255.255
access−list 1 permit 0.0.0.0 255.255.255.255

Now that you feel more comfortable with how to start BGP and how to define a neighbor, let's look at how to start exchanging network information.

There are multiple ways to send network information using BGP. I will go through these methods one by one.

eBGP Multihop

2008-11-11T04:57:00.000-08:00

In some cases, a Cisco router can run eBGP with a third party router that doesn't allow the two external peers to be directly connected. To achieve this, you can use eBGP multihop, which allows the neighbor connection to be established between two non−directly−connected external peers. The multihop is used only for eBGP and not for iBGP. The following example illustrates of eBGP multihop.

RTA#
router bgp 100
neighbor 180.225.11.1 remote−as 300
neighbor 180.225.11.1 ebgp−multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote−as 100

RTA is indicating an external neighbor that isn't directly connected. RTA needs to indicate that it's using ebgp−multihop. On the other hand, RTB is indicating a neighbor that is directly connected (129.213.1.2), which is why it doesn't need the ebgp−multihop command. You should also configure an IGP or static routing to allow the non−connected neighbors to reach each other.
The following example shows how to achieve load balancing with BGP in a particular case where we have eBGP over parallel lines.

eBGP Multihop (Load Balancing)

RTA#
int loopback 0
ip address 150.10.1.1 255.255.255.0
router bgp 100
neighbor 160.10.1.1 remote−as 200
neighbor 160.10.1.1 ebgp−multihop
neighbor 160.10.1.1 update−source loopback 0
network 150.10.0.0
ip route 160.10.0.0 255.255.0.0 1.1.1.2
ip route 160.10.0.0 255.255.0.0 2.2.2.2
RTB#
int loopback 0
ip address 160.10.1.1 255.255.255.0
router bgp 200
neighbor 150.10.1.1 remote−as 100
neighbor 150.10.1.1 update−source loopback 0
neighbor 150.10.1.1 ebgp−multihop
network 160.10.0.0
ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1

The above example illustrates the use of loopback interfaces, update−source and ebgp−multihop. This is a workaround in order to achieve load balancing between two eBGP speakers over parallel serial lines. In normal situations, BGP picks one of the lines to send packets on, and load balancing wouldn't happen. By introducing loopback interfaces, the next hop for eBGP is the loopback interface. We use static routes (we could also use an IGP) to introduce two equal cost paths to reach the destination. RTA has two choices to reach next hop 160.10.1.1: one via 1.1.1.2 and the other one via 2.2.2.2, and the same for RTB.

BGP and Loopback Interfaces

2008-11-11T04:56:00.000-08:00

Using a loopback interface to define neighbors is common with iBGP, but not with eBGP. Normally the loopback interface is used to make sure the IP address of the neighbor stays up and is independent of hardware functioning properly. In the case of eBGP, peer routers are frequently directly connected and loopback doesn't apply.

If you use the IP address of a loopback interface in the neighbor command, you need some extra

configuration on the neighbor router. The neighbor router needs to tell BGP it's using a loopback interface rather than a physical interface to initiate the BGP neighbor TCP connection. The command used to indicate a loopback interface is:

neighbor ip−address update−source interface

The following example illustrates the use of this command.

RTA#

router bgp 100
neighbor 190.225.11.1 remote−as 100
neighbor 190.225.11.1 update−source loopback 1

RTB#
router bgp 100
neighbor 150.212.1.1 remote−as 100

Forming BGP Neighbors

2008-11-11T04:54:00.000-08:00

Two BGP routers become neighbors once they establish a TCP connection between each other. The TCP connection is essential in order for the two peer routers to start exchanging routing updates.

Once the TCP connection is up, the routers send open messages in order to exchange values such as the AS number, the BGP version they're running, the BGP router ID and the keepalive hold time. After these values are confirmed and accepted the neighbor connection is established. Any state other than "established" is an indication that the two routers didn't become neighbors, and BGP updates won't be exchanged.

Use this neighbor command to establish a TCP connection:

neighbor ip−address remote−as number

The remote−as number is the AS number of the router we're trying to connect to using BGP.

The ip−address is the next hop directly−connected address for eBGP and any IP address on the other router for iBGP.

It's essential that the two IP addresses used in the neighbor command of the peer routers be able to reach one another. One sure way to verify reachability is an extended ping between the two IP addresses. The extended ping forces the pinging router to use as source the IP address specified in the neighbor command rather than the IP address of the interface the packet is going out from.

It is important to reset the neighbor connection in case any BGP configuration changes are made in order for the new parameters to take effect.

clear ip bgp address (where address is the neighbor address)
clear ip bgp * (clear all neighbor connections)

By default, BGP sessions begin using BGP version 4 and negotiating downward to earlier versions if necessary. To prevent negotiations and force the BGP version used to communicate with a neighbor, perform the following task in router configuration mode:

neighbor {ip address|peer−group−name} version value

An example of the neighbor command configuration follows:

RTA#
router bgp 100
neighbor 129.213.1.1 remote−as 200
RTB#
router bgp 200
neighbor 129.213.1.2 remote−as 100
neighbor 175.220.1.2 remote−as 200
RTC#
router bgp 200
neighbor 175.220.212.1 remote−as 200

In the above example RTA and RTB are running eBGP. RTB and RTC are running iBGP. The difference between eBGP and iBGP is manifested by having the remote−as number pointing to either an external or an internal AS.

Also, the eBGP peers are directly connected while the iBGP peers are not. iBGP routers don't have to be directly connected, as long as there is some IGP running that allows the two neighbors to reach one another.

The following is an example of the information that the show ip bgp neighbors command displays. Pay special attention to the BGP state, since anything other than state "established" indicates the peers aren't up. You should also note the BGP version is 4, the remote router ID (highest IP address on the router or the highest loopback interface in case it exists) and the table version (this is the state of the table, any time new information comes in, the table increases the version and a version that keeps incrementing indicates that some route is flapping causing routes to continuously be updated).

#show ip bgp neighbors
BGP neighbor is 129.213.1.1, remote AS 200, external link
BGP version 4, remote router ID 175.220.12.1
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10

Enabling BGP Routing

2008-11-11T04:53:00.000-08:00

Use these steps to enable and configure BGP.

Let's assume you want to have two routers, RTA and RTB, talk BGP. In the first example RTA and RTB are in different ASs and in the second example both routers belong to the same AS.

We start by defining the router process and the AS number to which the routers belong. Use this command to enable BGP on a router:

router bgp autonomous−system

RTA#
router bgp 100

RTB#
router bgp 200

The above statements indicate that RTA is running BGP and it belongs to AS100 and RTB is running BGP and it belongs to AS200.

The next step in the configuration process is to define BGP neighbors, which indicates the routers that are trying to talk BGP.

eBGP and iBGP

2008-11-11T04:50:00.000-08:00

If an AS has multiple BGP speakers, it could be used as a transit service for other ASs. As you see below, AS200 is a transit AS for AS100 and AS300.

It is necessary to ensure reachability for networks within an AS before sending the information to external ASs. This is done by a combination of internal BGP (iBGP) peering between routers inside an AS and by redistributing BGP information to Internal Gateway Protocols (IGPs) running in the AS.

As far as this paper is concerned, when BGP is running between routers belonging to two different ASs, we call this exterior BGP (eBGP). When BGP is running between routers in the same AS, we call this iBGP.

How Does BGP Work

2008-11-11T04:49:00.000-08:00

How Does BGP Work ?

BGP uses TCP as its transport protocol (port 179). Two BGP routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters.

BGP routers exchange network reachability information. This information is mainly an indication of the full paths (BGP AS numbers) that a route should take in order to reach the destination network. This information helps in constructing a graph of ASs that are loop−free and where routing policies can be applied in order to enforce some restrictions on the routing behavior.

Any two routers that have formed a TCP connection in order to exchange BGP routing information are called peers, or neighbors. BGP peers initially exchange their full BGP routing tables. After this exchange, incremental updates are sent as the routing table changes. BGP keeps a version number of the BGP table, which should be the same for all of its BGP peers. The version number changes whenever BGP updates the table due to routing information changes. Keepalive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to errors or special conditions.

Dial-on-Demand Routing

2008-10-08T03:48:00.000-07:00

Dial-on-demand routing (DDR) is used to allow two or more Cisco routers to dial an ISDN dial-up connection on an as-needed basis. DDR is only used for low-volume, periodic network connections using either a Public Switched Telephone Network (PSTN) or ISDN. This was designed to reduce WAN costs if you have to pay on a per-minute or per-packet basis.

DDR works when a packet received on an interface meets the requirements of an access list defined by an administrator, which defines interesting traffic. The following five steps give a basic description of how DDR works when an interesting packet is received in a router interface:

1. Route to the destination network is determined.
2. Interesting packets dictate a DDR call.
3. Dialer information is looked up.
4. Traffic is transmitted.
5. Call is terminated when no more traffic is being transmitted over a link and the idle-timeout period ends.

Configuring DDR
To configure legacy DDR, you need to perform three tasks:
1. Define static routes, which define how to get to the remote networks and what interface to use to get there.
2. Specify the traffic that is considered interesting to the router.
3. Configure the dialer information that will be used to dial the interface to get to the remote network.

Configuring Static Routes

To forward traffic across the ISDN link, you configure static routes in each of the routers. You certainly can configure dynamic routing protocols to run on your ISDN link, but then the link will never drop. The suggested routing method is static routes. Keep the following in mind when creating static routes:

* All participating routers must have static routes defining all routes of known networks.
* Default routing can be used if the network is a stub network. An example of static routing with ISDN is shown below: RouterA(config)#ip route 172.16.50.0 255.255.255.0 172.16.60.2

RouterA(config)#ip route 172.16.60.2 255.255.255.255 bri0 What this does is tell the router how to get to network 172.16.50.0, which is through 172.16.60.2. The second line tells the router how to get to 172.16.60.2.

Specifying Interesting Traffic
After setting the route tables in each router, you need to configure the router to determine what brings up the ISDN line. An administrator using the dialer-list global configuration command defines interesting packets.

The command to turn on all IP traffic is shown as follows:

804A(config)#dialer-list 1 protocol ip permit
804A(config)#int bri0
804A(config-if)#dialer-group 1

The dialer-group command sets the access list on the BRI interface. Extended access lists can be used with the dialer-list command to define interesting traffic to just certain applications. We’ll cover that in a minute.

Configuring the Dialer Information
There are five steps in the configuration of the dialer information.
1. Choose the interface.
2. Set the IP address.
3. Configure the encapsulation type.
4. Link interesting traffic to the interface.
5. Configure the number or numbers to dial.

Here is an example of how to configure the five steps:

804A#config t
804A(config)#int bri0
804A(config-if)#ip address 172.16.60.1 255.255.255.0
804A(config-if)#no shut
804A(config-if)#encapsulation ppp
804A(config-if)#dialer-group 1
804A(config-if)#dialer-string 8350661
Instead of the dialer-string command, you can use a dialer map,
which provides more security.
804A(config-if)#dialer map ip 172.16.60.2 name 804B 8350661

The dialer map command can be used with the dialer-group command and its associated access list to initiate dialing. The dialer map command uses the IP address of the next hop router, the hostname of the remote router for authentication, and then the number to dial to get there.

Take a look at the following configuration of an 804 router:
804B#sh run
Building configuration...
Current configuration:

!
version 12.0
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 804B
!
ip subnet-zero
!
isdn switch-type basic-ni
!
interface Ethernet0
ip address 172.16.50.10 255.255.255.0
no ip directed-broadcast
!
interface BRI0
ip address 172.16.60.2 255.255.255.0
no ip directed-broadcast
encapsulation ppp
dialer idle-timeout 300
dialer string 8358661
dialer load-threshold 2 either
dialer-group 1
isdn switch-type basic-ni
isdn spid1 0835866201 8358662
isdn spid2 0835866401 8358664
hold-queue 75 in
!
ip classless
ip route 172.16.30.0 255.255.255.0 172.16.60.1
ip route 172.16.60.1 255.255.255.255 BRI0
!
dialer-list 1 protocol ip permit
!

The BRI interface is running the PPP encapsulation and has a timeout value of 300 seconds. The load-threshold command makes both BRI interfaces come up immediately (Okay, I feel that if I am paying for both I want them both up all the time). The one thing you really want to notice is the dialer-group 1 command. That number must match the dialer-list number. The hold-queue 75 in command tells the router that when it receives an interesting packet, it should queue up to 75 packets while it is waiting for the BRI to come up. If there are more than 75 packets queued before the link comes up, the packets will be dropped.

Optional Commands:

There are two other commands that you should configure on your BRI interface: the dialer load-threshold command and the dialer idletimeout command.

The dialer load-threshold command tells the BRI interface when to bring up the second B channel. The option is from 1–255, where 255 tells the BRI to bring up the second B channel only when the first channel is 100 percent loaded. The second option for that command is in, out, or either. This calculates the actual load on the interface either on outbound traffic, inbound traffic, or combined. The default is outbound. The dialer idle-timeout command specifies the number of seconds before a call is disconnected after the last interesting traffic is sent. The default is 120 seconds.

RouterA(config-if)#dialer load-threshold 125 either
RouterA(config-if)#dialer idle-timeout 180

The dialer load-threshold 125 tells the BRI interface to bring up the second B channel if either the inbound or outbound traffic load is 50 percent. The dialer idle-timeout 180 changes the default disconnect time from 120 to 180 seconds.

DDR with Access Lists:

You can use access lists to be more specific about what is interesting traffic. In the preceding example we just set the dialer list to allow any IP traffic to bring up the line. That is great if you are testing, but it can defeat the purpose of why you use a DDR line in the first place. You can use extended access lists to set the restriction, for example, to only e-mail or Telnet.

Here is an example of how you define the dialer list to use an access list:

804A(config)#dialer-list 1 list 110
804A(config)#access-list 110 permit tcp any any eq smtp
804A(config)#access-list 110 permit tcp any any eq telnet
804A(config)#int bri0
804A(config-if)#dialer-group 1

In the preceding example, you configure the dialer-list command to look at an access list. This doesn’t have to be IP; it can be used with any protocol. Create your list, then apply it to the BRI interface with the dialergroup command.

Verifying the ISDN Operation:

The following commands can be used to verify legacy DDR and ISDN: Ping and Telnet Are great IP tools for any network. However, your interesting traffic must dictate that Ping and Telnet are acceptable as interesting traffic to bring up a link. Once a link is up, you can ping or telnet to your remote router regardless of your interesting traffic lists. Show dialer Gives good information about your dialer diagnostic information and shows the number of times the dialer string has been reached, the idle-timeout values of each B channel, the length of cal, and the name of the router to which the interface is connected.

Show isdn active Shows the number called and whether a call is in progress.
Show isdn status Is a good command to use before trying to dial.
Shows if your SPIDs are valid and if you are connected and communicating with layers 1 through 3 information to the provider’s switch.
Sho ip route Shows all routes the router knows about.
Debug isdn q921 Is used to see layer-2 information only.
Debug isdn q931 Is used to see layer-3 information, including call setup and teardown.
Debug dialer Gives you call-setup and teardown activity.
Isdn disconnect int bri0 Clears the interface and drops the connection. Performing a shutdown on the interface can give you the same results.

Integrated Services Digital Network

2008-10-08T03:28:00.000-07:00

Integrated Services Digital Network (ISDN)

Integrated Services Digital Network (ISDN) is a digital service designed to run over existing telephone networks. ISDN can support both data and voice—a telecommuter’s dream. But ISDN applications require bandwidth. Typical ISDN applications and implementations include high-speed image applications (such as Group IV facsimile), high-speed file transfer, videoconferencing, and multiple links into homes of telecommuters. ISDN is actually a set of communication protocols proposed by telephone companies that allows them to carry a group of digital services that simultaneously convey data, text, voice, music, graphics, and video to end users, and it was designed to achieve this over the telephone systems already in place. ISDN is referenced by a suite of ITU-T standards that encompass the OSI model’s Physical, Data Link, and Network layers. The ISDN standards define the hardware and call-setup schemes for end-to-end digital connectivity.

PPP is typically used with ISDN to provide data encapsulation, link integrity, and authentication. These are the benefits of ISDN:

* Can carry voice, video, and data simultaneously
* Has faster call setup than a modem
* Has faster data rates than a modem connection

ISDN Components:
The components used with ISDN include functions and reference points. Figure 6 shows how the different types of terminal and reference points can be used in an ISDN network.

In North America, ISDN uses a two-wire connection into a home or office. That is called a “U” reference point. The NT1 device is used to convert the two-wire connection to a four-wire connection that is used by ISDN phones and terminal adapters (TAs). Most routers can now be purchased with a built-in NT1 (U) interface.

Figure 7 shows the different reference points and terminal equipment that can be used with Cisco ISDN BRI interfaces.

ISDN Terminals: Devices connecting to the ISDN network are known as terminal equipment (TE) and network termination (NT) equipment. There are two types of each: TE1 Terminal equipment type 1 refers to those terminals that understand ISDN standards and can plug right into an ISDN network.

TE2 Terminal equipment type 2 refers to those that predate ISDN standards. To use a TE2, you have to use a terminal adapter (TA) to be able to plug into an ISDN network.

NT1 Network termination 1 implements the ISDN Physical layer specifications and connects the user devices to the ISDN network.

NT2 Network termination 2 is typically a provider’s equipment, such as a switch or PBX. It also provides Data Link and Network layer implementation.

It’s very rare at a customer premises.
TA Terminal adapter converts TE2 wiring to TE1 wiring that then connects into an NT1 device for conversion into a two-wire ISDN network.

ISDN Reference Points

Reference points are a series of specifications that define the connection between the various equipment used in an ISDN network. ISDN has four reference points that define logical interfaces:

R reference point Defines the reference point between non-ISDN equipment (TE2) and a TA.
S reference point Defines the reference point between the customer router and an NT2. Enables calls between the different customer equipment.
T reference point Defines the reference point between NT1 and NT2 devices. S and T reference points are electrically the same and can perform the same function. Therefore, they are sometimes referred to as an S/T reference point.
U reference point Defines the reference point between NT1 devices and line-termination equipment in a carrier network. (This is only in North America where the NT1 function isn’t provided by the carrier network.)

ISDN Protocols:

ISDN protocols are defined by the ITU, and there are several series of protocols dealing with diverse issues:

* Protocols beginning with the letter E deal with using ISDN on the existing telephone network.
* Protocols beginning with the letter I deal with concepts, aspects, and services.
* Protocols beginning with the letter Q cover switching and signaling.

ISDN Switch Types

We can credit AT&T and Nortel for the majority of the ISDN switches in place today, but additional companies also make them. In Table 10.1 under “Keyword,” you’ll find the right keyword to use along with the isdn switch-type command to configure a router for the variety of switches it’s going to connect to. If you don’t know which switch your provider is using at their central office, simply call them to find out.

Switch Type Keyword
----------------------------------------------------------
AT&T basic rate switch - Basic-5ess
Nortel DMS-100 basic rate switch - Basic-dms100
National ISDN-1 switch - Basic-ni1
AT&T 4ESS (ISDN PRI only) - Primary-4ess
AT&T 5ESS (ISDN PRI only) - Primary-5ess
Nortel DMS-100 (ISDN PRI only) - Primary-dms100

Basic Rate Interface (BRI): ISDN Basic Rate Interface (BRI, also known as 2B+1D) service provides two B channels and one D channel. The BRI B-channel service operates at 64Kbps and carries data, while the BRI D-channel service operates at 16Kbps and usually carries control and signaling information.

The D-channel signaling protocol spans the OSI reference model’s Physical, Data Link, and Network layers. The D channel carries signaling information to set up and control calls. The D channel can also be used for other functions like an alarm system for a building, or anything that doesn’t need much bandwidth, since it is only a whopping 16k. D channels work with LAPD at the Data Link layer.

When configuring ISDN BRI, you will need to obtain SPIDs (Service Profile Identifiers), and you should have one SPID for each B channel. SPIDs can be thought of as the telephone number of each B channel. The ISDN device gives the SPID to the ISDN switch, which then allows the device to access the network for BRI or PRI service. Without a SPID, many ISDN switches don’t allow an ISDN device to place a call on the network.

To set up a BRI call, four events must take place:

1. The D channel between the router and the local ISDN switch comes up.
2. The ISDN switch uses the SS7 signaling technique to set up a path to a remote switch.
3. The remote switch sets up the D-channel link to the remote router.
4. The B channels are then connected end-to-end.

Primary Rate Interface (PRI):
In North America and Japan, the ISDN Primary Rate Interface (PRI, also known as 23B+D1) service delivers 23 64Kbps B channels and one 64Kbps D channel for a total bit rate of up to 1.544Mbps. In Europe, Australia, and other parts of the world, ISDN provides 30 64Kbps B channels and one 64Kbps D channel for a total bit rate of up to 2.048Mbps.

ISDN with Cisco Routers:
Accessing ISDN with a Cisco router means that you will need to purchase either a router with a built-in NT1 (U reference point) or an ISDN modem (called a TA). If your router has a BRI interface, you’re ready to rock. Otherwise, you can use one of your router’s serial interfaces if you can get ahold of a TA. A router with a BRI interface is called a TE1 (terminal endpoint 1), and one that requires a TA is called a TE2 (terminal endpoint 2). ISDN supports virtually every upper-layer network protocol (IP, IPX, AppleTalk, you name it), and you can choose PPP, HDLC, or LAPD as your encapsulation protocol.

For each ISDN BRI interface, you need to specify the SPIDs that are using the isdn spid1 and isdn spid2 interface subcommands. These are provided by the ISDN provider and identify you on the switch, sort of like a telephone number. However, some providers no longer require SPIDs to be configured on the router. Check with your provider to be sure.

The second part of the SPID configuration is the local dial number for that SPID. It is optional, but some switches need to have those set on the router in order to use both B channels simultaneously.

An example is shown below:

RouterA#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#isdn switch-type basic-ne1
RouterA(config)#int bri0
RouterA(config-if)#encap ppp (optional)
RouterA(config-if)#isdn spid1 086506610100 8650661
RouterA(config-if)#isdn spid2 086506620100 8650662

Data Link Connection Identifiers

2008-10-08T03:16:00.000-07:00

Data Link Connection Identifiers (DLCIs): Frame Relay virtual circuits (PVCs) are identified by DLCIs. A Frame Relay service provider, such as the telephone company, typically assigns DLCI values, which are used by Frame Relay to distinguish between different virtual circuits on the network. Because many virtual circuits can be terminated on one multipoint Frame Relay interface, many DLCIs are often affiliated with it. For the IP devices at each end of a virtual circuit to communicate, their IP addresses need to be mapped to DLCIs. This mapping can function as a multipoint device—one that can identify to the Frame Relay network the appropriate destination virtual circuit for each packet that is sent over the single physical interface. The mappings can be done dynamically through IARP or manually through the Frame Relay map command.

Frame Relay uses DLCIs the same way that X.25 uses X.121 addresses, and every DLCI number can be given either global or local meaning everywhere within the Frame Relay network. Sometimes a provider can give a site a DLCI that is advertised to all remote sites as the same PVC. This PVC is said to have a global significance. For example, a corporate office might have a DLCI of 20. All remote sites would know that the corporate office is DLCI 20 and use this PVC to communicate to the corporate office. However, the customary implementation is to give each DLCI local meaning. What does this mean? It means that DLCI numbers do not necessarily need to be unique. Two DLCI numbers can be the same on different sides of a link because Frame Relay maps a local DLCI number to a virtual circuit on each interface of the switch. Each remote office can have its own DLCI number and communicate with the corporate office using unique DLCI numbers. DLCI numbers, used to identify a PVC, are typically assigned by the provider and start at 16. Configuring a DLCI number to be applied to an interface is shown below:

RouterA(config-if)#frame-relay interface-dlci ?
<16-1007> Define a DLCI as part of the current
subinterface
RouterA(config-if)#frame-relay interface-dlci 16

Local Management Interface (LMI)

The Local Management Interface (LMI) was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation and became known as the Gang-of-Four LMI or Cisco LMI. This gang took the basic Frame Relay protocol from the CCIT and added extensions onto the protocol features that allow internetworking devices to communicate easily with a Frame Relay network.

The LMI is a signaling standard between a CPE device (router) and a frame switch. The LMI is responsible for managing and maintaining status between these devices. LMI messages provide information about the following:

Keepalives Verify data is flowing
Multicasting Provides a local DLCI PVC
Multicast addressing Provides global significance
Status of virtual circuits Provides DLCI status

If you’re not going to use the auto-sense feature, you’ll need to check with your Frame Relay provider to find out which type to use instead. The default type is Cisco, but you may need to hange to ANSI or Q.933A. The three different LMI types are depicted in the router output below.

RouterA(config-if)#frame-relay lmi-type ?
cisco
ansi q933a

As seen in the output, all three standard LMI signaling formats are supported:

Cisco LMI defined by the Gang of Four (default)
ANSI Annex D defined by ANSI standard T1.617
ITU-T (q933a) Annex A defined by Q.933

Routers receive LMI information on a frame-encapsulated interface and update the virtual circuit status to one of three different states: Active state Everything is up and routers can exchange information.

Inactive state The router’s interface is up and working with a connection to the switching office, but the remote router is not working.

Deleted state This means that no LMI information is being received on the interface from the switch. It could be a mapping problem or a line failure.

Partial Meshed Networks
You can use subinterfaces to mitigate partial meshed Frame Relay networks and split horizon protocols. For example, say you were running the IP protocol on a LAN network. If, on the same physical network, Router A can talk to Router B, and Router B to Router C, you can usually assume that Router A can talk to Router C. Though this is true with a LAN, it’s not true with a

Frame Relay network, unless Router A has a PVC to Router C. In Figure 5, Network 1 is configured with five locations. To be able to make this network function, you would have to create a meshed network as shown in Network 2. However, even though Network 2’s example works, it’s an expensive solution—configuring subinterfaces as shown in the Network 3 solution is much more cost-effective.

In Network 3, configuring subinterfaces actually works to subdivide the Frame Relay network into smaller subnetworks—each with its own network number. So locations A, B, and C connect to a fully meshed network, while locations C and D, and D and E, are connected via point-to-point connections.

Locations C and D connect to two subinterfaces and forward packets. Subinterfaces also solve the problem with routing protocols that use split horizon. As you may recall, split horizon protocols do not advertise routes out the same interface they received the route update on. This can cause a problem on a meshed Frame Relay network. However, by using subinterfaces, routing protocols that receive route updates on one subinterface can send out the same route update on another subinterface.

Creating Subinterfaces
You define subinterfaces with the int s0.subinterface number command as shown below. You first set the encapsulation on the serial interface, then you can define the subinterfaces.

RouterA(config)#int s0
RouterA(config)#encapsulation frame-relay
RouterA(config)#int s0.?
<0-4294967295> Serial interface number
RouterA(config)#int s0.16 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link

You can define an almost limitless number of subinterfaces on a given physical interface (keeping router memory in mind). In the above example, we chose to use subinterface 16 because that represents the DLCI number assigned to that interface. However, you can choose any number between 0 and 4,292,967,295.

There are two types of subinterfaces: Point-to-point Used when a single virtual circuit connects one router to another. Each point-to-point subinterface requires its own subnet.

Multipoint Used when the router is the center of a star of virtual circuits. Uses a single subnet for all routers’ serial interfaces connected to the frame switch.

An example of a production router running multiple subinterfaces is shown below. Notice that the subinterface number matches the DLCI number. This is not a requirement but helps in the administration of the interfaces.

Also notice that there is no LMI type defined, which means they are running either the default of Cisco or using autodetect if running Cisco IOS version 11.2 or newer. This configuration was taken from one of my customers’ production routers (used by permission). Notice that each interface is defined as a separate subnet, separate IPX network, and separate Apple-Talk cable range (AppleTalk is beyond the scope of this course):

interface Serial0
no ip address
no ip directed-broadcast
encapsulation frame-relay
!
interface Serial0.102 point-to-point
ip address 10.1.12.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 12-12 12.65
appletalk zone wan2
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 12
frame-relay interface-dlci 102
!
interface Serial0.103 point-to-point
ip address 10.1.13.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 13-13 13.174
appletalk zone wan3
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 13
frame-relay interface-dlci 103
!
interface Serial0.104 point-to-point
ip address 10.1.14.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 14-14 14.131
appletalk zone wan4
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 14
frame-relay interface-dlci 104
!
interface Serial0.105 point-to-point
ip address 10.1.15.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 15-15 15.184
appletalk zone wan5
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 15
frame-relay interface-dlci 105
!
interface Serial0.106 point-to-point
ip address 10.1.16.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 16-16 16.28
appletalk zone wan6
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 16
frame-relay interface-dlci 106
!
interface Serial0.107 point-to-point
ip address 10.1.17.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 17-17 17.223
appletalk zone wan7
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 17
frame-relay interface-dlci 107
!
interface Serial0.108 point-to-point
ip address 10.1.18.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 18-18 18.43
appletalk zone wan8
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 18
frame-relay interface-dlci 108

Mapping Frame Relay
As we explained earlier, in order for IP devices at the ends of virtual circuits
to communicate, their addresses must be mapped to the DLCIs. There are
two ways to make this mapping happen:
* Use the Frame Relay map command.
* Use the inverse-arp function.

Here’s an example using the Frame Relay map command:

RouterA(config)#int s0
RouterA(config-if)#encap frame
RouterA(config-if)#int s0.16 point-to-point
RouterA(config-if)#no inverse-arp
RouterA(config-if)#ip address 172.16.30.1 255.255.255.0
RouterA(config-if)#frame-relay map ip 172.16.30.17 16 ietf
broadcast
RouterA(config-if)#frame-relay map ip 172.16.30.18 17
broadcast
RouterA(config-if)#frame-relay map ip 172.16.30.19 18

Here’s what we did: First, we chose configured interface serial 0 to use the encapsulation type of Cisco (default), then we created our subinterface. We then turned off inverse arp and mapped three virtual circuits and their corresponding DLCI numbers.

Notice that we changed the encapsulation type for the first mapping. The frame map command is the only way to configure multiple frame encapsulation types on an interface. The broadcast keyword at the end of the map command tells the router to forward broadcasts for this interface to this specific virtual circuit.

Remember that Frame Relay is a nonbroadcast multiaccess (NBMA) encapsulation method, which will not broadcast routing protocols. You can either use the map command with the broadcast keyword or the neighbor command within the routing process. Instead of putting in map commands for each virtual circuit, you can use the inverse-arp function to perform dynamic mapping of the IP address to the DLCI number. This makes our configuration look like this:

RouterA(config)#int s0.16 point-to-point
RouterA(config-if)#encap frame-relay ietf
RouterA(config-if)#ip address 172.16.30.1 255.255.255.0

Yes, this configuration is a whole lot easier to do, but it’s not as stable as using the map command. Why? Sometimes, when using the inverse-arp function, configuration errors occur because virtual circuits can be insidiously and dynamically mapped to unknown devices.

Frame Relay Congestion Control
In this section we will define how the Frame Relay switch handles Congestion problems.

DE (Discard Eligibility) When a Frame Relay router detects congestion on the Frame Relay network, it will turn the DE bit on in a Frame Relay packet header. If the switch is congested, the Frame Relay switch will discard the packets with the DE bit set first. If your bandwidth is configured with a CIR of zero, the DE will always be on.

FECN (Forward-Explicit Congestion Notification) When the Frame Relay network recognizes congestion in the cloud, the switch will set the FECN bit to 1 in a Frame Relay packet header. This will indicate to the destination DCE that the path just traversed is congested. BECN (Backward-Explicit Congestion Notification) When the switch detects congestion in the Frame Relay network, it will set the BECN bit in a Frame Relay packet and send it to the source router, telling it to slow down the rate at which it is transmitting packets. Committed Information Rate (CIR)

Frame Relay provides a packet-switched network to many different customers at the same time. This is a great idea because it spreads the cost of the switches among many customers. However, Frame Relay is based on the assumption that not all customers need to transmit constant data all at the same time. Frame Relay works best with bursty traffic. Think of Frame Relay as a party line. Remember party lines? That is when many people on your block had to share the same phone number. Okay, I am showing my age here, but understand that party lines were created on the assumption that few people needed to use the phone each day. If you needed to talk excessively, you had to pay for the more expensive dedicated circuit. Frame Relay works somewhat on the same principle, except many devices can transmit at the same time. However, if you need a constant data-stream connection, then Frame Relay is not for you. Buy a dedicated, point-to-point T-1 instead.

Frame Relay works by providing a dedicated bandwidth to each user, who is committed to that bandwidth at any given time. Frame Relay providers allow customers to buy a lower amount of bandwidth than what they really might need. This is called the Committed Information Rate (CIR). What this means is that the customer can buy bandwidth of, for example, 256k, but it is possible to burst up to T-1 speeds. The CIR specifies that as long as the data input by a device to the Frame Relay network is below or equal to the CIR, then the network will continue to forward data for the PVC. However, if data rates exceed the CIR, it is not guaranteed.

It is sometimes possible to also purchase a Bc (Committed Burst), which allows customers to exceed their CIR for a specified amount of time. In this situation, the DE bit will always be set. Choose a CIR based on realistic, anticipated traffic rates. Some Frame Relay providers allow you to purchase a CIR of zero. You can use a zero CIR to save money if retransmission of packets is acceptable. However, understand that the DE bit will always be turned on in every frame.

Monitoring Frame Relay
There are several ways to check the status of your interfaces and PVCs once you have Frame Relay encapsulation set up and running:

RouterA>sho frame ?
ip show frame relay IP statistics
lmi show frame relay lmi statistics map Frame-Relay map table
pvc show frame relay pvc statistics
route show frame relay route
traffic Frame-Relay protocol statistics
Show Frame-Relay Lmi

The show frame-relay lmi command will give you the LMI traffic statistics exchanged between the local router and the Frame Relay switch.

Router#sh frame lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE
= CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 0
Router#

The router output from the show frame-relay lmi command shows you LMI errors as well as the LMI type.

Show Frame-Relay Pvc
The show frame pvc command will list all configured PVCs and DLCI numbers.
It provides the status of each PVC connection and traffic statistics. It
will also give you the number of BECN and FECN packets received on the
router.

RouterA#sho frame pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 16,DLCI USAGE = LOCAL,PVC STATUS =ACTIVE,INTERFACE
= Serial0.1
input pkts 50977876 output pkts 41822892 in bytes
3137403144
out bytes 3408047602 dropped pkts 5 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 9393 out DE pkts 0
pvc create time 7w3d, last time pvc status changed 7w3d
DLCI = 18,DLCI USAGE =LOCAL,PVC STATUS =ACTIVE,INTERFACE =
Serial0.3
input pkts 30572401 output pkts 31139837 in bytes
1797291100
out bytes 3227181474 dropped pkts 5 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 28 out DE pkts 0
pvc create time 7w3d, last time pvc status changed 7w3d

To see information about only PVC 16, you can type the command show frame-relay pvc 16.

Show Interface : We can also use the show interface command to check for LMI traffic.
The show interface command displays information about the encapsulation as well as layer-2 and layer-3 information.

The LMI DLCI, as bolded in the command, is used to define the type of
LMI being used. If it is 1023, it is the default LMI type of Cisco. If the LMI
DLCI is zero, then it is the ANSI LMI type.

RouterA#sho int s0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/
255, load 2/255
Encapsulation FRAME-RELAY, loopback not set, keepalive
set (10 sec)
LMI enq sent 451751,LMI stat recvd 451750,LMI upd recvd
164,DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 0/0,
interface broadcasts 839294

The show interface command displays line, protocol, DLCI, and LMI information.

Show Frame Map: The show frame map command will show you the Network layer–to–DLCI
mappings.

RouterB#show frame map
Serial0 (up): ipx 20.0007.7842.3575 dlci 16(0x10,0x400),
dynamic, broadcast,, status defined, active
Serial0 (up): ip 172.16.20.1 dlci 16(0x10,0x400),
dynamic,
broadcast,, status defined, active
Serial1 (up): ipx 40.0007.7842.153a dlci 17(0x11,0x410),
dynamic, broadcast,, status defined, active
Serial1 (up): ip 172.16.40.2 dlci 17(0x11,0x410),
dynamic,
broadcast,, status defined, active

Notice that the search interface has two mappings, one for IP and one for IPX. Also, notice that the Network layer addresses were resolved with the dynamic protocol Inverse ARP (IARP). If an administrator mapped the addresses, the output would say “static.”

After the DLCI number is listed, you can see some numbers in parentheses. Notice the first number is 0x10, which is the hex equivalent for the DLCI number 16 used on serial 0, and the 0x11 is the hex for DLCI 17 used on serial 1. The second numbers, 0x400 and 0x410, are the DLCI numbers configured in the Frame Relay frame. They are different because of the way the
bits are spread out in the frame.

Debug Frame Lmi: The debug frame lmi command will show output on the router consoles by default. The information from this command will allow you to verify and troubleshoot the Frame Relay connection by helping you to determine whether the router and switch are exchanging the correct LMI information.

Router#debug frame-relay lmi
Serial3/1(in): Status, myseq 214
RT IE 1, length 1, type 0
KA IE 3, length 2, yourseq 214, myseq 214
PVC IE 0x7 , length 0x6 , dlci 130, status 0x2 , bw 0
Serial3/1(out): StEnq, myseq 215, yourseen 214, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 D7 D6

Serial3/1(in): Status, myseq 215
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 215, myseq 215
Serial3/1(out): StEnq, myseq 216, yourseen 215, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 D8 D7

WAN Frame Relay

2008-10-08T03:08:00.000-07:00

Recently, the high-performance WAN encapsulation method known as Frame Relay has become one of the most popular technologies in use. It operates at the Physical and Data Link layers of the OSI reference model and was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. But today, Frame Relay is used over a variety of other network interfaces. Cisco Frame Relay supports the following protocols:

IP
DECnet
AppleTalk
Xerox Network Service (XNS)
Novell IPX
Connectionless Network Service (CLNS)
International Organization for Standards (ISO)
Banyan Vines
Transparent bridging

Frame Relay provides a communications interface between DTE (Data Terminal Equipment) and DCE (Data Circuit-Terminating Equipment, such as packet switches) devices. DTE consists of terminals, PCs, routers, and bridges—customer-owned end-node and internetworking devices. DCE consists of carrier-owned internetworking devices. Popular opinion maintains that Frame Relay is more efficient and faster than X.25 because it assumes error checking will be done through higherlayer protocols and application services.

Frame Relay provides connection-oriented, Data Link layer communication via virtual circuits just as X.25 does. These virtual circuits are logical connections created between two DTEs across a packet-switched network, which is identified by a DLCI, or Data Link Connection Identifier. (We’ll get to DLCIs in a bit.) Also, like X.25, Frame Relay uses both PVCs (Permanent Virtual Circuits) and SVCs (Switched Virtual Circuits), although most Frame Relay networks use only PVCs. This virtual circuit provides the complete path to the destination network prior to the sending of the first frame.

Frame Relay Terminology:

To understand the terminology used in Frame Relay networks, first you need to know how the technology works. Figure 10.4 is labeled with the various terms used to describe different parts of a Frame Relay network.

The basic idea behind Frame Relay networks is to allow users to communicate between two DTE devices through DCE devices. The users should not see the difference between connecting to and gathering resources from a local server and a server at a remote site connected with Frame Relay. Chances are this connection will be slower than a 10Mbps Ethernet LAN, but the physical difference in the connection should be transparent to the user.

Figure 4 illustrates everything that must happen in order for two DTE devices to communicate. Here is how the process works:

1. The user’s network device sends a frame out on the local network. The hardware address of the router (default gateway) will be in the header of the frame.

2. The router picks up the frame, extracts the packet, and discards the frame. It then looks at the destination IP address within the packet and checks to see whether it knows how to get to the destination network by looking in the routing table.

3. The router then forwards the data out the interface that it thinks can find the remote network. (If it can’t find the network in its routing table, it will discard the packet.) Because this will be a serial interface encapsulated with Frame Relay, the router puts the packet onto the Frame Relay network encapsulated within a Frame Relay frame. It will add the DLCI number associated with the serial interface. DLCIs identify the virtual circuit (PVC or SVC) to the routers and provider’s switches participating in the Frame Relay network.

4. The channel service unit/data service unit (CSU/DSU) receives the digital signal and encodes it into the type of digital signaling that the switch at the Packet Switch Exchange (PSE) can understand. The PSE receives the digital signal and extracts the 1s and 0s from the line.

5. The CSU/DSU is connected to a demarcation (demarc) installed by the service provider, and its location is the service provider’s first point of responsibility (last point on the receiving end). The demarc is typically just an RJ-45 jack installed close to the router and CSU/DSU.

6. The demarc is typically a twisted-pair cable that connects to the local loop. The local loop connects to the closest central office (CO), sometimes called a point of presence (POP). The local loop can connect using various physical mediums, but twisted-pair or fiber is very common.

7. The CO receives the frame and sends it through the Frame Relay “cloud” to its destination. This cloud can be dozens of switching offices—or more! It looks for the destination IP address and DLCI number. It typically can find the DLCI number of the remote device or router by looking up an IP-to-DLCI mapping. Frame Relay mappings are usually created statically by the service provider, but they can be created dynamically using the Inverse ARP (IARP) protocol. Remember that before data is sent through the cloud, the virtual circuit is created from end to end.

8. Once the frame reaches the switching office closest to the destination office, it is sent through the local loop. The frame is received at the demarc and then is sent to the CSU/DSU. Finally, the router extracts the packet, or datagram, from the frame and puts the packet in a new LAN frame to be delivered to the destination host. The frame on the LAN will have the final destination hardware address in the header. This was found in the router’s ARP cache, or an ARP broadcast was performed.

The user and server do not need to know, nor should they know, everything that happens as the frame makes its way across the Frame Relay network. The remote server should be as easy to use as a locally connected resource.

Frame Relay Encapsulation: When configuring Frame Relay on Cisco routers, you need to specify it as an encapsulation on serial interfaces.

There are only two encapsulation types: Cisco and IETF (Internet Engineering Task Force). The following router output shows the two different encapsulation methods when choosing Frame Relay on your Cisco router:

RouterA(config)#int s0
RouterA(config-if)#encapsulation frame-relay ?
ietf Use RFC1490 encapsulation

The default encapsulation is Cisco unless you manually type in IETF, and Cisco is the type used when connecting two Cisco devices. You’d opt for the IETF-type encapsulation if you needed to connect a Cisco device to a non-Cisco device with Frame Relay. So before choosing an encapsulation type, check with your ISP and find out which one they use. (If they don’t know, hook up with a different ISP!)

Point-to-Point Protocol

2008-10-08T02:56:00.001-07:00

PPP (Point-to-Point Protocol) is a data-link protocol that can be used over either asynchronous serial (dial-up) or synchronous serial (ISDN) media and that uses the LCP (Link Control Protocol) to build and maintain data-link connections. The basic purpose of PPP is to transport layer-3 packets across a Data Link layer point-to-point link. Figure 10.3 shows the protocol stack compared to the OSI reference model.

PPP contains four main components:

EIA/TIA-232-C: A Physical-layer international standard for serial communication.
HDLC: A method for encapsulating datagrams over serial links.
LCP: A method of establishing, configuring, maintaining, and terminating the point-to-point connection.
NCP: A method of establishing and configuring different Network layer protocols. PPP is designed to allow the simultaneous use of multiple Network layer protocols. Some examples of protocols here are IPCP (Internet Protocol Control Protocol) and IPXCP (Internetwork Packet Exchange Control Protocol).

It is important to understand that the PPP protocol stack is specified at the Physical and Data Link layers only. NCP is used to allow communication of multiple Network layer protocols by encapsulating the protocols across a PPP data link.

Link Control Protocol (LCP) Configuration Options:

Link Control Protocol offers PPP encapsulation different options, including the following:

Authentication: This option tells the calling side of the link to send information that can identify the user. The two methods discussed in this course are PAP and CHAP.

Compression: This is used to increase the throughput of PPP connections. PPP decompresses the data frame on the receiving end. Cisco uses the Stacker and Predictor compression methods, discussed in the Advanced Cisco Router Configuration course.

Error detection: PPP uses Quality and Magic Number options to ensure a reliable, loop-free data link.

Multilink: Starting in IOS version 11.1, multilink is supported on PPP links with Cisco routers. This splits the load for PPP over two or more parallel circuits and is called a bundle.

PPP Session Establishment:
PPP can be used with authentication. This means that communicating routers must provide information to identify the link as a valid communication link. When PPP connections are started, the links go through three phases of session establishment:

Link-establishment phase: LCP packets are sent by each PPP device to configure and test the link. The LCP packets contain a field called the Configuration Option that allows each device to see the size of the data, compression, and authentication. If no Configuration Option field is present, then the default configurations are used.

Authentication phase: If configured, either CHAP or PAP can be used to authenticate a link. Authentication takes place before Network-layer protocol information is read.

Network-layer protocol phase: PPP uses the Network Control Protocol to allow multiple Network-layer protocols to be encapsulated and sent over a PPP data link.

PPP Authentication Methods: There are two methods of authentication that can be used with PPP links, either Password Authentication Protocol (PAP) or Challenge Authentication Protocol (CHAP).

Password Authentication Protocol (PAP): The Password Authentication Protocol (PAP) is the less secure of the two methods. Passwords are sent in clear text, and PAP is only performed upon the initial link establishment. When the PPP link is first established, the remote node sends back to the sending router the username and password until authentication is acknowledged. That’s it.

Challenge Authentication Protocol (CHAP): The Challenge Authentication Protocol (CHAP) is used at the initial startup of a link and at periodic checkups on the link to make sure the router is still communicating with the same host.

After PPP finishes its initial phase, the local router sends a challenge request to the remote device. The remote device sends a value calculated using a one-way hash function called MD5. The local router checks this hash value to make sure it matches. If the values don’t match, the link is immediately terminated.

Configuring PPP on Cisco Routers: Configuring PPP encapsulation on an interface is a fairly straightforward process. To configure it, follow these router commands:

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int s0

Router(config-if)#encapsulation ppp
Router(config-if)#^Z
Router#

Configuring PPP Authentication:
After you configure your serial interface to support PPP encapsulation, you can then configure authentication using PPP between routers. First set the hostname of the router if it is not already set. Then set the username and password for the remote router connecting to your router.

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# hostname RouterA
RouterA(config)#username todd password cisco

When using the hostname command, remember that the username is the hostname of the remote router connecting to your router. It is case-sensitive. Also, the password on both routers must be the same. It is a plain-text password and can be seen with a show run command. You can configure the password to be encrypted by using the command service passwordconfig before you set the username and password. You must have a username and password configured for each remote system you are going to connect to. The remote routers must also be configured with usernames and passwords.

After you set the hostname, usernames, and passwords, choose the authentication type, either CHAP or PAP.

RouterA#config t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#int s0
RouterA(config-if)#ppp authentication chap
RouterA(config-if)#ppp autherntication pap
RouterA(config-if)#^Z
RouterA#

Verifying PPP Encapsulation:
Now that we have PPP encapsulation enabled, let’s take a look to verify that it’s up and running. You can verify the configuration with the show interface command:

RouterA#show int s0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 172.16.20.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation PPP, loopback not set, keepalive set (10 sec)
LCP Open
Listen: IPXCP
Open: IPCP, CDPCP, ATCP
Last input 00:00:05, output 00:00:05, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops:0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
670 packets input, 31845 bytes, 0 no buffer
Received 596 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
707 packets output, 31553 bytes, 0 underruns
0 output errors, 0 collisions, 18 interface resets
0 output buffer failures, 0 output buffers swapped out 21 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
RouterA#

High-Level Data-Link Control Protocol

2008-10-08T02:54:00.000-07:00

The High-Level Data-Link Control protocol (HDLC) is a popular ISOstandard, bit-oriented Data Link layer protocol. It specifies an encapsulation method for data on synchronous serial data links using frame characters and checksums. HDLC is a point-to-point protocol used on leased lines. No authentication can be used with HDLC.

In byte-oriented protocols, control information is encoded using entire bytes. Bit-oriented protocols, on the other hand, may use single bits to represent control information. Bit-oriented protocols include SDLC, LLC, HDLC, TCP, IP, etc. HDLC is the default encapsulation used by Cisco routers over synchronous serial links. Cisco’s HDLC is proprietary—it won’t communicate with any other vendor’s HDLC implementation—but don’t give Cisco grief for it; everyone’s HDLC implementation is proprietary. Figure 10.2 shows the Cisco HDLC format.

As shown in the figure, the reason that every vendor has a proprietary HDLC encapsulation method is that each vendor has a different way for the HDLC protocol to communicate with the Network layer protocols. If the vendors didn’t have a way for HDLC to communicate with the different layer-3 protocols, then HDLC would only be able to carry one protocol. This propriety header is placed in the data field of the HDLC encapsulation. If you had only one Cisco router and you needed to connect to, say, a Bay router because you had your other Cisco router on order, then you couldn’t use the default HDLC serial encapsulation. You would use something like PPP, which is an ISO standard way of identifying the upper-layer protocols.

WAN Connection Types

2008-10-08T02:52:00.000-07:00

Below Figure shows the different WAN connection types that can be used to connect your LANs together over a DCE network.

The following list explains the WAN connection types:

Leased lines
Typically referred to as a point-to-point or dedicated connection. It is a pre-established WAN communications path from the CPE, through the DCE switch, to the CPE of the remote site, allowing DTE networks to communicate at any time with no setup procedures before transmitting data. It uses synchronous serial lines up to 45Mbps.

Circuit switching
Sets up line like a phone call. No data can transfer before the end-to-end connection is established. Uses dial-up modems and ISDN. It is used for low-bandwidth data transfers.

Packet switching
WAN switching method that allows you to share bandwidth with other companies to save money. Think of packet switching networks as a party line. As long as you are not constantly transmitting data and are instead using bursty data transfers, packet switching can save you a lot of money. However, if you have constant data transfers, then you will need to get a leased line. Frame Relay and X.25 are packetswitching technologies. Speeds can range from 56Kbps to 2.048Mbps.

WAN Support
In this section, we will define the most prominent WAN protocols used today. These are Frame Relay, ISDN, LAPB, HDLC, and PPP. The rest of the chapter will be dedicated to explaining in depth how WAN protocols work and how to configure them with Cisco routers.

Frame Relay
A packet-switched technology that emerged in the early 1990s. Frame Relay is a Data Link and Physical layer specification that provides high performance. Frame Relay assumes that the facilities used are less error prone than when X.25 was used and that they transmit data with less overhead. Frame Relay is more cost-effective than point-to-point links and can typically run at speeds of 64Kbps to 1.544Mbps. Frame Relay provides features for dynamic-bandwidth allocation and congestion control.

ISDN
Integrated Services Digital Network is a set of digital services that transmit voice and data over existing phone lines. ISDN can offer a costeffective solution for remote users who need a higher-speed connection than analog dial-up links offer. ISDN is also a good choice as a backup link for other types of links such as Frame Relay or a T-1 connection.

LAPB
Link Access Procedure, Balanced was created to be used as a connection-oriented protocol at the Data Link layer for use with X.25. It can also be used as a simple Data Link transport. LAPB has a tremendous amount of overhead because of its strict timeout and windowing techniques. You can use LAPB instead of the lower-overhead HDLC if your link is very error prone. However, that typically is not a problem any longer.

HDLC
High-Level Data Link Control was derived from Synchronous Data Link Control (SDLC), which was created by IBM as a Data Link connection protocol. HDLC is a connection-oriented protocol at the Data Link layer, but it has very little overhead compared to LAPB. HDLC was not intended to encapsulate multiple Network layer protocols across the same link. The HDLC header carries no identification of the type of protocol being carried inside the HDLC encapsulation. Because of this, each vendor that uses HDLC has their own way of identifying the Network layer protocol, which means that each vendor’s HDLC is proprietary for their equipment.

PPP
Point-to-Point Protocol is an industry-standard protocol. Because many versions of HDLC are proprietary, PPP can be used to create pointto-point links between different vendors’ equipment. It uses a Network Control Protocol field in the Data Link header to identify the Network layer protocol. It allows authentication and multilink connections and can be run over asynchronous and synchronous links.

WAN - Defining WAN Terms

2008-10-05T01:50:00.000-07:00

Wide Area Networks

To understand WAN technologies, you need to understand the different WAN terms and connection types that can be used to connect your networks together. This section will discuss the different WAN terms and connection types typically used by service providers.

Defining WAN Terms
Before you order a WAN service type, it is important to understand the terms that the service providers use. Customer premises equipment (CPE) Equipment that is owned and located at the subscriber’s premises.

Demarcation (demarc) : The last responsibility of the service provider, usually an RJ-45 jack located close to the CPE. The CPE at this point would be a CSU/DSU or ISDN interface that plugs into the demarc.

Local loop : Connects the demarc to the closest switching office, called a central office.

Central office (CO) : Connects the customers to the provider’s switching network. A CO is sometimes referred to as a point of presence (POP).

Toll network : Trunk lines inside a WAN provider’s network. It is a collection of switches and facilities. It is important to familiarize yourself with these terms, as they are crucial to understanding WAN technologies.

IPX SAP Filters

2008-10-01T10:48:00.000-07:00

IPX SAP filters are implemented using the same tools we’ve been discussing all along in this chapter. They have an important place in controlling IPX SAP traffic. Why is this important? Because if you can control the SAPs, you can control the access to IPX devices. IPX SAP filters use access lists in the 1000–1099 range.

IPX SAP filters should be placed as close as possible to the source of the SAP broadcasts; this is to stop unwanted SAP traffic from crossing a network because it will only be discarded.

Two types of access list filters control SAP traffic: IPX input SAP filter This is used to stop certain SAP entries from entering a router and updating the SAP table.

IPX output SAP filter This stops certain SAP updates from being sent in the regular 60-second SAP updates.

Here’s the template for each line of an IPX SAP filter:

access-list {number} {permit/deny} {source} {service type} Here is an example of an IPX SAP filter that allows service type 4 (file services)

from a NetWare service named Sales.

Router(config)#access-list 1010 permit ?
-1 Any IPX net
<0-ffffffff> Source net
N.H.H.H Source net.host address
Router(config)#access-list 1010 permit -1 ?
<0-ffff> Service type-code (0 matches all services)
N.H.H.H Source net.host mask

Router(config)#access-list 1010 permit -1 4 ?
WORD A SAP server name

Router(config)#access-list 1010 permit -1 4 Sales

The –1 in the access list is a wildcard that says any node, any network.

After the list is created, apply it to an interface with either of the two following commands:

RouterA(config-if)#ipx input-sap-filter
RouterA(config-if)#ipx output-sap-filter

The input-sap-filter is used to stop SAP entries from being added to the SAP table on the router, and the output-sap-filter is used to stop SAP entries from being propagated out of the router.

Verifying IPX Access Lists
To verify the IPX access lists and their placement on a router, use the commands

show ipx interface and show ipx access-list.

Notice in the output of the show ipx interface command that the IPX address is shown, the outgoing access list is set with list 810, and the SAP input filter is 1010.

Router#sh ipx int
Ethernet0 is up, line protocol is up
IPX address is 10.0060.7015.63d6, NOVELL-ETHER [up]
Delay of this IPX network, in ticks is 1 throughput 0 link delay 0
IPXWAN processing not enabled on this interface.
IPX SAP update interval is 1 minute(s)
IPX type 20 propagation packet forwarding is disabled
Incoming access list is not set
Outgoing access list is 810
IPX helper access list is not set
SAP GNS processing enabled, delay 0 ms, output filter list is not set
SAP Input filter list is 1010
SAP Output filter list is not set
SAP Router filter list is not set
Input filter list is not set
Output filter list is not set
Router filter list is not set
Netbios Input host access list is not set
Netbios Input bytes access list is not set
Netbios Output host access list is not set
Netbios Output bytes access list is not set

Updates each 60 seconds, aging multiples RIP: 3 SAP: 3

SAP interpacket delay is 55 ms, maximum size is 480 bytes
RIP interpacket delay is 55 ms, maximum size is 432 bytes

The show ipx access-list shows the two IPX lists set on the router.

Router#sh ipx access-list
IPX access list 810
permit FFFFFFFF 30
IPX SAP access list 1010
permit FFFFFFFF 4 Sales
Router#

The Fs are hexadecimal and are the same as all 1s or permit any. Since you used the –1 in the IPX commands, the running-config shows them as all Fs.

IPX Access Lists

2008-10-01T10:42:00.001-07:00

IPX access lists are configured the same way as any other list. You use the access-list command to create your access list of packet tests and then apply the list to an interface with the access-group command.

I will discuss the following IPX access lists: IPX standard These access lists filter on IPX source and destination host or network number. They use the access-list numbers 800–899. IPX standard access lists are similar to IP standard access lists, except that IP standards only filter on source IP addresses, whereas IPX standards filter on source and destination IPX addresses.

IPX extended These access lists filter on IPX source and destination host or network number, IPX protocol field in the Network layer header, and socket number in the Transport layer header. They use the access list numbers 900–999.

IPX SAP filter These filters are used to control SAP traffic on LANs and WANs. IPX SAP filters use the access list numbers 1000–1099. Network administrators can set up IPX access lists to control the amount of IPX traffic, including IPX SAPs across low WAN links.

Standard IPX Access Lists
Standard IPX access lists use the source or destination IPX host or network address to filter the network. This is configured much the same way IP standard access lists are. The parameter to configure IPX standard access lists is access-list 800-899 deny or permit source_Address destination_address Wildcards can be used for the source and destination IPX addresses; however, the wildcard is –1, which means it is equal to any host and network.

The below Figure shows an example of an IPX network and how IPX standard access lists can be configured.

The following configuration is used with Figure 9.2. Interface Ethernet 0 is on Network 40; interface Ethernet 1 is on Network 10; interface Ethernet 2 is on Network 20; interface Ethernet 3 is on Network 30.

The access list is configured and applied as shown. This IPX access list permits packets generated from IPX Network 20 out interface Ethernet 0 to Network 40.

Router(config)#access-list 810 permit 20 40
Router(config)#int e0
Router(config-if)#ipx access-group 810 out

Think about what this configuration accomplishes. First and most obvious, any IPX devices on IPX Network 20 off interface Ethernet 2 can communicate to the server on Network 40, which is connected to interface Ethernet 0. However, notice what else this configuration accomplishes with only one line (remember that there is an implicit deny all at the end of the list):

Hosts on Network 10 cannot communicate to the server on Network 40.
Hosts on Network 40 can get to Network 10, but the packets cannot get back.
Hosts on Network 30 can communicate to Network 10, and Network 10 can communicate to Network 30.
Hosts on Network 30 cannot communicate to the server on Network 40.
Hosts on Network 40 can get to hosts on Network 30, but the packets can’t come back from Network 30 in response.
Hosts on Network 20 can communicate to all devices in the internetwork.
Extended IPX Access Lists
Extended IPX access lists can filter based on any of the following:
Source network/node
Destination network/node
IPX protocol (SAP, SPX, etc.)
IPX socket

These are access lists in the range of 900–999 and are configured just like standard access lists, with the addition of protocol and socket information.

Let’s take a look at a template for building lines in an IPX extended access list.
access-list {number} {permit/deny} {protocol} {source}{socket} {destination} {socket}

Again, when you move from standard to extended access lists, you’re simply adding the ability to filter based on protocol and socket (port for IP).

Extended IP Access Lists

2008-10-01T10:37:00.001-07:00

In the standard IP access list example, notice how you had to block the whole subnet from getting to the finance department. What if you wanted them to gain access to only a certain server on the Finance LAN, but not to other network services, for obvious security reasons? With a standard IP access list, you can’t allow users to get to one network service and not another. However, extended IP access lists allow you to do this. Extended IP access lists allow you to choose your IP source and destination address as well as the protocol and port number, which identify the upper-layer protocol or application.

By using extended IP access lists, you can effectively allow users access to a physical LAN and stop them from using certain services. Here is an example of an extended IP access list. The first command shows the access list numbers available. You’ll use the extended access list range from 100 to 199.

RouterA(config)# access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<200-299> Protocol type-code access list
<300-399> DECnet access list
<400-499> XNS standard access list
<500-599> XNS extended access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list

At this point, you need to decide what type of list entry you are making. For this example, you’ll choose a deny list entry.

RouterA(config)#access-list 110 ?
deny Specify packet
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit Specify packets to forward

Once you choose the access list type, you must choose a Network layer protocol field entry. It is important to understand that if you want to filter the network by Application layer, you must choose an entry here that allows you to go up through the OSI model. For example, to filter by Telnet or FTP, you must choose TCP here. If you were to choose IP, you would never leave the Network layer, and you would not be allowed to filter by upper-layer applications.

RouterA(config)#access-list 110 deny ?
<0-255> An IP protocol number
eigrp Cisco's EIGRP routing protocol
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco's IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
tcp Transmission Control Protocol
udp User Datagram Protocol
Once you choose to go up to the Application layer through TCP, you will
be prompted for the source IP address of the host or network. You can
choose the any command to allow any source address.
RouterA(config)#access-list 110 deny tcp ?
A.B.C.D Source address
any Any source host
host A single source host
After the source address is selected, the destination address is chosen.
RouterA(config)#access-list 110 deny tcp any ?
A.B.C.D Destination address
any Any destination host
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host

lt Match only packets with a lower port number neq Match only packets not on a given port number range Match only packets in the range of port numbers In the example below, any source IP address that has a destination IP address of 172.16.30.2 has been denied.

RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 ?
eq Match only packets on a given port number
established Match established connections
fragments Check fragments
gt Match only packets with a greater port
number
log Log matches against this entry
log-input Log matches against this entry,including inputinterface
lt Match only packets with a lower port number
neq Match only packets not on a given port number
precedence Match packets with given precedence value
range Match only packets in the range of port numbers
tos Match packets with given TOS value

Now, you can press Enter here and leave the access list as is. However, you can be even more specific: once you have the host addresses in place, you can specify the type of service you are denying. The following help screen gives you the options. You can choose a port number or use the application or even the program name.

RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 eq ?
<0-65535> Port number
bgp Border Gateway Protocol (179)
chargen Character generator (19)
cmd Remote commands (rcmd, 514)
daytime Daytime (13)
discard Discard (9)
domain Domain Name Service (53)
echo Echo (7)
exec Exec (rsh, 512)
finger Finger (79)
ftp File Transfer Protocol (21)
ftp File Transfer Protocol (21)
gopher Gopher (70)
hostname NIC hostname server (101)
ident Ident Protocol (113)
irc Internet Relay Chat (194)
klogin Kerberos login (543)
kshell Kerberos shell (544)
login Login (rlogin, 513)
lpd Printer service (515)
nntp Network News Transport Protocol (119)
pop2 Post Office Protocol v2 (109)
pop3 Post Office Protocol v3 (110)
smtp Simple Mail Transport Protocol (25)
sunrpc Sun Remote Procedure Call (111)
syslog Syslog (514)
tacacs TAC Access Control System (49)
talk Talk (517)
telnet Telnet (23)
time Time (37)
uucp Unix-to-Unix Copy Program (540)
whois Nicname (43)
www World Wide Web (HTTP, 80)

At this point, let’s block Telnet (port 23) to host 172.16.30.2 only. If the users want to FTP, that is allowed. The log command is used to send messages to the console every time the access list is hit. This would not be a good thing to do in a busy environment, but it is great when used in a class or in a home network.

RouterA(config)#access-list 110 deny tcp any host 172.16.30.2 eq 23 log

You need to keep in mind that the next line is an implicit deny any by default. If you apply this access list to an interface, you might as well just shut the interface down, since by default there is an implicit deny all at the end of every access list. You must follow up the access list with the following command:

RouterA(config)#access-list 110 permit ip any 0.0.0.0 255.255.255.255

Remember, the 0.0.0.0 255.255.255.255 is the same command as any.

Once the access list is created, you need to apply it to an interface. It is the same command as the IP standard list:

RouterA(config-if)#ip access-group 110 in or RouterA(config-if)#ip access-group 110 out

Extended IP Access List Example

Using Figure 9.1 from the IP standard access list example again, let’s use the same network and deny access to a server on the finance-department LAN for both Telnet and FTP services on server 172.16.10.5. All other services on the LAN are acceptable for the sales and marketing departments to access.

The following access list should be created:

Acme#config t
Acme(config)#access-list 110 deny tcp any host 172.16.10.5 eq 21
Acme(config)#access-list 110 deny tcp any host 172.16.10.5 eq 23
Acme(config)#access-list 110 permit ip any any

It is important to understand why the denies were placed first in the list. This is because if you had configured the permits first and the denies second, the Finance LAN would have not been able to go to any other LAN or to the Internet because of the implicit deny at the end of the list. It would be difficult to configure the list any other way than the preceding example. After the lists are created, they need to be applied to the Ethernet 0 port. This is because the other three interfaces on the router need access to the LAN.

However, if this list were created to only block Sales, then we would have wanted to put this list closest to the source, or on Ethernet interface 2.

Acme(config-if)#ip access-group 110 out

Monitoring IP Access Lists
It is important to be able to verify the configuration on a router. The following commands can be used to verify the configuration:

show access-list Displays all access lists and their parameters configured on the router. This command does not show you which interface the list is set on.

show access-list 110 Shows only the parameters for the access list 110. This command does not show you the interface the list is set on.

show ip access-list Shows only the IP access lists configured on the router.

show ip interface Shows which interfaces have access lists set.

show running-config Shows the access lists and which interfaces have access lists set.

Standard IP Access Lists

2008-10-01T10:31:00.002-07:00

Standard IP access lists filter the network by using the source IP address in an IP packet. You create a standard IP access list by using the access list numbers 1–99.

Here is an example of the access list numbers that you can use to filter your network. The different protocols that you can use with access lists depend on your IOS version.

RouterA(config)# access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1000-1099> IPX SAP access list
<1100-1199> Extended 48-bit MAC address access list
<1200-1299> IPX summary address access list
<200-299> Protocol type-code access list
<300-399> DECnet access list
<400-499> XNS standard access list
<500-599> XNS extended access list
<600-699> Appletalk access list
<700-799> 48-bit MAC address access list
<800-899> IPX standard access list
<900-999> IPX extended access list

By using the access list numbers between 1–99, you tell the router that you want to create a standard IP access list.

RouterA(config)# access-list 10 ?

deny Specify packets to reject
permit Specify packets to forward

After you choose the access list number, you need to decide if you are creating a permit or deny list. For this example, you will create a deny statement:

RouterA(config)# access-list 10 deny ?

Hostname or A.B.C.D ---- Address to match
any -------------------- Any source
host -------------------- host A single host address

The next step requires a more detailed explanation. There are three options available. You can use the any command to permit or deny any host or network, you can use an IP address to specify or match a specific network or IP host, or you can use the host command to specify a specific host only.

Here is an example of using the host command:

RouterA(config)# access-list 10 deny host 172.16.30.2

This tells the list to deny any packets from host 172.16.30.2. The default command is host. In other words, if you type access-list 10 deny 172.16.30.2, the router assumes you mean host 172.16.30.2.

However, there is another way to specify a specific host: you can use wildcards. In fact, to specify a network or a subnet, you have no option but to use wildcards in the access list.

Wildcards

Wildcards are used with access lists to specify a host, network, or part of a network. To understand wildcards, you need to understand block sizes.

Block sizes are used to specify a range of addresses. The following list shows some of the different block sizes available. When you need to specify a range of addresses, you choose the closest block size for your needs. For example, if you need to specify 34 networks, you need a block size of 64. If you want to specify 18 hosts, you need a block size of 32. If you only specify two networks, then a block size of 4 would work. Wildcards are used with the host or network address to tell the router a range of available addresses to filter. To specify a host, the address would look like this: 172.16.30.5 0.0.0.0

The four zeros represent each octet of the address. Whenever a zero is present, it means that octet in the address must match exactly. To specify that an octet can be any value, the value of 255 is used. As an example, here is how a full subnet is specified with a wildcard:
172.16.30.0 0.0.0.255

This tells the router to match up the first three octets exactly, but the fourth octet can be any value.

Block Sizes
64
32
16
8
4

Now, that was the easy part. What if you want to specify only a small range of subnets? This is where the block sizes come in. You have to specify the range of values in a block size. In other words, you can’t choose to specify 20 networks. You can only specify the exact amount as the block size value. For example, the range would either have to be 16 or 32, but not 20. Let’s say that you want to block access to part of network that is in the range from 172.16.8.0 through 172.16.15.0. That is a block size of 8. Your network number would be 172.16.8.0, and the wildcard would be 0.0.7.255. Whoa! What is that? The 7.255 is what the router uses to determine the block size. The network and wildcard tell the router to start at 172.16.8.0 and go up a block size of eight addresses to network 172.16.15.0.

It is actually easier than it looks. I could certainly go through the binary math for you, but actually all you have to do is remember that the wildcard is always one number less than the block size. So, in our example, the wildcard would be 7 since our block size is 8. If you used a block size of 16, the wildcard would be 15.

We’ll go through some examples to help you really understand it. The following example tells the router to match the first three octets exactly but that the fourth octet can be anything.

RouterA(config)# access-list 10 deny 172.16.10.0 0.0.0.255

The next example tells the router to match the first two octets and that the last two octets can be any value.

RouterA(config)# access-list 10 deny 172.16.0.0 0.0.255.255

Try to figure out this next line:

RouterA(config)# access-list 10 deny 172.16.16.0 0.0.3.255

The above configuration tells the router to start at network 172.16.16.0 and use a block size of 4. The range would then be 172.16.16.0 through 172.16.19.0.

The example below shows an access list starting at 172.16.16.0 and going up a block size of 8 to 172.16.23.0.

RouterA(config)# access-list 10 deny 172.16.16.0 0.0.7.255

The next example starts at network 172.16.32.0 and goes up a block size of 32 to 172.16.63.0.

RouterA(config)# access-list 10 deny 172.16.32.0 0.0.31.255

The last example starts at network 172.16.64.0 and goes up a block size of 64 to 172.16.127.0.

RouterA(config)# access-list 10 deny 172.16.64.0 0.0.63.255

Here are two more things to keep in mind when working with block sizes and wildcards:

Each block size must start at 0. For example, you can’t say that you want a block size of 8 and start at 12. You must use 0–7, 8–15, 16–23,etc. For a block size of 32, the ranges are 0–31, 32–63, 64–95, etc.

The command any is the same thing as writing out the wildcard 0.0.0.0 255.255.255.255.

Standard IP Access List Example: In this section, you’ll learn how to use a standard IP access list to stop certain users from gaining access to the finance-department LAN. In Figure 9.1, a router has three LAN connections and one WAN connection to the Internet. Users on the Sales LAN should not have access to the Finance LAN, but they should be able to access the Internet and the marketing department. The Marketing LAN needs to access the Finance LAN for application services.

On the Acme router, the following standard IP access list is applied:

Acme# config t
Acme(config)#access-list 10 deny 172.16.40.0 0.0.0.255
Acme(config)#access-list 10 permit any

It is very important to understand that the any command is the same thing as saying this:

Acme(config)#access-list 10 permit 0.0.0.0 255.255.255.255

At this point, the access list is denying the Sales LAN and allowing everyone else. But where should this access list be placed? If you place it as an incoming access list on E2, you might as well shut down the Ethernet interface because all of the Sales LAN devices are denied access to all networks attached to the router. The best place to put this router is the E0 interface as an outbound list.

Acme(config)#int e0
Acme(config-if)#ip access-group 10 out

This completely stops network 172.16.40.0 from getting out Ethernet 0, but it can still access the Marketing LAN and the Internet.

Controlling VTY (Telnet) Access

You will have a difficult time trying to stop users from telnetting into a router because any active port on a router is fair game for VTY access. However, you can use a standard IP access list to control access by placing the access list on the VTY lines themselves.

To perform this function:

Create a standard IP access list that permits only the host or hosts you want to be able to telnet into the routers.

Apply the access list to the VTY line with the access-class command.

Here is an example of allowing only host 172.16.10.3 to telnet into a router:

RouterA(config)#access-list 50 permit 172.16.10.3
RouterA(config)#line vty 0 4
RouterA(config-line)#access-class 50 in

Because of the implied deny any at the end of the list, the access list stops any host from telnetting into the router except the host 172.16.10.3.

Access Lists Basics

2008-10-01T10:24:00.001-07:00

Access lists are essentially lists of conditions that control access. They’re powerful tools that control access both to and from network segments. They can filter unwanted packets and be used to implement security policies. With the right combination of access lists, network managers will be armed with the power to enforce nearly any access policy they can invent. The IP and IPX access lists work similarly—they’re both packet filters that packets are compared with, categorized by, and acted upon. Once the lists are built, they can be applied to either inbound or outbound traffic on any interface. Applying an access list will then cause the router to analyze every packet crossing that interface in the specified direction and take action accordingly.

There are a few important rules a packet follows when it’s being compared with an access list:

It’s always compared with each line of the access list in sequential order, i.e., it’ll always start with line 1, then go to line 2, then line 3, and so on.

It’s compared with lines of the access list only until a match is made. Once the packet matches a line of the access list, it’s acted upon, and no further comparisons take place.

There is an implicit “deny” at the end of each access list—this means that if a packet doesn’t match up to any lines in the access list, it’ll be discarded.

Each of these rules has some powerful implications when filtering IP and IPX packets with access lists.

There are two types of access lists used with IP and IPX:

Standard access lists

These use only the source IP address in an IP packet to filter the network. This basically permits or denies an entire suite of protocols. IPX standards can filter on both source and destination IPX address.

Extended access lists

These check for both source and destination IP address, protocol field in the Network layer header, and port number at the Transport layer header. IPX extended access lists use source and destination IPX addresses, Network layer protocol fields, and socket numbers in the Transport layer header.

Once you create an access list, you apply it to an interface with either an inbound or outbound list:

Inbound access lists: Packets are processed through the access list before being routed to the outbound interface.

Outbound access lists: Packets are routed to the outbound interface and then processed through the access list.

There are also some access list guidelines that should be followed when creating and implementing access lists on a router:

You can only assign one access list per interface, per protocol, or per direction. This means that if you are creating IP access lists, you can only have one inbound access list and one outbound access list per interface.

Organize your access lists so that the more specific tests are at the top of the access list.

Anytime a new list is added to the access list, it will be placed at the bottom of the list.

You cannot remove one line from an access list. If you try to do this, you will remove the entire list. It is best to copy the access list to a text editor before trying to edit the list. The only exception is when using named access lists.

Unless your access list ends with a permit any command, all packets will be discarded if they do not meet any of the lists’ tests. Every list should have at least one permit statement, or you might as well shut the interface down.

Create access lists and then apply them to an interface. Any access list applied to an interface without an access list present will not filter traffic.

Access lists are designed to filter traffic going through the router. They will not filter traffic originated from the router.

Place IP standard access lists as close to the destination as possible.

Place IP extended access lists as close to the source as possible.

VTP Modes of Operation

2008-10-01T02:53:00.001-07:00

There are thee different modes of operation within a VTP domain. Figure 4 shows all three.

Server : Is the default for all Catalyst switches. You need at least one server in your VTP domain to propagate VLAN information throughout the domain. The switch must be in server mode to be able to create, add, or delete VLANs in a VTP domain. Changing VTP information must also be done in server mode. Any change made to a switch in server mode is advertised to the entire VTP domain.

Client : Receives information from VTP servers and send and receives updates, but cannot make any changes. No ports on a client switch can be added to a new VLAN before the VTP server notifies the client switch of the new VLAN. If you want a switch to become a server, first make it a client so it receives all the correct VLAN information, then change it to a server.

Transparent : Does not participate in the VTP domain but will still forward VTP advertisements through the configured trunk links. VTP transparent switches can add and delete VLANs as the switch keeps its own database and does not share it with other switches. Transparent is considered only locally significant.

Configuration Revision Number: The revision number is the most important piece in the VTP advertisement. Figure shows an example of how a revision number is used in an advertisement.

This figure shows a configuration revision number as “N.” As a database is modified, the VTP server increments the revision number by 1. The VTP server then advertises the database with the new configuration revision number. When a switch receives an advertisement that has a higher revision number, it overwrites the database in NVRAM with the new database being advertised.

VTP Pruning: You can preserve bandwidth by configuring the VTP to reduce the amount of broadcasts, multicasts, and other unicast packets, which helps preserve bandwidth. This is called pruning. VTP pruning only sends broadcasts to trunk links that must have the information; any trunk link that does not need the broadcasts will not receive them. For example, if a switch does not have any ports configured for VLAN 5, and a broadcast is sent throughout VLAN 5, the broadcast would not traverse the trunk link to this switch. VTP pruning is disabled by default on all switches.

When you enable pruning on a VTP server, you enable it for the entire domain. By default, VLANs 2–1005 are pruning-eligible. VLAN 1 can never prune because it is an administrative VLAN.

Routing between VLANs

2008-10-01T02:49:00.001-07:00

Hosts in a VLAN are within their own broadcast domain and communicate freely. VLANs create network partitioning and traffic separation at layer 2 of the OSI specifications. To have hosts or any device communicate between VLANs, a layer-3 device is absolutely necessary.

You can use a router that has an interface for each VLAN, or a router that supports ISL routing. The least expensive router that supports ISL routing is the 2600 series router. The 1600, 1700, and 2500 series do not support ISL routing.

If you only had a few VLANs (two or three), you could get a router with two or three 10BaseT or FastEthernet connections. 10BaseT is OK, but FastEthernet will work really well. However, if you have more VLANs available than router interfaces, you can either run ISL routing on one FastEthernet interface or buy a route switch module (RSM) for a 5000 series switch. The RSM can support up to 1005 VLANs and run on the backplane of the switch. If you use one Fast-Ethernet interface and run ISL routing, Cisco calls this a router-on-a-stick.

VLAN Trunk Protocol (VTP)

Cisco created VLAN Trunk Protocol (VTP) to manage all the configured VLANs across a switched internetwork and to maintain consistency throughout the network. VTP allows an administrator to add, delete, and rename VLANs, which are then propagated to all switches.

VTP provides the following benefits to a switched network:

Consistent VLAN configuration across all switches in the network
Allowing VLANs to be trunked over mixed networks, like Ethernet to
ATM LANE or FDDI
Accurate tracking and monitoring of VLANs
Dynamic reporting of added VLANs to all switches
Plug-and-Play VLAN adding

To allow VTP to manage your VLANs across the network, you must first create a VTP server. All servers that need to share VLAN information must use the same domain name, and a switch can only be in one domain at a time. This means that a switch can only share VTP domain information with switches configured in the same VTP domain.

A VTP domain can be used if you have more than one switch connected in a network. If all switches in your network are in only one VLAN, then you don’t need to use VTP. VTP information is sent between switches via a trunk port.

Switches advertise VTP-management domain information, as well as a configuration revision number and all known VLANs with any specific parameters. You can configure switches to forward VTP information through trunk ports but not accept information updates, nor update their VTP database. This is called VTP transparent mode.

If you are having problems with users adding switches to your VTP domain, you can add passwords, but remember that every switch must be set up with the same password, which may be difficult.

Switches detect the additional VLANs within a VTP advertisement and then prepare to receive information on their trunk ports with the newly defined VLAN in tow. The information would be VLAN ID, 802.10 SAID fields, or LANE information. Updates are sent out as revision numbers that are the notification plus 1. Anytime a switch sees a higher revision number, it knows the information it is receiving is more current and will overwrite the current database with the new one.

VLAN Identification Methods

2008-10-01T02:41:00.000-07:00

To keep track of frames traversing a switch fabric, VLAN identification is used to identify which frames belong to which VLANs. There are multiple trunking methods:

Inter-Switch Link (ISL)
Proprietary to Cisco switches, it is used for FastEthernet and Gigabit Ethernet links only. Can be used on a switch port, router interfaces, and server interface cards to trunk a server. This server trunking is good if you are creating functional VLANs and don’t want to break the 80/20 rule. The server that is trunked is part of all VLANs (broadcast domains) simultaneously. The users do not have to cross a layer-3 device to access a company-shared server.

IEEE 802.1q
Created by the IEEE as a standard method of frame tagging. It actually inserts a field into the frame to identify the VLAN. If you are trunking between a Cisco switched link and a different brand of switch, you have to use 802.1q for the trunk to work.

LAN emulation (LANE)
Used to communicate multiple VLANs over ATM.

802.10 (FDDI)
Used to send VLAN information over FDDI. Uses a SAID field in the frame header to identify the VLAN. This is proprietary to Cisco devices.

Inter-Switch Link (ISL) Protocol

Inter-Switch Link (ISL) is a way of explicitly tagging VLAN information onto an Ethernet frame. This tagging information allows VLANs to be multiplexed over a trunk link through an external encapsulation method. By running ISL, you can interconnect multiple switches and still maintain VLAN information as traffic travels between switches on trunk links. ISL provides a low-latency, full wire-speed performance over FastEthernet using either half- or full-duplex mode.

Cisco created the ISL protocol, and therefore ISL is proprietary in nature to Cisco devices only. If you need a non-proprietary VLAN protocol, use the 802.1q, which is covered in the CCNP: Switching Study Guide.

ISL is an external tagging process, which means the original frame is not altered but instead encapsulated with a new 26-byte ISL header. It also adds a second 4-byte frame check sequence (FCS) field at the end of the frame. Because the frame is encapsulated with information, only ISL-aware devices can read it. Also, the frame can be up to 1522 bytes long. Devices that receive an ISL frame may record this as a giant frame because it is over the maximum of 1518 bytes allowed on an Ethernet segment.

On multi-VLAN (trunk) ports, each frame is tagged as it enters the switch. ISL network interface cards (NICs) allow servers to send and receive frames tagged with multiple VLANs so the frames can traverse multiple VLANs without going through a router, which reduces latency. This technology can also be used with probes and certain network analyzers. It makes it easy for users to attach to servers quickly and efficiently, without going through a router every time they need to communicate with a resource. Administrators can use the ISL technology to include file servers in multiple VLANs simultaneously, for example. It is important to understand that ISL VLAN information is added to a frame only if the frame is forwarded out a port configured as a trunk link. The ISL encapsulation is removed from the frame if the frame is forwarded out an access link.

Trunking
Trunk links are 100- or 1000Mbps point-to-point links between two switches, between a switch and router, or between a switch and server. Trunked links carry the traffic of multiple VLANs, from 1 to 1005 at a time. You cannot run trunked links on 10Mbps links. Trunking allows you to make a single port part of multiple VLANs at the same time. The benefit of trunking is that a server, for example, can be in two broadcast domains at the same time. This will stop users from having to cross a layer-3 device (router) to log in and use the server. Also, when connecting switches together, trunk links can carry some or all VLAN information across the link. If you do not trunk these links between switches, then the switches will only send VLAN 1 information by default across the link. All VLANs are configured on a trunked link unless cleared by an administrator by hand. Cisco switches use the Dynamic Trunking Protocol (DTP) to manage trunk negation in the Catalyst-switch engine software release 4.2 or later, using either ISL or 802.1q. DTP is a point-to-point protocol that was created to send trunk information across 802.1q trunks.

Identifying VLANs

2008-10-01T02:30:00.000-07:00

Identifying VLANs

VLANs can span multiple connected switches. Switches in this switchfabric must keep track of frames and which VLAN frames belong to. Frametagging performs this function. Switches can then direct frames to the appropriate port.

There are two different types of links in a switched environment: Access links Links that are only part of one VLAN and are referred to asthe native VLAN of the port. Any device attached to an access link isunaware of a VLAN membership. This device just assumes it is part of a broadcast domain, with no understanding of the physical network.Switches remove any VLAN information from the frame before it is set to an access link device. Access link devices cannot communicate with devices outside their VLAN unless the packet is routed through a router.

Trunk links
Trunks can carry multiple VLANs. Originally named aftertrunks of the telephone system, which carries multiple telephone conversations,trunk links are used to connect switches to other switches, to routers, or even to servers. Trunked links are supported on Fast or Gigabit Ethernet only. To identify the VLAN that a frame belongs to with Ethernet technology, Cisco switches support two different identification techniques: ISL and 802.1q. Trunk links are used to transport VLANs between devices and can be configured to transport all VLANs or just a few. Trunk links still have a native, or default, VLAN that is used if the trunk link fails.

Frame Tagging
The switch in an internetwork needs a way of keeping track of users and frames as they travel the switch fabric and VLANs. A switch fabric is a group of switches sharing the same VLAN information. Frame identification ( frame tagging) uniquely assigns a user-defined ID to each frame. This is sometimes referred to as a VLAN ID or color. Cisco created frame tagging to be used when an Ethernet frame traverses a trunked link. The VLAN tag is removed before exiting trunked links. Each switch that the frame reaches must identify the VLAN ID, then determine
what to do with the frame based on the filter table. If the frame reaches a switch that has another trunked link, the frame will be forwarded out the trunk link port. Once the frame reaches an exit to an access link, the switch removes the VLAN identifier. The end device will receive the frames without having to understand the VLAN identification.

VLAN Memberships

2008-10-01T02:20:00.000-07:00

VLANs are typically created by an administrator, who then assigns switch ports to the VLAN. These are called static VLANs. If the administrator wants to do a little more work up front and assign all the host devices’ hardware addresses into a database, the switches can be configured to assign VLANs dynamically.

Static VLANs

Static VLANs are the typical way of creating VLANs and the most secure. The switch port that you assign a VLAN association always maintains that association until an administrator changes the port assignment. This type of VLAN configuration is easy to set up and monitor, working well in a network where the movement of users within the network is controlled. Using network management software to configure the ports can be helpful but is not mandatory.

Dynamic VLANs

Dynamic VLANs determine a node’s VLAN assignment automatically. Using intelligent management software, you can enable hardware (MAC) addresses, protocols, or even applications to create dynamic VLANs. For example, suppose MAC addresses have been entered into a centralized VLAN management application. If a node is then attached to an unassigned switch port, the VLAN management database can look up the hardware address and assign and configure the switch port to the correct VLAN. This can make management and configuration easier for the administrator. If a user moves, the switch will automatically assign them to the correct VLAN. However, more administration is needed initially to set up the database.

Cisco administrators can use the VLAN Management Policy Server (VMPS) service to set up a database of MAC addresses that can be used for dynamic addressing of VLANs. VMPS is a MAC address–to–VLAN mapping database.

Virtual LANs

2008-10-01T01:59:00.000-07:00

Virtual LANs (VLANs)

A Virtual Local Area Network (VLAN) is a logical grouping of network users and resources connected to administratively defined ports on a switch. By creating VLANs, you are able to create smaller broadcast domains within a switch by assigning different ports in the switch to different subnetworks. A VLAN is treated like its own subnet or broadcast domain. This means that frames broadcasted onto a network are only switched between ports in the same VLAN. Using virtual LANs, you’re no longer confined to creating workgroups by physical locations. VLANs can be organized by location, function, department, or even the application or protocol used, regardless of where the resources or users are located. In this chapter, you will learn what a VLAN is and how VLAN memberships are used in a switched internetwork. Also, I’ll discuss how Virtual Trunk Protocol (VTP) is used to update switch databases with VLAN information. Trunking FastEthernet links will also be discussed. Trunking allows you to send information about all VLANs across one link.

Virtual LANs
In a layer-2 switched network, the network is flat, as shown in Figure 1. Every broadcast packet transmitted is seen by every device on the network, regardless of whether the device needs to receive the data.

Because layer-2 switching creates individual collision domain segments for each device plugged into the switch, the Ethernet distance constraints are lifted, which means larger networks can be built. The larger the number of users and devices, the more broadcasts and packets each device must handle. Another problem with a flat layer-2 network is security, as all users can see all devices. You cannot stop devices from broadcasting and users trying to respond to broadcasts. Your security is passwords on the servers and other devices.

By creating VLANs, you can solve many of the problems associated with layer-2 switching, as shown in the upcoming sections.

Security
One problem with the flat internetwork is that security was implemented by connecting hubs and switches together with routers. Security was maintained at the router, but anyone connecting to the physical network could access the network resources on that physical LAN. Also, a user could plug a network analyzer into the hub and see all the traffic in that network. Another problem was that users could join a workgroup by just plugging their workstations into the existing hub.

By using VLANs and creating multiple broadcast groups, administrators now have control over each port and user. Users can no longer just plug their workstations into any switch port and have access to network resources. The administrator controls each port and whatever resources it is allowed to use. Because groups can be created according to the network resources a user requires, switches can be configured to inform a network management station of any unauthorized access to network resources. If inter-VLAN communication needs to take place, restrictions on a router can also be implemented. Restrictions can also be placed on hardware addresses, protocols, and applications.

Flexibility and Scalability
Layer-2 switches only read frames for filtering; they do not look at the Network layer protocol. This can cause a switch to forward all broadcasts. However, by creating VLANs, you are essentially creating broadcast domains. Broadcasts sent out from a node in one VLAN will not be forwarded to ports configured in a different VLAN. By assigning switch ports or users to VLAN groups on a switch or group of connected switches (called a switch fabric), you have the flexibility to add only the users you want in the broadcast domain regardless of their physical location. This can stop broadcast storms caused by a faulty network interface card (NIC) or an application from propagating throughout the entire internetwork.

When a VLAN gets too big, you can create more VLANs to keep the broadcasts from consuming too much bandwidth. The fewer users in a VLAN, the fewer users affected by broadcasts. To understand how a VLAN looks to a switch, it’s helpful to begin by first looking at a traditional collapsed backbone. Figure 2 shows a collapsed backbone created by connecting physical LANs to a router.

Each network is attached to the router and has its own logical network number. Each node attached to a particular physical network must match that network number to be able to communicate on the internetwork. Now let’s look at what a switch accomplishes. Figure 3 shows how switches remove the physical boundary.

Switches create greater flexibility and scalability than routers can by themselves. You can group users into communities of interest, which are known as VLAN organizations. Because of switches, we don’t need routers anymore, right? Wrong. In Figure 3, notice that there are four VLANs or broadcast domains. The nodes within each VLAN can communicate with each other, but not with any other VLAN or node in another VLAN. When configured in a VLAN, the nodes think they are actually in a collapsed backbone as in Figure 2. What do the hosts in Figure 6.2 need to do to communicate to a node or host on a different network? They need to go through the router, or other layer- 3 device, just like when they are configured for VLAN communication, as shown in Figure 6.3. Communication between VLANs, just as in physical networks, must go through a layer-3 device.

Layers of the OSI Model

2008-09-29T12:05:00.000-07:00

The 7 Layers of the OSI Model

The OSI, or Open System Interconnection, model defines a networking framework for implementing protocols in seven layers. Control is passed from one layer to the next, starting at the application layer in one station, proceeding to the bottom layer, over the channel to the next station and back up the hierarchy.

Application (Layer 7)	This layer supports application and end-user processes. Communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified. Everything at this layer is application-specific. This layer provides application services for file transfers, e-mail, and other network software services. Telnet and FTP are applications that exist entirely in the application level. Tiered application architectures are part of this layer.
Presentation (Layer 6)	This layer provides independence from differences in data representation (e.g., encryption) by translating from application to network format, and vice versa. The presentation layer works to transform data into the form that the application layer can accept. This layer formats and encrypts data to be sent across a network, providing freedom from compatibility problems. It is sometimes called the syntax layer.
Session (Layer 5)	This layer establishes, manages and terminates connections between applications. The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues between the applications at each end. It deals with session and connection coordination.
Transport (Layer 4)	This layer provides transparent transfer of data between end systems, or hosts, and is responsible for end-to-end error recovery and flow control. It ensures complete data transfer.
Network (Layer 3)	This layer provides switching and routing technologies, creating logical paths, known as virtual circuits, for transmitting data from node to node. Routing and forwarding are functions of this layer, as well as addressing, internetworking, error handling, congestion control and packet sequencing.
Data Link (Layer 2)	At this layer, data packets are encoded and decoded into bits. It furnishes transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame synchronization. The data link layer is divided into two sublayers: The Media Access Control (MAC) layer and the Logical Link Control (LLC) layer. The MAC sublayer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking.
Physical (Layer 1)	This layer conveys the bit stream - electrical impulse, light or radio signal -- through the network at the electrical and mechanical level. It provides the hardware means of sending and receiving data on a carrier, including defining cables, cards and physical aspects. Fast Ethernet, RS232, and ATM are protocols with physical layer components.

Seven layers are defined:

7) Application : Provides different services to the applications

6) Presentation : Converts the information

5) Session : Handles problems which are not communication issues

4) Transport : Provides end to end communication control

3) Network : Routes the information in the network

2) Data Link : Provides error control between adjacent nodes

1) Physical : Connects the entity to the transmission media

OSI Model Networking Materials

2008-09-29T07:54:00.000-07:00

The 7 Layers of the OSI Model Networking Materials

3 attachments — Download all attachments

The 7 Layers of the OSI Model.doc
198K View as HTML Open as a Google document Download

osi.pdf
221K View as HTML Download

subnetting.pdf
90K View as HTML Download

FXS and FXO

2008-09-29T07:24:00.000-07:00

What do the terms FXS and FXO mean?

FXS and FXO are the name of ports used by Analog phone lines (also known as POTS - Plain Old Telephone Service).

FXS - Foreign eXchange Subscriber interface is the port that actually delivers the analog line to the subscriber. In other words it is the ‘plug on the wall’ that delivers a dial tone, battery current and ring voltage.

FXO - Foreign eXchange Office interface is the port that receives the analog line. It is the plug on the phone or fax machine, or the plug(s) on your analog phone system. It delivers an on-hook/off-hook indication (loop closure). Since the FXO port is attached to a device, such as a fax or phone, the device is often called the ‘FXO device’.

FXO and FXS are always paired, i.e similar to a male / female plug.

Without a PBX, a phone is connected directly to the FXS port provided by a telephone company.

If you have a PBX, then you connect the lines provided by the telephone company to the PBX and then the phones to the PBX. Therefore, the PBX must have both FXO ports (to connect to the FXS ports provided by the telephone company) and FXS ports (to connect the phone or fax devices to).

FXS & FXO & VOIP

You will come across the terms FXS and FXO when deciding to buy equipment that allows you to connect analog phones to a VOIP Phone System or traditional PBXs to a VOIP service provider or to each other via the Internet.

An FXO gateway

To connect analog phone lines to an IP phone system you need an FXO gateway. This allows you to connect the FXS port to the FXO port of the gateway, which then translates the analog phone line to a VOIP call.

An FXS gateway

An FXS gateway is used to connect one or more lines of a traditional PBX to a VOIP phone system or provider. You need an FXS gateway because you want to connect the FXO ports (which normally are connected to the telephone company) to the Internet or a VOIP system.

An FXS adapter a.k.a. ATA adapter

An FXS adapter is used to connect an analog phone or fax machine to a VOIP phone system or to a VOIP provider. You need this because you need to connect the FXO port of the phone/fax machine to the adapter.

Connecting

FXS/ FXO procedures – how it technically works

If you are interested to know in more technical detail how an FXS/ FXO port interoperate, here is the exact sequence:

When you wish to place a call:

You pick up the phone (the FXO device). The FXS port detects that you have gone off hook.

You dial the phone number, which is passed as Dual-Tone Multi-Frequency (DTMF) digits to the FXS port.

Inbound call:

The FXS port receives a call, and then sends a ring voltage to the attached FXO device.
The phone rings
As soon as you pick up the phone you can answer the call.

Ending the call – normally the FXS port relies on either of the connected FXO devices to end the call.

Note: The analog phone line passes approximately 50 volts DC power to the FXS port. That’s why you get a faint ‘shock’ when you touch a connected phone line. This allows a call to be made in the event of a power cut.

Wide Area File Sharing

2008-09-29T06:24:00.000-07:00

Hi,

Some information on WAFS. This concept is catching up
Wide-area file services (WAFS) is a storage technology that makes it possible to access a remote data center as though it were local. Among other benefits, WAFS enables businesses, academic institutions, and government agencies having numerous branch offices to centrally manage data backups in real time.

Other benefits of WAFS include immediate, round-the-clock read-write access to backed-up data for all end users in the network, low latency and rapid data transfer speed comparable to local area network (LAN) technologies, continuous real-time updating of backup content, enhanced data security, and simple, rapid system recovery in the event the network is compromised or damaged. Additional security of data may be possible by backing up the data on multiple servers at different physical locations.

Enabling File Sharing over the WAN
File distribution between remote locations is a hot topic in the enterprise world. But, to make it a reality, designers need to deliver systems that effectively handle file transfers across the WANs. Fortunately, WAFS boxes provide a strong alternative. Here's why.

Today's companies face the challenge of managing distributed development efforts across multiple remote locations. Not only are there substantial communication and process issues involved, but simply enabling all team members to collaborate on the same data set at the same time can be difficult, and data storage requirements for design files are growing every year.

While gigabytes of project data can easily be shared on a local-area network (LAN) using standard file server technology, these benefits do not extend to remote offices connected over wide-area networks (WANs). When it comes to file sharing over WANs, standard file server protocols provide unacceptably slow response times while opening and writing files. This forces IT to make an unappealing choice: either live with reduced productivity due to poor network performance at remote offices or use replication schemes that waste storage and inhibit global collaboration.

However, a new class of product known as wide-area file services (WAFS) holds the promise of solving the shared data problem for distributed engineering organizations without sacrificing performance. Let's take a look at WAFS systems and the technology capabilities they need to deliver.

File Sharing Dilemmas
All major file sharing protocols, including NFS (Network File System—for Unix/Linux environments), CIFS (Common Internet File System—for Windows environments), and IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange—for Novell environments) were designed for LAN environments where clients and servers were located in the same building or campus.

The assumption that the client and the server would be in close proximity led to a number of design decisions that do not scale across WANs. For example, these file sharing protocols tend to be rather "chatty", which means that they send many remote procedure calls (RPCs) across the network to perform operations.

For certain operations on a file system using the NFS protocol (such as an rsync of a source code tree), almost 80% of the RPCs sent across the network can be access() RPCs, while the actual read() and write() RPCs typically comprise only 8-10% of the RPCs. Thus 80% of the work done by the protocol is simply spent trying to determine if the NFS client has the proper permissions to access a particular file on the NFS server, rather than actually moving data.

In a LAN environment, these RPCs do not impact performance significantly, but when combined with the high latency typical of WANs, these RPCs can be deadly to performance. Worse, remote clients often end up timing out and retransmitting the RPCs, compounding the inefficiency. Furthermore, because data movement RPCs make up such a small percentage of the communication, increasing network bandwidth will make no difference to the aggravated end user.

Solution Attempts
Various solutions have been proposed to the WAN file sharing problem, including replicating file copies and implementing distributed file systems, but neither approach has provided a complete solution. Enterprise content delivery networks (eCDNs) tried to mitigate this problem by caching copies of files at each remote office. But eCDNs, like web caching infrastructure, only provide a read-only copy of data at the remote office. If remote office users wanted to modify the file, they either had to go across the WAN to access the original copy and incur a major performance penalty, or update the local copy and create multiple, out-of-sync versions of the same file.

File systems developed over the last 15 to 20 years such as AFS attempted to solve the WAN file sharing problem using a distributed file system architecture, which unites disparate file servers at remote offices into a single logical file system. However, these technologies required substantial changes in IT architecture to work properly.

In particular, file system-based technologies require remote-office applications to use entirely new protocols because they do not export data using industry standard protocols such as NFS or CIFS. With over 1 billion computers deployed in the world that access data using either CIFS or NFS, clearly such a solution is untenable. Further, these technologies depend on "owning" the data store at the data center, which is clearly untenable given the billions of dollars invested in current file server and NAS infrastructure.

The bottom line is that for any solution to the wide area file sharing problem to gain traction, it must be able to integrate itself with existing infrastructure rather than requiring new infrastructure to be built.

New Option
In spite of the failures of both caching technologies like eCDNs and distributed file systems to address the central issues in WAN file sharing, these technologies do provide important components for solving the WAN file sharing problem. New wide area file services (WAFS) products combine distributed file systems with caching technology to allow real-time, read-write access to shared file storage from any location, while also providing interoperability with standard file sharing protocols such as NFS and CIFS.

WAFS products enable transparent worldwide design collaboration on the same data set, without complicated replication schemes or slow network performance. WAFS products will cache files in a read-write mode at remote locations, thus speeding up data access for remote users tremendously. WAFS enables LAN semantics for file access to be extended to the entire enterprise.

WAFS systems (Figure 1) usually consist of edge file gateway (EFG) appliances, which are placed at remote offices, and one or more central server (CS) appliances that allow storage resources to be accessed by the EFGs.

Each EFG appears as a local fileserver to remote office users. Together, the EFGs and CS implement a distributed file system and communicate using a WAN-optimized protocol. This protocol is translated back and forth to NFS and CIFS at either end, to communicate with centralized storage and remote user applications.

Key Design Issues
When building a WAFS system, three key design questions that must be addressed include:

What are the features of the optimized protocol run between the EFGs and CSes across the WAN?
What specific optimizations have to occur in the system design for reading files?
What is the specific architecture for writing files and moving updates back to central storage resources?

The protocol used between the remote offices and the datacenter should incorporate file-aware differencing technology, data compression, streaming, and other technologies to improve performance and efficiency in moving data across the WAN. File-aware differencing is especially important because it can detect which parts of a file have changed, and only move those parts across the WAN. Furthermore, if pieces of a file have been rearranged, only offset information will be sent, rather than the data itself. These techniques result in tremendous, order-of-magnitude bandwidth reduction across the WAN and time savings in accessing files by remote users.

Read performance is governed by the ability of the EFG to cache files at the remote office, and the ability to serve cached data to users while minimizing the overhead of expensive kernel user communication and context switches, in effect enabling the cache to act just like a high-performance file server. If the WAFS system is architected correctly the remote cache should mirror the data center exactly and only a few WAN round trips are required to check credentials and availability of file updates, but read requests will be satisfied from the local cache. Thus, regardless of how many NFS/CIFS read RPCs come into the EFG, it should hardly translate into any WAN traffic.

Unlike read performance, write performance is governed by the write caching mechanism that is used in the WAFS system. The two main types of mechanisms are known as write-back and write-through.

In a write-through approach, data written to a file is sent immediately over the WAN to the datacenter, while in write-back the data is written to the EFG and then sent over the WAN. Either approach, in isolation, has certain associated tradeoffs. Write-through is very safe, because all file updates are stored in the datacenter, but it suffers from poor performance and does not survive WAN disruptions. Write-back is very fast, but is riskier if the EFG fails before updates are sent to the datacenter.

The optimal combination involves using a write-back approach for maximum performance, coupled with synchronous logging of file updates to persistent storage, ensuring no data loss in case of file system crashes or WAN outages. Write-back caching is typically very difficult to implement correctly with logging, but has superior performance and reliability characteristics.

Figure 2 depicts representative performance for both read and write operations over a WAFS system and over a standard wide area network. Opening a 5-Mbyte file over the WAN takes about 122 seconds, while a high-performing WAFS system will fetch the file in 11 seconds the first time it is accessed, and at essentially LAN speed on subsequent (warm) accesses because the file is cached locally. Writing a 2 MB file over the WAN takes 81 seconds. A write-back WAFS system achieves the same result in about 4 seconds.

In all the tests shown in Figure 2, the WAN latency was 60 ms (representative of actual conditions between San Francisco and Houston) and the bandwidth allotted was 1.544 Mbit/s (T1 Line). Clearly, WAFS products can enable near-LAN speed read-write access to data in a WAN environment.

Data Coherency and Consistency
Data coherency and data consistency are important properties of WAFS implementations, because they ensure that file updates are safe (cannot be written over) and available throughout the network of edge devices—crucial features for supporting engineering collaboration.

Data coherency means that file updates (writes) from any one remote office are guaranteed never to conflict with updates from another remote office. Properly designed WAFS implementations guarantee this by maintaining a system of file leases. Leases are defined as a particular access privilege to a file from a remote office.

If a user at a remote office wants to write to a cached file, the EFG at that office must obtain a "write lease", i.e. a right to modify the document before it can do so. WAFS solutions guarantee that at any time there will be only one remote office that has the write lease on a particular file thus guaranteeing coherence. Also, when a user at another office tries to open the file, the EFG that has the write lease flushes its data first and optionally can give up the write lease if there are no active writers to the file. This mechanism ensures that writers at different offices do not collide with each other and that file updates are safe.

Data consistency implies that file updates made at one office are always available enterprise-wide, and well-architected WAFS system do this immediately after the update is made. Again, for collaboration, this is supremely important because remote designers want to be sure they are working on the most current version of any file, no matter where it was worked on last.

Scalability
Any WAFS implementation should be capable of handling large files and large numbers of files (particularly important for CAD), as well as large numbers of concurrent users. A WAFS product that cannot scale beyond a few hundred MB of files or 10 users is not of much use.

The issue of write-through and write-back architectures mentioned earlier figures into how well a WAFS implementation scales. A write-through WAFS implementation that cannot scale to enterprise levels as synchronous data transfers across the WAN quickly becomes a bottleneck as the number of files and users increase. Systems that are based on write-back architectures, that incorporate differencing and compression technologies, scale much better.

Additionally, scalable systems recognize temporary files that applications (e.g. Microsoft Word) may create during the normal course of operation and do not send these files over the WAN, instead only sending over the final revision, which accelerates performance.

Revision Control Systems
One big question that gets asked about WAFS systems is whether these systems are somehow competitive to revision control systems. In fact, revision control systems are one of the key areas to benefit from WAFS, and the two solutions are complimentary.

Any revision control system that stores its data in flat files, even if it stores metadata in a separate database, will see a tremendous improvement in performance using WAFS. To properly support revision control systems it is highly imperative for a WAFS implementation to provide both data coherency and data consistency.

WAFS products are capable of exporting entire revision control repositories to remote sites, allowing the revision control system manager to run locally at the remote site—dramatically speeding up check-in, check-out, and build processes. As locks are released, the changed files are propagated to the server, immediately ensuring that changes are reflected back to the datacenter in a consistent and coherent manner.

Wrap Up
For companies sporting distributed teams, sharing data between a number of remote offices in real-time has been a challenge due to the poor performance and reliability of file sharing protocols such as NFS and CIFS when used over wide are networks. Workarounds to the problem have had undesirable consequences. Emerging WAFS technologies, on the other hand, offer a solution to the problem that enables enterprises around the world to share data with the same performance, reliability, interface, and semantics that they would have if they were sharing data on a local area network

Advanced Router Features

2008-09-29T01:39:00.000-07:00

B/W Aggregation & Load Balancing

Load balancing of outbound traffic using multi-path support with gateway weight allocation.
Dynamic management of gateways via health checks and traffic controlled weight assignments.
Weighted Round Robin (WRR) session-based load balancing for outbound connections with advanced gateway status detection.
Full gateway/route fail over capability.
Inbound load balancing and fail over based on proprietary Advanced DNS functionality.
Service/Port/Protocol based routing to allow alternative routing for different services.
Full featured QoS capabilities (as an add-on module)

NAT (SNAT) Support
Using NAT configuration, SysMaster can provide secure Internet connectivity to all computers in the Local Area Network requiring just one public IP address, sparing investments on a block of IP addresses and increasing overall network security.

Load balancing of Gateways
Problems associated with Enterprise WAN connectivity

The utilization of multiple ISP up link gateways requires advanced route load balancing and fail over to ensure uninterrupted connectivity of corporate offices and service centers. Current routing protocols are limited in terms of bandwidth aggregation and do not support dynamic weight allocation to gateways. In most cases unavailable routes are not recognized by the access router and thus proper gateway fail over procedure is out of the question.

The SysMaster solution

SysMaster allows complete bandwidth aggregation, gateway load balancing (multi-path WRR), and gateway fail over. If any active gateway changes its state to disabled, it is isolated and removed from rotation. In all cases, only available gateways are used to route traffic. Furthermore, SysMaster allows dynamic gateway weight assignment to dynamically manage gateway utilization and traffic flow without the need to reconfigure routes. SysMaster is the only router that allows dynamic management of up link gateways in corporate and ISP environment.

Bandwidth Aggregation - supports unlimited number of up link gateways to multiply the overall system throughput;
Gateway fail over - allows isolation of 'dead gateways' and traffic routing through alternative gateways;
Global DNS Load Balancing - features stand-alone DNS server that provides scalability and load balancing of inbound (ingress) routes for all web, mail, and other Internet servers;
Ingress/Egress Load Balancing - provides two-way load balancing services for multiple uplinks such as xDSL, T1, T3, OC-3/12/48 and Ethernet.

Unique Functionality

SysMaster is the only router that allows dynamic route and gateway management to provide complete gateway fail over and static/dynamic load balancing. The device can control the weight assignments for each individual gateway dynamically without manual intervention. The weight for each gateway to be used for the route is initially assigned by the network admin, and then (if selected) dynamically controlled using a third party agent, utilization monitoring, advanced rules.

Third-party agent. The information is read by SysMaster from a third-party agent to dynamically allocate new weight to each individual gateway.
Internal network device utilization monitoring. The device traffic is evaluated against the physical device parameters to provide dynamic aggregated bandwidth management.
Set of Advanced Rules. SysMaster completely supports advanced object management rules based on traffic volume, time-of-day, device-status checks.

Traffic load balancing and fail over

Large enterprises can have multiple xDSL, T1, T3, OC-3/12/48, and Ethernet gateways to access the Internet or implement corporate VPN networks and extranets. In this environment, SysMaster can be used to dynamically aggregate bandwidth and distribute the load of a network (to which it serves as a gateway) among the higher level corporate gateways thus delivering high level of efficiency. In order to effectively match the available resources allocated for each managed gateway, SysMaster assigns a performance weight to each managed gateway which reciprocally reflects the volume of traffic being forwarded through the respective gateway. The SysMaster also actively monitors all available gateways to allow for 'dead gateway discovery', and redirect traffic through alternative gateways.

Outbound Traffic load balancing and fail over

SysMaster allows dynamic control of all outbound gateways to isolate disabled routes from traffic routing. Utilizing proprietary mechanism of WAN device controls and L3/L7 gateway health checks, the device quickly responds to changed traffic conditions and dynamically changes weight assignments to its managed up link gateways. SysMaster fully supports static and dynamic Weighted Round Robing (WRR) load balancing for outbound traffic on a per session basis.

Inbound Traffic load balancing and fail over

SysMaster utilizes a proprietary Advanced DNS algorithm to loadbalance and fail over inbound traffic via DNS responses. The device provides intelligent DNS responses that are based on server utilization and performance, physical client proximity (via BGP client), and geographical client location (via proprietary geographical IP segment database). Utilizing Advanced DNS services, the appliance allows dynamic global load balancing for servers and routes.

Transparent Network Integration

SysMaster supports Route Bridge functionality to allow transparent integration into existing networks. SysMaster installation does not require changes in routing tables and gateways of existing network devices. In many cases, SysMaster will replace an existing Ethernet cable and act as a transparent router to allow simplified environment integration.

SysMaster as an Access Router

Delivering extensive set of supported routing protocols such as RIP, BGP and others, together with the high-performance packet forwarding, allows system administrators to build solid network solutions upon the SysMaster Routing/Gateway Module. The QoS module can be used to add functionality that can be positioned as a highly flexible edge router supporting DiffServ IP QoS.

Cisco HSRP FAQ

2008-09-27T03:43:00.001-07:00

Q. Will the standby router take over if the active router LAN interface state is "interface up line protocol down"?

A. Yes, the standby router takes over once the holdtime expires. By default, this is equivalent to three hello packets from the active router having been missed. The actual convergence time depends on the HSRP timers configured for the group and possibly on routing protocol convergence. The HSRP hellotime timer defaults to three and the holdtime timer defaults to ten.

Q. Can I configure more than one standby group with the same group number?

A. Yes. However, Cisco does not recommend it on lower-end platforms such as the 4x00 series and earlier. If the same group number is assigned to multiple standby groups, it creates a non-unique MAC address. This is seen as the MAC address of the router, and it is filtered out if more than one router in a LAN becomes active. This behavior can change in future releases of Cisco IOS®.

Note: 4x00 series and earlier do not have the hardware required to support more than one MAC address at a time on Ethernet interfaces. However, the Cisco 2600 and Cisco 3600 do support multiple MAC addresses on all Ethernet and Fast Ethernet interfaces.

Q. When an active router tracks serial 0 and the serial line goes down, how does the standby router know to become active?

A. When the state of a tracked interface changes to down, the active router decrements its priority. The standby router reads this value from the hello packet priority field, and becomes active if this value is lower than its own priority and the standby preempt is configured. You can configure by how much the router must decrement the priority. By default, it decrements its priority by ten.

Q. If there is no priority configured for a standby group, what determines which router is active?

A. The priority field is used to elect the active router and the standby router for the specific group. In the case of an equal priority, the router with the highest IP address for the respective group is elected as active. Furthermore, if there are more than two routers in the group, the second highest IP address determines the standby router and the other router/routers are in the listen state.

Note: If no priority is configured, it uses the default of 100.

Q. What are the limiting factors that determine how many standby groups can be assigned to a router?

A. Ethernet: 256 per router. FDDI: 256 per router. Token Ring: 3 per router (uses reserved functional address).

Note: 4x00 series and earlier do not have the hardware required to support more than one MAC address at a time on Ethernet interfaces. However, the Cisco 2600 and Cisco 3600 do support multiple MAC addresses on all Ethernet and Fast Ethernet interfaces.

Q. Which HSRP router requires that I configure preempt?

A. An HSRP-enabled router with preempt configured attempts to assume control as the active router when its Hot Standby priority is higher than the current active router. The standby preempt command is needed in situations when you want an occurring state change of a tracked interface to cause a standby router to take over from the active router. For example, an active router tracks another interface and decrements its priority when that interface goes down. The standby router priority is now higher and it sees the state change in the hello packet priority field. If preempt is not configured, it cannot take over and failover does not occur.

Q. Based on the documentation, it looks like I can use HSRP to achieve load-balancing across two serial links. Is this true?

A. Yes, refer to Load Sharing with HSRP for more information.

Q. Does HSRP support DDR, and if so, how will it know to dial?

A. No, HSRP does not support Dial-on-Demand Routing (DDR) directly. However, you can configure it to track a serial interface and swap from the active to the standby router in case of a WAN link failure. The command used to track the state of an interface is standby track .

Q. I use HSRP and all hosts use the active router to forward traffic to the rest of my network. I have noticed that the return traffic comes back through the standby router. Will this cause problems with HSRP or my applications?

A. No, normally this is transparent to all hosts and/or servers on the LAN and can be desirable if a router experiences high traffic. In order to change this, configure a more desirable cost for the link you want the distant router/routers to use.

Q. How does DECnet traffic fit into the HSRP scenario?

A. DECnet and XNS are compatible with HSRP and multiple HSRP (MHSRP) over Ethernet, FDDI, and Token Ring on the Cisco 7000 and Cisco 7500 routers only. Refer to Using HSRP for Fault-Tolerant IP Routing for more information.

Q. Can a Cisco 2500 and Cisco 7500 router on the same LAN segment use HSRP, or do I have to replace one of the routers so the platforms are identical?

A. You can mix the platforms with HSRP, but you are not able to support multiple HSRP (MHSRP) due to the hardware limitations of the lower-end platform.

Q. If I use a switch, what do I see on the CAM tables for the HSRP?

A. The content-addressable memory (CAM) tables provide a map for the HSRP MAC address to the port on which the active router is located. In this way, you can determine what the switch perceives the HSRP status to be.

Q. What is the standby use-bia command and how does it work?

A. By default, HSRP uses the preassigned HSRP virtual MAC address on Ethernet and FDDI, or the functional address on Token Ring. In order to configure HSRP to use the burnt-in address of the interface as its virtual MAC address, instead of the default, use the standby use-bia command.

For example, on Token Ring, if Source Route Bridging is in use, a Routing Information Field (RIF) is stored with the virtual MAC address in the RIF cache of the host. The RIF indicates the path and final ring used to reach the MAC address. As routers transition to the active state, they send gratuitous Address Resolution Protocols (ARPs) in order to update the ARP table of the host. However, this does not affect the RIF cache of the hosts that are on the bridged ring. This situation can lead to packets being bridged to the ring for the previous active router. In order to avoid this situation, use the standby use-bia command. The router now uses its burnt-in MAC address as the virtual MAC address.

Note: Using the standby use-bia command has these disadvantages:

* When a router becomes active the virtual IP address is moved to a different MAC address. The newly active router sends a gratuitous ARP response, but not all host implementations handle the gratuitous ARP correctly.

* Proxy ARP breaks when use-bia is configured. A standby router cannot cover for the lost proxy ARP database of the failed router.

Q. Can I run NAT and HSRP together?

A. You can configure network address translation (NAT) and HSRP on the same router. However, a router that runs NAT holds state information for traffic that is translated through it. If this is the active HSRP router and the HSRP standby takes over, the state information is lost.

Note: Stateful NAT (SNAT) can make use of HSRP to fail over. Refer to NAT Stateful Failover of Network Address Translation for more information. Static NAT Mapping Support with HSRP for High Availability is another feature which makes NAT and HSRP interact. If static NAT is configured with the same IP on each router, the routers advertise each other with the MAC addresses, and the routers display the %IP-4-DUPADDR: Duplicate address [ip address] on [interface], sourced by [mac-address] error message. Refer to NAT—Static Mapping Support with HSRP for High Availability for more information.

Q. What are the IP source address and destination address of HSRP hello packets?

A. The destination address of HSRP hello packets is the all routers multicast address (224.0.0.2). The source address is the primary IP address of the router assigned to the interface.

Q. Are HSRP messages TCP or UDP?

A. UDP, since HSRP runs on UDP port 1985.

Q. HSRP does not work when an Access Control List (ACL) is applied. How can I permit HSRP through an ACL?

A. HSRP hello packets are sent to multicast address 224.0.0.2 with UDP port 1985. Whenever an ACL is applied to an HSRP interface, ensure that packets destined to 224.0.0.2 on UDP port 1985 are permitted.

Q. How does TACACS/RADIUS accounting work with HA routers with HSRP?

A. If routers are configured in HA mode (that run HSRP in-between them), then the active and standby routers act as one logical unit and share the same IP and MAC address. Only the active router generates the accounting record with a particular virtual IP address and updates the TACACS/RADIUS server. If the standby generates the accounting record with the same address, there is duplicate data in the backend RADIUS/TACACS server. Therefore, in order to avoid duplication of data, the standby router does not generate accounting records.

Q. Are HSRP and VLAN translation supported together in a Cisco Catalyst 6500 series switch?

A. VLAN translation and HSRP can be configured together in a Cisco Catalyst 6500 series switch, subject to the restrictions put in place by VLAN translation. Refer to VLAN Translation Guidelines and Restrictions for more information.

Q. Is it possible to use HSRP to track the tunnel interface?

A. It is not possible to use the HSRP configuration to track the GRE tunnel interface. However, the tunnel interface never goes down and the track never triggers failover.

Q. How do I perform a forced failover of an HSRP active router without a shutdown on an interface?

A. The only way to make a failover without an interface shut down is to manually change the priority in the HSRP configuration.

Q. Is it possible to run HSRP on an interface configured for 802.1q trunking?

A. Yes it is possible to run HSRP on the interfaces configured for 802.1q. Make sure to verify that both sides of the trunk are configured to use the same native VLAN and verify that VLANs are not pruned and in the STP state for router-connected ports.

Q. Is it possible to run HSRP between two routers on two different interfaces?

A. Yes, it is possible to run HSRP on two interfaces on two different routers. In order to have HSRP on two interfaces on two different routers, two HSRP groups are needed .

Q. Is it possible to run HSRP and OSPF together on the backbone router?

A. HSRP and OSPF are two different protocols. The OSPF that runs on the router advertises the two physical interfaces and not the virtual IP address. When this router becomes active, it broadcasts a gratuitous ARP packet with the HSRP virtual MAC address to the affected LAN segment. If the segment uses an Ethernet switch, this allows the switch to change the location of the virtual MAC address so that packets go to the new router instead of the one that is no longer active. End devices do not actually need this gratuitous ARP if the routers use the default HSRP MAC address.

Q. Which IP address must be seen when a reply is received for traceroute?

A. When a reply for traceroute is received from a hop that runs HSRP, the reply must contain the active physical IP adddress and not the virtual ip address. If there is an asymmetric routing in the network due to which standby router IP address is seen in the reply for the traceroute.

Q. What is the difference between GLBP and HSRP?

A. GLBP provides load balancing over multiple routers (gateways) using a single virtual IP address and multiple virtual MAC addresses. Members of the GLBP group select one of them to become the active virtual gateway for the group.

With HSRP in a single router (gateway), one interface is used as the active interface and the other interface is in standby. The active interface is used for all the traffic and the standby interface just waits for the active interface to fail without any traffic.

Cisco Hot Standby Router Protocol

2008-09-27T03:39:00.000-07:00

Step-by-Step With Cisco's Hot Standby Router Protocol

The Hot Swappable Router Protocol (HSRP) is a way to build redundancy into your network by allowing two or more routers to continuously test each other for connectivity, and take over if a router fails. For purposes of discussing a basic HSRP configuration, let's assume we want to make the 10.10.10./24 network dynamically redundant and have two building routers at our disposal.

Using HSRP terminology, both building routers together are referred to as a standby group and appear to the subnet as a single default gateway. Through an election process, one router is designated as active and the other router is designated as standby. Both the active and standby router listen to routing updates from the core router, but only the active router processes IP packets as the default gateway for the subnet. The active and standby routers are constantly sending "hello" packets back and forth. If the active router fails, as soon as a predetermined number of "hello" packets from the standby router to the active router go unanswered, the standby router becomes the active router and starts processing IP packets for the subnet.

Both routers are configured with standard IP addresses on their interface into the subnet. Each router also has a special virtual IP address which is the same on both routers, configured via standby commands under the specific interfaces.

Configuring The Routers
Given a standard 24-bit subnet, we can build the following:

Network: 10.10.10.0

Subnet Mask: 255.255.255.0

Default Gateway: 10.10.10.251

Physical IP Address

Building Router A: 10.10.10.252

Building Router B: 10.10.10.253

The configuration commands are as follows:

building router a#
interface fa0/2
ip address 10.10.10.252 255.255.255.0

This sets the IP address for the interface

standby 100 timers 3 10

100 denotes the HSRP process number as "hot standby group 100". You can have multiple HSRP standby groups on the same interface. The timers command sets the interval to 3 seconds between HELLO messages, and waits 10 seconds before the other router is declared down.

standby 100 priority 200 preempt

Defines the priority of this router. The highest priority number will win the election. "Preempt" allows the router to take over control even if there is not an election in process if it comes on line with the highest priority.

standby 100 authentication fnord

Optional - Authentication [word] creates an unencrypted authentication process for each HSRP packet.

standby 100 ip 10.10.10.251

Establishes 10.10.10.251 as the virtual interface. This IP address should be the same on both HSRP routers.

standby 100 track fa0/0

The track command monitors a specific link on this router, and decrements its own priority if this interface goes down by 10, allowing another HSRP router to take over if the other router has "preempt" enabled.

building router b#
interface fa0/3
ip address 10.10.10.253:255.255.255.0
standby 100 timers 3 10
standby 100 priority 195 preempt

A priority number of 195 means this router will come up as secondary. If the active router loses its uplink (via the primary router's track command) then the primary router decrements to 190, causing this router to take over as active because of the preempt command.

standby 100 authentication fnord
standby 100 ip 10.10.10.251
standby 100 track fa0/1

Monitoring Techniques and Commands
With this configuration, you can program each client on that subnet to use 10.10.10.251 as the default gateway, and if one router fails the other router will answer and packets needing to be passed on. You can identify which router is currently active remotely by telnetting to the default gateway (10.10.10.251) - you will end up being logged into the active router. You can also telnet to the secondary router by using the interface IP address directly. From the router, there are a series of commands which can give you information about the status of your HSRP pair.

Building_router_A# show standby
Int fa0/2 - Group 100
Local state is Active, priority 200, may preempt
Hellotime 3 holdtime 10 configured hellotime 3 sec holdtime 10 sec
Next hello sent in 00:00:01.782
Hot standby IP address is 10.10.10.251 configured
Active router is local
Standby router is 10.10.10.253 expires in 00:00:07
Standby virtual mac address is 0000.0c07.acce
1 state changes, last state change 5w1d
Tracking interface states for 1 interfaces, 1 up:
Up   fa0/0 Priority decrement: 10

We see from the "show standby" command that this router is the active router, that the secondary router is 10.10.10.253 - and that we are tracking fa0/0 successfully.

If you would like a more streamlined description:

Building_router_A#sho standby brief

                     P indicates configured to preempt.
                    |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr

Fa0/2       100 200  P Active   local           10.10.10.253  10.10.10.251

For the adventuresome network administrator, you can fire up a LAN Analyzer and decode the HSRP HELLO packets as they transverse your network.

Troubleshooting Tips
The number one problem with HSRP configuration is router communication. The two routers must be able to communicate to each other on the same subnet via their HSRP enabled interfaces. If your routers cannot ping each other successfully before you apply HSRP, then there will be no syncing between them. Make sure your VLANS are configured correctly on the switch level - and if you are using Cisco Catalyst 6500s with MSFCs for your routers, make sure you have the VLAN configurations set correctly on the switch-component as well.

Make sure you use tracking commands for your uplinks to the next level of routers. If you do not and loose an uplink on the primary router, HSRP will not convert to the standby router.

If you can ping the interface IP addresses but still are not getting HSRP communication, confirm whether or not you are using the "authentication" command and if so, that your authentication words match.

You can run HSRP on any Cisco IOS Release 10.0 or later, but release 11.0(3)(1) provides improved support.

Wrapup

HSRP is a great way to take two or more routers and add a dynamic fault tolerant element to your network, removing a single point of failure for your subnets. You can also accomplish load balancing by having a router active for one subnet, and secondary for another subnet - the routers will handle default gateway requests for only the subnets they are active for, and will still handle fault tolerance for all subnets if one router fails.

Virus Ports

2008-09-27T03:15:00.000-07:00

List of Virus Ports

IP access-list extended UDP-DENY-NEW

Deny TCP any any eq 1068
Deny TCP any any eq 5554
Deny TCP any any eq 9996
Deny TCP any any eq 445
Deny TCP any any eq 1024
Deny udp any any eq 1024
Deny TCP any any eq 1025
Deny udp any any eq 1025
Deny udp any any eq 135
Deny TCP any any eq 135
Deny udp any any eq netbios-ns
Deny TCP any any eq 137
Deny udp any any eq 445
Deny TCP any any eq 4444
Deny udp any any eq 1434
Deny TCP any any eq 139
Deny udp any any eq netbios-ss
Deny udp any any eq 995
Deny udp any any eq 996
Deny udp any any eq 997
Deny udp any any eq 998
Deny udp any any eq 999
Deny udp any any eq 8998