DocWiki - User contributions [en]

Before You Buy or Deploy - Considerations for Design and Procurement

2012-10-17T16:17:27Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="uc virtualization, unified communications, uc design"></meta>

'''Go to: [[Guidelines to Edit UC Virtualization Pages|Guidelines to Edit UC Virtualization Pages]]''' 

----

Use this page prior to quoting, procuring, designing or deploying Virtualization of Cisco Unified Communications. 

= Useful Links =

*UC Virtualization Design and Sizing

:*[http://www.cisco.com/go/ucsrnd Cisco Unified Communications Design Guide]
:*[http://tools.cisco.com/cucst/faces/login.jsp Cisco UC System Sizing Tool (UCSST)]
:*[[Unified Communications Virtualization Downloads (including OVA/OVF Templates)|Virtual Machine OVA Templates for UC apps]]
:*[[Unified Communications Virtualization Sizing Guidelines | Application Co-residency and Virtual/Physical Sizing]]
:*[[QoS Design Considerations for Virtual UC with UCS | LAN and QoS Design ]]
:*[[UC Virtualization Storage System Design Requirements | Storage System Design and IOPS ]]
 

*UC Virtualization Compatibility Information

:*[[Unified Communications Virtualization Supported Applications|Supported Apps and Versions]]
:*[[UC Virtualization Supported Hardware|Supported Hardware (TRC vs. Specs-based)]]
:*[[Unified Communications VMware Requirements|Supported VMware products, versions and features]]
:*[[UC Applications-Specific Virtualization Information | UC app-specific support rules (in addition to or instead of above links)]]

 

= Presales Design Considerations =

 For a design example case study, see [[Unified Communications Virtualization Sizing Guidelines|'''Unified Communications Virtualization Sizing Guidelines.''']]

{{note| Mixed deployments of virtual, nonvirtual, Cisco-provided, and customer-provided servers are supported provided you follow all rules listed below for sizing UC applications and sizing UC hardware. Use general requirements in UC application design; for example, do not make a backup node smaller than a primary node, and do not make a Publisher smaller than a Subscriber.}}

 

== Sizing UC Applications for Virtualization ==

*Verify the '''supported UC Application products and versions''' listed in [[Unified Communications Virtualization Supported Applications|'''Unified Communications Virtualization Supported Applications''']].
*'''Sizing virtualized UC applications''' is the same as appliance sizing. Use the [http://www.cisco.com/go/ucsrnd '''Cisco Unified Communications System Design Guidance'''] and [http://tools.cisco.com/cucst/faces/login.jsp '''Unified Communications Sizing Tool''']. Instead of determining appliance size and count, determine Virtual Machine size and count. 
*Select an appropriate OVA/OVF template for each "Server" required for a UC application. Each UC application has one or more OVA/OVF template options. See [[Unified Communications Virtualization Downloads (including OVA/OVF Templates)|'''Unified Communications Virtualization Downloads (including OVA/OVF Templates)''']].
*Follow the [[Unified Communications Virtualization Sizing Guidelines|'''coresidency policy in Sizing Guidelines'''to]] determine which OVAs can share physical servers. Which OVAs "should" share a physical server depends on customer placement logic, which includes but is not limited to considerations for geographic distribution, minimizing server footprint, server/site redundancy, security domains, change management, service level agreements and assessed business criticality of the individual UC apps.
*Verify alignment of virtualization support details (such as supported hardware or VMware features). These details may vary based on each UC application. Because UC applications  share physical resources, be sure to verify alignment of these details for all UC applications in your deployment--particularly for UC applications that share a physical server. 

 

== Selecting the VMware Product and Version ==

 

*Verify the '''VMware product/version compatibility and VMware feature support for each UC app''' in your deployment. See [[Unified Communications VMware Requirements|'''Unified Communications VMware Requirements''']]. 

 

== Sizing the Compute, Storage, and Network Hardware ==

'''Physical server count''' is dependent on VM quantity and size, customer placement logic, and the coresidency support policy (see [[Unified Communications Virtualization Sizing Guidelines|'''Unified Communications Virtualization Sizing Guidelines''']]).

=== General Rules ===

Decide which one of the following options you will use:

:*[[Tested Reference Configurations (TRC)|'''Tested Reference Configurations (TRC)''']]
:*[[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']]

Follow the rules for your selected approach; your allowed hardware options, design rules, procurement and TAC support are different for each.

 

=== Sizing Network Hardware and QoS Considerations ===

Virtualized deployments of Unified Communications have specific LAN and QoS considerations. See [[QoS Design Considerations for Virtual UC with UCS|'''QoS Design Considerations for Virtual UC with UCS''']].

=== Sizing Shared Storage (SAN/NAS) ===

See [[Shared Storage Considerations|'''Shared Storage Considerations''']] for support of NFS NAS or FC/FCoE/iSCSI SAN, including best-practices guidelines for UC.

See also [[IO Operations Per Second (IOPS) |'''IO Operations Per Second (IOPS)'''.]]

 

= Procurement Considerations =

The following sections describe purchasing options for the various components of Virtualization of Cisco Unified Communications.

 

== Purchasing Cisco Unified Communications Applications ==

There is no change to how UC applications are purchased. Cisco User Connect Licensing, Cisco Unified Workspace Licensing and Cisco UC Software Subscription are all the same for both virtualized and nonvirtualized deployments.

License '''enforcement''' can differ from appliances when virtualized. See [[Licensing Model for Virtualized UC Applications|'''Licensing Model for Virtualized UC Applications''']] for details.

 

== Purchasing the Required VMware Software ==

For UC on UCS (whether specs-based or Tested Reference Configuration), VMware vSphere ESXi and vCenter may be either customer-provided or purchased from Cisco.

For specs-based with HP/IBM servers, all VMware software must be customer-provided and may not be purchased from Cisco.

Cisco provides two purchase options for VMware vSphere ESXi:
:*As an option under a build-to-order data center part number for the UCS server: Note that for the Cisco UCS B-Series, you must order this option through the Netformx DesignXpert ordering tool UCS Advisor.
::* For vSphere 4.1, licenses are sold on a per-populated-physical-CPU-socket basis (not physical CPU cores or virtual CPUs or virtual CPU cores). Each populated CPU socket per physical server requires a VMware license and a required service contract. Only Advanced, Enterprise and Enterprise Plus Editions are available, and only with one-year or three-year service subscription options. VMware licensing rules must be followed to determine quantities and feature editions - see details on VMware's web site here: https://www.vmware.com/files/pdf/vsphere_pricing.pdf .
::* Cisco does not resell vSphere 5.0 at this time.
:* Preset “per-server” Cisco Collaboration part number. This part number is separate from server hardware part numbers. You can use the same part number for Cisco UCS B-Series and C-Series deployments. Note that for the Cisco UCS B-Series, you must add this part number to a group of data center part numbers ordered through the Netformx DesignXpert ordering tool UCS Advisor. There are three options:
::* vSphere ESXi 4.1 Standard Edition, limited to two CPU sockets (no more, no less) and only with one-year service subscription (no multiyear or auto-renewals).
::* Cisco UC Virtualization Hypervisor 4.1, only available with Business Edition 6000 and with limited hardware/software deployment options - [http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Supported_Editions_and_Features_of_VMware_vSphere_ESXi.2C_VMware_vCenter_and_VMware_vSphere_Client click here for details].
::* Cisco UC Virtualization Foundation 4.1, for use only with Business Edition 6000 and UC on UCS, and with limited hardware/software deployment options - [http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Supported_Editions_and_Features_of_VMware_vSphere_ESXi.2C_VMware_vCenter_and_VMware_vSphere_Client click here for details].
:*Cisco field and channel partners may consult the [http://www.cisco.com/web/partners/sell/technology/ipc/uc_tech_readiness.html#~7 '''"UC on UCS" chapter of the User Connect Licensing Ordering Guide at Cisco Partner Central'''].
:*For part number and SKU examples, see the UC on UCS page at [http://www.cisco.com/go/swonly '''www.cisco.com/go/swonly'''], specifically Table 1 on [http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/solution_overview_c22-597556.html '''http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/solution_overview_c22-597556.html'''].

For guidance on supported VMware products, versions and features, and which vSphere Edition to buy for UC, see [[Unified Communications VMware Requirements|'''VMware requirements''']]. If you are not buying one of the preset Cisco Collaboration part numbers for vSphere, then follow VMware licensing rules at https://www.vmware.com/files/pdf/vsphere_pricing.pdf to determine required Edition and license quantities.

'''Please keep the following in mind when purchasing VMware from Cisco''':

*A vSphere license purchased from Cisco entitles both ESX and ESXi, but remember that UC only supports ESXi.
*A vSphere 4 license purchased from Cisco entitles either 4.0 or 4.1. License activation at vmware.com will be for latest version unless you explicitly request a downgrade. For version compatibility among VMware products, see the [http://www.vmware.com/resources/compatibility/sim/interop_matrix.php '''VMware Product Interoperability Matrix'''].
*VMware vCenter is mandatory for deployments on Specs-based Hardware Support. VMware vCenter is optional for deployments on Tested Reference Configurations.
*VMware.com provides Cisco-specific VMware builds for certain UCS servers. These UCS-specific builds are usually not required for UC on UCS, and the regular "off-the-shelf" builds of VMware are fine. Consult your server documentation to see which one you should use.
*VMware Partner Activation Codes (PACs) are currently per-CPU. A dual-CPU physical server requires two of these per-CPU licenses to be "combined" prior to generating a license key file for upload to the physical server hosting VMware. For example, see [http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010686 '''http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010686'''].
*Cisco channel partners should register VMware Partner Activation Codes (PACs) with the end-user customer (not the channel partner) as Primary License Administrator to ensure that support contracts work correctly.
*For additional details, see [[License Activation for Cisco UC on UCS|'''License Activation for Cisco UC on UCS''']].

 

== Purchasing Virtualization Hardware ==

This section provides details on server, storage, and network hardware requirements to implement virtualization. 

 

=== Cisco Unified Computing System (UCS) Servers ===

Cisco UCS servers may be purchased through the following options:

*Certain [[Unified Computing System Hardware|'''Tested Reference Configurations''']] of Cisco UCS servers may be purchased as a single Cisco Collaboration part number. This purchase option supports only a single fixed-server configuration with no parts substitutions supported. For the Cisco UCS B200 it does not include any other components such as blade-server chassis, fabric extenders, or fabric interconnect switches (a certified Cisco channel partner must order these components using the Netformx DesignXpert ordering tool UCS Advisor). This "single SKU" option provides simplicity of ordering for deployments that are predominantly Cisco Unified Communications software. Note that some supported tested reference configurations, such as Cisco UCS C210 M2 Tested Reference Configuration 2, are not offered through this procurement option because they are used only for design guidance with [[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']]. For mapping of Tested Reference Configurations to lists of equivalent Cisco Data Center part numbers, see [http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/solution_overview_c22-597556.html '''http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/solution_overview_c22-597556.html'''].

*Any Cisco UCS that is deployed as a [[Unified Computing System Hardware|'''Tested Reference Configuration''']] or that uses [[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']] may be purchased as a build-to-order set of "a la carte" Cisco Data Center part numbers. This option supports all Cisco Unified Computing System components, and for UC apps that support [[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']] provides a broader range of server and part options. A certified Cisco channel partner must order from Dynamic Configuration Tool (for UCS C-Series) or the Netformx DesignXpert ordering tool UCS Advisor (for UCS B-Series). This option is appropriate for mixed software deployments in which the customer wants something different from the tested reference configurations that are offered as single Cisco Collaboration SKUs.

Cisco field and channel partners may also consult the "UC on UCS" chapter of the User Connect Licensing Ordering Guide.

 

=== Third-Party Servers ===

For a deployment of [[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']] using supported third-party servers, the servers must be customer-provided and are not purchased from Cisco.

 

=== Shared Storage and Network Access Hardware ===

Shared storage arrays (for supported SAN or NAS deployments) are customer-provided and are not purchased from Cisco. Network hardware for LAN and storage access may be Cisco-provided or third-party-provided depending on deployment.

 

= Key Differences Between Appliances and Virtualization of Cisco Unified Communications =

Deployments on Cisco 7800 Series Media Convergence Servers that are shifting to virtualization should prepare for the following:

*Virtualization of Cisco Unified Communications is "not an appliance." You must independently configure, manage, and monitor the hardware, VMware software, and virtualized UC applications.
*Higher level of expertise with server administration, VMware vSphere/vCenter administration, and storage administration is expected from whoever is managing the UC deployment. This expectation is more for deployments of [[Specification-Based Hardware Support|'''Specification-Based Hardware Support''']] and UC on UCS B-Series than for UC on UCS C-Series [[Unified Computing System Hardware|'''Tested Reference Configurations''']].
*If you are using Shared Storage (SAN or NAS), be aware that it is a critical solution component and if improperly configured, monitored, or managed will cause significant performance and availability issues for UC apps. Ensure that whoever is managing the UC deployment is experienced and proficient with storage management.
*Adhere to all licensing requirements for virtualized UC apps. For example, license keys may be different when virtualized than they are on appliances.
*UC application features that are dependent on physical USB ports are not supported. See the required [[UC Applications-Specific Virtualization Information|'''UC Application documentation''']] for alternatives and workarounds.

 

= Considerations for Cisco TAC Support =

This section is for convenience and illustration purposes only, and does not supersede any master support agreements or other support documents between Cisco and its partners/customers.

If you purchased your solution components from Cisco and have a service contract with Cisco, then Cisco TAC accepts the first call for virtualization issues, coordinates triage, and automatically escalates the issue to other vendors covered by Cisco service contracts as required. 

If your solution components are self-sourced, then Cisco TAC does not take the first call, nor does Cisco provide triage coordination or escalation. In these cases, you may need to directly engage with your component vendors to escalate an issue and/or coordinate triage with Cisco TAC.

The following table identifies who takes the first call for each solution component.

{{note| These support demarcations are similar to the appliance hardware demarcations provide by Cisco versus customer self-sourced.}}

 

{| style="width: 812px; height: 108px;" class="wikitable FCK__ShowTableBorders"
|-
! Deployment Scenario
! Server Hardware
! Shared Storage Hardware
! VMware Software
! Cisco Application Software
|-
| UCS + VMware purchased from Cisco
| Cisco
| Third-party1
| Cisco
| Cisco
|-
| UCS + Customer-provided VMware
| Cisco
| Third-party1
| Third-party1
| Cisco
|-
| VCE Vblock
| vcesupport.com
| vcesupport.com
| vcesupport.com
| Cisco
|-
| Customer-provided Server and VMware
| Third-party
| Third-party
| Third-party
| Cisco
|}

1 A VCE Vblock may be leveraged to provide single source of support.

 

----

{| border="1" class="wikitable"
|-
! style="background-color: rgb(255, 215, 0);" | '''Back to:''' [[Unified Communications in a Virtualized Environment|Unified Communications in a Virtualized Environment]]
|}

SocialMiner

2012-10-17T16:15:33Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="socialminer"></meta>

= Welcome to the Cisco SocialMiner Doc Wiki =

'''Cisco SocialMiner''' is a customer-care system that provides capture, filtering, workflow, queuing, and reporting for social-media engagement teams. Internet postings captured by SocialMiner are referred to as Social Contacts. SocialMiner stores the Social Contacts and groups them into user-defined Campaigns. SocialMiner presents the Social Contacts to social-media customer care personnel who can categorize and respond to the postings. SocialMiner also produces reporting statistics on the handling of the Social Contacts.

[[Image:SocialMiner login.png|thumb|right|400px|SocialMiner login.png]]

Click below for details on each release of Cisco SocialMiner:

*[[SocialMiner Release 8.5(1)]]
*[[SocialMiner Release 8.5(2)]]
*[[SocialMiner Release 8.5(3)]]
*[[SocialMiner Release 8.5(4)]]
*[[SocialMiner Release 8.5(5)]]
*[[SocialMiner Release 9.0(1)]]

Additional Resources

*[[SocialMiner Browsers|Supported Web Browsers]]
*[[SocialMiner Feed Sources|SocialMiner Feed Sources]]
*[[Virtualization for Cisco SocialMiner|Virtualization for Cisco SocialMiner]]
*[[Troubleshooting Cisco SocialMiner|Troubleshooting Cisco SocialMiner]]
*[[SocialMiner_Training_Videos|SocialMiner Training Videos]]
*[http://developer.cisco.com/web/socialminer/docs SocialMiner Developer Guide]

[[Category:Cisco_SocialMiner]]

Internetwork Design Guide -- Dial-on-Demand Routing

2012-10-17T16:13:43Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="ddr, dial on demand, internetworking"></meta>
Cisco's dial-on-demand routing (DDR) feature allows you to use existing telephone lines to form a wide-area network (WAN). While using existing telephone lines, you can analyze traffic patterns to determine whether the installation of leased lines is appropriate. DDR provides significant cost savings over leased lines for links that are utilized for only a few hours each day or that experience low traffic flow.

DDR over serial lines requires the use of dialing devices that support V.25bis. V.25bis is an International Telecommunication Union Telecommunication (ITU-T) Standardization Sector standard for in-band signaling to bit synchronous data communications equipment (DCE) devices. A variety of devices support V.25bis, including analog V.32 modems, ISDN terminal adapters, and inverse multiplexers. Cisco's implementation of V.25bis supports devices that use the 1984 version of V.25bis (which requires the use of odd parity), as well as devices that use the 1988 version of V.25bis (which does not use parity).

{{note|The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone (CCITT).}}

This case study describes the use of DDR to connect a worldwide network that consists of a central site located in San Francisco and remote sites located in Tokyo, Singapore, and Hong Kong. The following scenarios and configuration file examples are described:
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Having the Central Site Dial Out|Having the Central Site Dial Out]]
: Describes the central and remote site configurations for three setups: a central site with one interface per remote site, a single interface for multiple remote sites, and multiple interfaces for multiple remote sites. Includes examples of the usage of rotary groups and access lists.
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Having the Central and Remote Sites Dial In and Dial Out|Having the Central and Remote Sites Dial In and Dial Out]]
: Describes the central and remote site configurations for three setups: central site with one interface per remote site, a single interface for multiple remote sites, and multiple interfaces for multiple remote sites. Also describes the usage of Point-to-Point Protocol (PPP) encapsulation and the Challenge Handshake Authentication Protocol (CHAP).
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Having Remote Sites Dial Out|Having Remote Sites Dial Out]]
: A common configuration is one in which the remote sites place calls to the central site but the central site does not dial out. In a "star" topology, it is possible for all of the remote routers to have their serial interfaces on the same subnet as the central site serial interface.
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Using DDR as a Backup to Leased Lines|Using DDR as a Backup to Leased Lines]]
: Describes the use of DDR as a backup method to leased lines and provides examples of how to use floating static routes on single and shared interfaces.
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Using Leased Lines and Dial Backup|Using Leased Lines and Dial Backup]]
: Describes the use of Data Terminal Ready (DTR) dialing and V.25bis dialing with leased lines.

[[Internetwork Design Guide -- Dial-on-Demand Routing#Figure: DDR internetwork topology|Figure: DDR internetwork topology]] shows the topology of the DDR network that is the subject of this case study.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

===== Figure: DDR internetwork topology=====

[[image:nd201501.jpg]]

{{note|All examples and descriptions in this case study refer to features available in Software Release 9.1(9) or later. Some features are available in earlier releases. Features that are available only in Software Release 9.21 are indicated as such.}}

== Having the Central Site Dial Out ==
In this example, the central site calls the remote sites. The cost of initiating a call from the United States to international sites is often lower than if the remote sites initiate the call, and it is expected that remote offices need to connect to the central site network only periodically. This section provides the following configuration examples in which the central site is configured to dial out:
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring One Interface Per Remote Site|Configuring One Interface Per Remote Site]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring Multiple Interfaces for Multiple Remote Sites|Configuring Multiple Interfaces for Multiple Remote Sites]]
=== Configuring One Interface Per Remote Site ===
For the initial configuration, the San Francisco central site is configured to have one interface per remote site.
==== Central Site: Dial Out Only ====
In the following configuration, the central site places the calls with a separate interface configured for each remote site. There is no support for answering calls in this configuration.

<pre>interface serial 5
description DDR connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118527351625
pulse-time 1
dialer-group 1
!
interface serial 6
description DDR connection to Singapore
ip address 128.10.202.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 011653367085
pulse-time 1
dialer-group 1
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
redistribute static
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101</pre>

==== Interface Configuration ====
The configuration of the individual interfaces and Internet Protocol (IP) addresses is straightforward. The IP address for each interface is provided. The example uses a 6-bit host portion in IP addresses. The '''dialer in-band''' command enables DDR and V.25bis dialing on the interface. V.25bis is a ITU-T standard for in-band signaling to bit synchronous DCE devices. A variety of devices support V.25bis, ranging from analog V.32 modems to ISDN terminal adapters to inverse multiplexers.

The '''dialer wait-for-carrier-time '''command is set to 60 seconds. When using V.25bis, the router does not parse any responses it receives from the DCE. Instead, the router depends on the modem's Carrier Detect (CD) signal to indicate that a call has been connected. If the modem's CD signal is not activated before the time allotted with the '''dialer wait-for-carrier-time '''command, the router assumes that the call has failed and disconnects the line. Because the calls are international, and thus take longer to connect than local calls, the wait for carrier time is set to 60 seconds. Even for local calls, analog modems can take 20 to 30 seconds to synchronize to each other, including the time to dial and answer.

The '''dialer string''' command identifies the telephone number of the targeted destination. Because the central site is calling only a single destination, this dialer string is the simplest possible configuration. The''' pulse-time''' command specifies how long Data Terminal Ready (DTR) is held inactive. When using DDR and V.25bis modems, the router disconnects calls by deactivating DTR. This command is automatically inserted into the configuration when the '''dialer in-band''' command is entered.

The '''dialer-group''' command is used to identify each interface with a dialer list set. The '''dialer-list '''command associates each interface with access lists that determine which packets are "interesting" versus "uninteresting" for an interface. For details on access lists and dialer lists, see the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Access List Configuration|Access List Configuration]]" section that follows.
==== Routing Configuration ====
* The Interior Gateway Routing Protocol (IGRP) is used to route traffic on the network. The first two commands in the routing section of the configuration file are '''router igrp''' and '''network'''. These define the IGRP number and the network over which IGRP runs.
* The''' redistribute''' command causes the static route information (defined with the '''ip route''' commands shown in the configuration example) to be sent to other routers in the same IGRP area. Without this command, other routers connected to the central site will not have routes to the remote routers. The three static routes define the subnets on the Ethernet backbone of the remote routers. DDR tends to use static routes extensively because routing updates are not received when the dial-up connection is not active.
==== Access List Configuration ====
The last section of the configuration file provides the access lists that DDR uses to classify "interesting" and "uninteresting" packets. Interesting packets are packets that pass the restrictions of the access lists. These packets either initiate a call (if one is not already in progress) or reset the idle timer if a call is in progress. Uninteresting packets are transmitted if the link is active, but dropped if the link is not active. Uninteresting packets do not initiate calls or reset the idle timer. Access list 101 provides the following filters:
* IGRP packets that are sent to the broadcast address (255.255.255.255) do not cause dialing.
* All other IP packets are interesting and thus may cause dialing and reset the idle timer.
===== Remote Sites: Dial In Only =====
Except for the IP address and the default route, each of the remote sites is configured identically as an answer-only site. The following example lists Hong Kong's configuration:

<pre>interface serial 1
description interface to answer calls from San Francisco
ip address 128.10.200.65 255.255.255.192
dialer in-band
!
ip route 0.0.0.0 0.0.0.0 128.10.200.66 </pre>

The answering site will not disconnect the call. It is up to the calling site to disconnect the call when the line is idle. In this case, the answering site is using static routing. The default route points to the serial interface at the central site.
=== Configuring a Single Interface for Multiple Remote Sites ===
It is possible to use a single interface to call multiple destinations, such as a site in Hong Kong and a site in Paris, France. Because of the time differences, these sites would never need to be connected at the same time. Therefore, a single interface could be used for both sites without the possibility of contention for the interface and without the cost of dedicating a serial port and modem to each destination.
==== Central Site: Dial Out Only ====
In the following configuration, the central site places the calls. A single interface is configured to call multiple remote sites. There is no support for answering calls in this configuration.

<pre>interface serial 5
description DDR connection to Hong Kong and Singapore
ip address 128.10.200.66 255.255.255.192
ip address 128.10.202.66 255.255.255.192 secondary
dialer in-band
dialer wait-for-carrier-time 60
! map Hong Kong to a phone number
dialer map ip 128.10.200.65 0118527351625
! map Singapore to a phone number
dialer map ip 128.10.202.65 011653367085
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
passive-interface serial 5
redistribute static
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

==== Interface Configuration ====
The configuration of the interface in this example is slightly more complicated than the configuration described in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring One Interface Per Remote Site|Configuring One Interface Per Remote Site]]" section. In addition to the original IP address, there is a secondary IP address configured for serial interface 5 because the Singapore and Hong Kong offices are on different subnets.

The '''dialer in-band''', '''dialer wait-for-carrier-time''', '''pulse-time''', and '''dialer-group''' commands are used in the same manner as described previously in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring One Interface Per Remote Site|Configuring One Interface Per Remote Site]]" section. However, the previous '''dialer string''' command has been removed and replaced with two '''dialer map''' commands.

The first '''dialer map''' command maps the telephone number for Hong Kong to its next hop address, which is the IP address of the serial port of the router in Hong Kong. The second '''dialer map''' command maps the telephone number for the Singapore router to the next hop address for Singapore.
==== Routing Configuration ====
The IP static routes define the next hops used in the '''dialer map''' commands. When a packet is received for a host on network 128.10.200.0, it is routed to a next hop address of 128.10.200.65. This route goes out serial interface 5. DDR uses the next hop address to obtain the telephone number of the destination router.

{{note|The use of the '''passive-interface''' command states that routing updates are not to be sent out serial interface 5. Because the remote sites are using a default route, there is no need to send routing updates over the wire.}}

==== Access List Configuration ====
The use of '''dialer map''' commands provides an additional level of filtering. When a packet is received for a host on network 128.10.200.0, it is routed to a next hop address of 128.10.200.65. This route goes out serial interface 5. The packet is compared to the access lists. If the packet is deemed "interesting," the packet's next hop address is compared to the '''dialer map''' commands defined for that interface. If a match is found, the interface is checked to determine whether it is connected to the telephone number for that next hop address. If the interface is not connected, a call is placed to the telephone number. If the interface is currently connected to that number, the idle timer is reset. If the interface is connected to another number (from another '''dialer map''' command), the fast-idle timer is started due to contention for the interface. If there is no match of the next hop address to any of the dialer maps and there is no dialer string defined (which matches all next hop addresses), the packet is dropped.

This additional layer of filtering for the next hop address causes problems for broadcast packets such as routing updates. Because a broadcast packet is transmitted with a next hop address of the broadcast address, the check against the''' dialer map''' commands will fail. If you want broadcast packets transmitted to telephone numbers defined by '''dialer map''' commands, additional '''dialer map''' commands must specify the broadcast address as the next hop address with the same telephone number. For example, you might add the following '''dialer map''' commands:

dialer map ip 255.255.255.255 0118527351625
dialer map ip 255.255.255.255 011653367085

If the interface is currently connected to one of these telephone numbers, and if it receives an IGRP broadcast packet, that packet will now be transmitted because it matches a '''dialer map''' command to an already connected telephone number. (If the connection is already established, both "interesting" and "uninteresting" packets are sent.) If a connection is not already established, adding the '''dialer map''' commands will not cause an IGRP packet sent to the broadcast address to cause dialing because the access lists determine that the IGRP packet is uninteresting.

{{note|In the configuration example described in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]" section, the '''dialer string''' command permits broadcast packets to be sent when the link is connected because the dialer string matches all next hop addresses that did not have a dialer map.}}

==== Remote Sites: Dial In Only ====
Except for the IP address and the default route, each of the remote sites is configured identically as an answer-only site. The following example illustrates the Hong Kong configuration:

<pre>interface serial 1
description interface to answer calls from San Francisco
ip address 128.10.200.65 255.255.255.192
dialer in-band
!
ip route 0.0.0.0 0.0.0.0 128.10.200.66 </pre>

The answering site will not disconnect the call. It is up to the calling site to disconnect the call when the line is idle. A default route is defined back to the central site.
=== Configuring Multiple Interfaces for Multiple Remote Sites ===
When using a single interface with dialer maps, contention for the interface can occur. This contention starts a fast-idle timer that causes lines to remain connected for a shorter idle time than usual, allowing other destinations to use the interface. Dialer rotary groups prevent contention by creating a set of interfaces that can be used to dial out. Rather than statically assigning an interface to a destination, dialer rotary groups allow dynamic allocation of interfaces to telephone numbers. Before a call is placed, the rotary group is searched for an interface that is not in use to place the call. It is not until all of the interfaces in the rotary group are in use that the fast-idle timer is started.

{{note|The following configurations appear as they would be entered at the command line. Due to the way dialer rotary groups function, the output from a '''write terminal''' command on the router may differ slightly from what is shown here.}}

==== Central Site: Dial Out Only ====
The following configuration defines dialer rotary groups on the central site router:

<pre>interface dialer 1
description rotary group for Hong Kong, Tokyo, and Singapore
ip address 128.10.200.66 255.255.255.192
ip address 128.10.202.66 255.255.255.192 secondary
ip address 128.10.204.66 255.255.255.192 secondary
dialer in-band
dialer wait-for-carrier-time 60
! map Hong Kong to a phone number
dialer map ip 128.10.200.65 0118527351625
! map Singapore to a phone number
dialer map ip 128.10.202.65 011653367085
! map Tokyo to a phone number
dialer map ip 128.10.204.65 0118127351625
pulse-time 1
dialer-group 1
!
interface serial 5
dialer rotary-group 1
!
interface serial 6
dialer rotary-group 1
!
router igrp 1
network 128.10.0.0
passive-interface dialer 1
redistribute static
!
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

==== Interface Configuration ====
Specifying a dialer interface is the first step in defining a dialer rotary group. While a dialer interface is not a physical interface, all of the configuration commands that can be specified for a physical interface can be used for a dialer interface. For example, the commands listed under the '''interface dialer''' command are identical to those used for physical serial interface 5 as described in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]" section. Also, an additional '''dialer map''' command has been added to map the next hop address for Tokyo to the telephone number.

The '''dialer rotary-group''' command places physical serial interface 5 and serial interface 6 in the rotary group. Either of these interfaces can be used to dial any of the destinations defined by the '''interface dialer''' command.

As mentioned earlier, when you look at the configuration on the router using the '''write terminal''' command, the configuration may look slightly different from your input. For example, the '''pulse-time '''command associated with the dialer interface will appear with all of the serial interfaces that were added with the '''dialer rotary-group''' command. Certain configuration information associated with the dialer interface is propagated to all of the interfaces that are in the rotary group.
==== Routing Configuration ====
The routing section of this configuration has not changed from the example in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]" section. But if you were to examine the routing table for one of the remote networks using the '''show ip route '''command (for example, '''show ip route 128.10.200.0'''), you would see that the output interface for packets sent to this subnet is interface dialer 1. The actual physical interface over which the packet will be transmitted is not determined until the DDR steps described in the following paragraph are performed.

Before a packet is sent out the dialer interface, DDR checks to determine whether the packet is "interesting" or "uninteresting." DDR then checks the dialer map. Next, all of the physical interfaces in the rotary group are checked to determine whether they are connected to the telephone number. If an appropriate interface is found, the packet is sent out that physical interface. If an interface is not found and the packet is deemed interesting, the rotary group is scanned for an available physical interface. The first available interface found is used to place a call to the telephone number.

{{note|To use dynamic routing, in which two of the remote sites communicate with each other via the central site, the '''no ip split-horizon''' command is required and the '''passive-interface''' command must be removed.}}

==== Access List Configuration ====
This configuration uses the same access lists as the example in the "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]" section. A default route is defined back to the central site.
==== Remote Sites: Dial In Only ====
Except for the IP address and the default route, each of the remote sites is configured identically as an answer-only site. The following example illustrates the Hong Kong configuration:

<pre>interface serial 1
description interface to answer calls from San Francisco
ip address 128.10.200.65 255.255.255.192
dialer in-band
!
ip route 0.0.0.0 0.0.0.0 128.10.200.66 </pre>

The answering site will not disconnect the call. It is up to the calling site to disconnect the call when the line is idle.
== Having the Central and Remote Sites Dial In and Dial Out ==
It is often more convenient to have the remote sites call the central site as its users require, instead of depending on the central site to poll the remote sites. This section provides the following configuration examples in which both the central site and the remote sites are placing calls:
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring One Interface Per Remote Site|Configuring One Interface Per Remote Site]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring Multiple Interfaces for Multiple Remote Sites|Configuring Multiple Interfaces for Multiple Remote Sites]]

=== Configuring One Interface Per Remote Site ===
In order to support dial-in and dial-out for both the central and remote sites using one interface per remote site, each remote site must call in on the specific central site interface that has the dialer string corresponding to the respective remote site telephone number.
==== Central Site: Dial In and Dial Out ====
In the following example, the central San Francisco site is configured to place and answer calls. One interface is configured per remote site.

<pre>interface serial 5
description DDR connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118527351625
pulse-time 1
dialer-group 1
!
interface serial 6
description DDR connection to Singapore
ip address 128.10.202.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 011653367085
pulse-time 1
dialer-group 1
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
redistribute static
!
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>
==== Remote Sites: Dial In and Dial Out ====
All of the remote configurations are similar. Each defines a default route back to the central site and a dialer string that contains the telephone number of the central site.
===== Hong Kong =====
In the following example, the remote Hong Kong site is configured to place and answer calls. Hong Kong's configuration file contains a dialer string of 14155551212, which should call serial interface 5 in San Francisco.

<pre>interface serial 1
description DDR connection to San Francisco
ip address 128.10.200.65 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
!
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>
===== Singapore =====
In the following example, the remote Singapore site is configured to place and answer calls. The Singapore configuration file contains a dialer string of 14155551213, which should call serial interface 6 in San Francisco.

<pre>interface serial 1
description DDR connection to San Francisco
ip address 128.10.202.65 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551213
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
!
ip route 128.10.0.0 255.255.0.0 128.10.202.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

===== Tokyo =====
In the following example, the remote Tokyo site is configured to place and answer calls. The Tokyo configuration file contains a dialer string of 14155551214, which should call serial interface 7 in San Francisco.

<pre>interface serial 1
description DDR connection to San Francisco
ip address 128.10.204.65 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551214
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
!
ip route 128.10.0.0 255.255.0.0 128.10.204.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

Because all incoming calls are assumed to be from the telephone number configured with the '''dialer string''' command, it is important to configure the central and remote sites correctly. For example, if the Singapore dialer string uses the telephone number that Hong Kong uses to call the central site, packets from the central site intended for Hong Kong would be sent to Singapore whenever Singapore called in because Singapore called in using the Hong Kong interface.
=== Configuring a Single Interface for Multiple Remote Sites ===
When multiple sites are calling into a central site, an authentication mechanism must be used unless that central site has one interface dedicated to each incoming call. Without the authentication mechanism, the central site router has no way of identifying the sites to which it is currently connected and cannot ensure that additional calls are not made. Point-to-Point Protocol (PPP) encapsulation with CHAP or Password Authentication Protocol (PAP) provides the mechanism to identify the calling party.

{{note|A router with a built-in ISDN port may be able to use calling party identification. Because calling party identification is not available everywhere, PPP with CHAP provides the identification mechanism. In Software Release 9.21, PPP and Password Authentication Protocol (PAP) can be used in place of CHAP, although PAP is less secure than CHAP. The configuration of PAP would differ slightly from the configuration for CHAP illustrated in this section.}}

==== Central Site: Dial In and Dial Out ====
In the following example, the central San Francisco site is configured to place and answer calls. A single interface is configured for multiple remote sites.

<pre>hostname SanFrancisco
interface serial 5
description DDR connection to Hong Kong and Singapore
ip address 128.10.200.66 255.255.255.192
ip address 128.10.202.66 255.255.255.192 secondary
encapsulation ppp
ppp authentication chap
dialer in-band
dialer wait-for-carrier-time 60
dialer map ip 128.10.200.65 name HongKong 0118527351625
dialer map ip 128.10.202.65 name Singapore 011653367085
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
passive-interface serial 5
redistribute static
!
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username HongKong password password1
username Singapore password password2 </pre>

The command '''encapsulation ppp''' enables PPP encapsulation. The command '''ppp authentication chap''' enables CHAP authentication. In addition, '''username''' commands are entered for each of the remote sites that place calls. The '''username''' command defines the name of the remote router and a password to be associated with that router. When '''ppp authentication chap''' is configured, authentication must be verified or else network traffic will not be transmitted.

The '''dialer map''' command contains the host name of the remote router. This associates the remote router with a next hop address and a telephone number. When a packet is received for a host on network 128.10.200.0, it is routed to a next hop address of 128.10.200.65 via serial interface 5. The packet is compared to the access lists and then the packet's next hop address is compared to the '''dialer map''' commands for serial interface 5.

If the packet is "interesting" and a connection to the number in the '''dialer map''' command is already active on the interface, the idle timer is reset. If a match is found, DDR checks the interface to determine whether it is connected to the telephone number for the next hop address. The comparison to the telephone number is useful only if the router placed the call or if the telephone number was received via calling party ID on an ISDN router. With CHAP and the '''name''' keyword included in the '''dialer map''' command, both the telephone number and the name for a given next hop address are compared to the names of the routers already connected. In this way, calls to destinations to which connections are already established can be avoided.
==== Remote Sites: Dial In and Dial Out ====
In the following configuration examples, the remote sites are configured to place and receive calls to or from a single interface at the central site.
===== Hong Kong =====
The following configuration allows Hong Kong to place and receive calls to and from the central site in San Francisco:

<pre>hostname HongKong
interface serial 1
description DDR connection to SanFrancisco
ip address 128.10.200.65 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
!
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password1 </pre>
===== Singapore =====
The following configuration allows Singapore to place and receive calls to and from the central site in San Francisco:

<pre>hostname Singapore
interface serial 1
description DDR connection to San Francisco
ip address 128.10.202.65 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.202.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password2 </pre>

Unlike the central site, the remote sites do not contain the '''ppp authentication chap''' command. This is because only one site, the central site, is calling in to the remote sites. If only one site is calling in, DDR assumes the call is from the number defined with the '''dialer string''' command; therefore, the command '''ppp authentication chap''' is not required.

{{note|If the remote sites use '''dialer map''' commands instead of '''dialer string''', the '''ppp authentication chap''' command is required, and the '''dialer map''' commands require the '''name''' keyword. This is because the assumption is made that if the '''dialer map''' command is used, multiple sites either can be called or can call in.}}

Also, the remote sites have a '''username''' entry for the San Francisco router, and the San Francisco router contains the username passwords for Singapore and Hong Kong.
=== Configuring Multiple Interfaces for Multiple Remote Sites ===
The configurations in this section are similar to the examples provided in the earlier "[[Internetwork Design Guide -- Dial-on-Demand Routing#Configuring a Single Interface for Multiple Remote Sites|Configuring a Single Interface for Multiple Remote Sites]]" section. The encapsulation is set to PPP and CHAP authentication is required.
==== Central Site: Dial In and Dial Out ====
The following example configures the central site router to dial in and dial out on multiple interfaces to multiple remote sites:

<pre>hostname SanFrancisco
interface dialer 1
description rotary group for Hong Kong, Tokyo, and Singapore
ip address 128.10.200.66 255.255.255.192
ip address 128.10.202.66 255.255.255.192 secondary
ip address 128.10.204.66 255.255.255.192 secondary
encapsulation ppp
ppp authentication chap
dialer in-band
dialer wait-for-carrier-time 60
dialer map ip 128.10.200.65 name HongKong 0118527351625
dialer map ip 128.10.202.65 name Singapore 011653367085
dialer map ip 128.10.204.65 name Tokyo 0118127351625
pulse-time 1
dialer-group 1
!
interface serial 5
dialer rotary-group 1
!
interface serial 6
dialer rotary-group 1
!
router igrp 1
network 128.10.0.0
passive-interface dialer 1
redistribute static
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.65
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.65
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username HongKong password password1
username Singapore password password2
username Tokyo password password3 </pre>
==== Remote Sites: Dial In and Dial Out ====
In the following configuration examples, the remote sites are configured to place and receive calls to or from multiple interfaces at the central site. All of the remote sites dial the same telephone number. At the San Francisco site, that single telephone number will connect to either serial interface 5 or serial interface 6. This capability is provided by the telephone service provider.
===== Hong Kong =====
The following configuration allows Hong Kong to place and receive calls to and from the central site in San Francisco:

<pre>hostname HongKong
interface serial 1
description DDR connection to SanFrancisco
ip address 128.10.200.65 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password1 </pre>
===== Singapore =====
The following configuration allows Singapore to place and receive calls to and from the central site in San Francisco:

<pre>hostname Singapore
interface serial 1
description DDR connection to San Francisco
ip address 128.10.202.65 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.202.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password2 </pre>

===== Tokyo =====
The following configuration allows Tokyo to place and receive calls to and from the central site in San Francisco:

<pre>hostname Tokyo
interface serial 1
description DDR connection to San Francisco
ip address 128.10.204.65 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.204.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password3 </pre>

The remote sites do not use the '''ppp authentication chap'''. This is because only one site, the central site, is calling in to the remote sites. If only one site is calling in, DDR assumes the call is from the number defined with the '''dialer string''' command; therefore, the command '''ppp authentication chap''' is not required. However, if the remote sites use '''dialer map''' commands instead of '''dialer string''', the '''ppp authentication chap''' command is required, and the '''dialer map''' commands require the '''name''' keyword.

Also, each remote site has a '''username SanFrancisco''' entry containing the same password that the central San Francisco site uses to identify the remote site.
== Having Remote Sites Dial Out ==
A common configuration is to have the remote sites place calls to the central site, which does not dial out.
=== Configuring Multiple Interfaces for Multiple Remote Sites ===
In a "star" topology, all the remote routers can have their serial interfaces on the same subnet as the central site serial interface. (See [[Internetwork Design Guide -- Dial-on-Demand Routing#Figure: Remote sites dial out (star topology)|Figure: Remote sites dial out (star topology)]].)

===== Figure: Remote sites dial out (star topology)=====

[[image:nd201502.jpg]]

==== Central Site: Dial In Only ====
The following example configures the central site router to accept dial-ins on multiple interfaces:

<pre>hostname SanFrancisco
interface dialer 1
description rotary group for inbound calls
ip address 128.10.200.66 255.255.255.192
encapsulation ppp
ppp authentication chap
dialer in-band
dialer wait-for-carrier-time 60
dialer map ip 128.10.200.67 name HongKong
dialer map ip 128.10.200.68 name Singapore
dialer map ip 128.10.200.69 name Tokyo
pulse-time 1
dialer-group 1
!
interface serial 5
dialer rotary-group 1
!
interface serial 6
dialer rotary-group 1
!
router igrp 1
network 128.10.0.0
passive-interface dialer 1
redistribute static
! route to Hong Kong
ip route 128.10.201.0 255.255.255.192 128.10.200.67
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.200.68
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.200.69
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username HongKong password password1
username Singapore password password2
username Tokyo password password3 </pre>
==== Remote Sites: Dial Out Only ====
In the following configurations, the remote sites are configured to place calls to multiple interfaces at the central site. The assumption here is that a single telephone number on the central site will get any one of two possible inbound serial interfaces (serial interface 5 or serial interface 6).
===== Hong Kong =====
The following configuration allows Hong Kong to place calls to the central site in San Francisco:

<pre>hostname HongKong
interface ethernet 0
ip address 128.10.201.1 255.255.255.192
interface serial 1
description DDR connection to SanFrancisco
ip address 128.10.200.67 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password1 </pre>
===== Singapore =====
The following configuration allows Singapore to place calls to the central site in San Francisco:

<pre>hostname Singapore
interface ethernet 0
ip address 128.10.202.1 255.255.255.192
interface serial 1
description DDR connection to San Francisco
ip address 128.10.200.68 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password2</pre>
===== Tokyo =====
The following configuration allows Tokyo to place calls to the central site in San Francisco:

<pre>hostname Tokyo
interface ethernet 0
ip address 128.10.204.1 255.255.255.192
interface serial 1
description DDR connection to San Francisco
ip address 128.10.200.69 255.255.255.192
encapsulation ppp
dialer in-band
dialer wait-for-carrier-time 60
dialer string 14155551212
pulse-time 1
dialer-group 1
router igrp 1
network 128.10.0.0
ip route 128.10.0.0 255.255.0.0 128.10.200.66
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
!
username SanFrancisco password password3 </pre>

== Using DDR as a Backup to Leased Lines ==
DDR allows you to quickly enable a WAN connection through the use of existing analog telephone lines. Also, DDR provides cost savings because the line is used on an as-needed basis, whereas a leased line is paid for when the line is not in use. However, there are times when a leased line may provide benefits.

[[Internetwork Design Guide -- Dial-on-Demand Routing#Figure: DDR-to-Leased Line Cutover|Figure: DDR-to-Leased Line Cutover]] shows that there can be a point (when a connection needs to be maintained for more than a certain number of hours per day) at which a DDR link no longer has cost savings, and a leased line may be more cost effective. Additionally, DDR links have a variable cost. It is difficult to predict what a DDR link may cost per month, given that users can initiate traffic at any time.

===== Figure: DDR-to-Leased Line Cutover=====

[[image:nd201503.jpg]]

With leased lines, you can still continue to use dial-up lines as a backup by using either of the following methods:
* Floating static routes (single and shared interfaces) and DDR
* DTR dialing or V.25bis dialing
=== Floating Static Routes ===
Floating static routes are static routes that have an administrative distance greater than the administrative distance of dynamic routes. Administrative distances can be configured on a static route so that the static route is less desirable than a dynamic route. In this manner, the static route is not used when the dynamic route is available. However, if the dynamic route is lost, the static route can take over, and traffic can be sent through this alternative route. If this alternative route is provided by a DDR interface, DDR can be used as a backup mechanism.
==== Central Site ====
The following example outlines a configuration of a central site using leased lines for primary connectivity and DDR for backup:

<pre>interface serial 1
description Leased connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
!
interface serial 2
description leased connection to Singapore
ip address 128.10.202.66 255.255.255.192
!
interface serial 5
description backup DDR connection to Hong Kong
ip address 128.10.200.130 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118527351625
pulse-time 1
dialer-group 1
!
interface serial 6
description backup DDR connection to Singapore
ip address 128.10.202.130 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 011653367085
pulse-time 1
dialer-group 1
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
redistribute static
!
! route to Hong Kong with administrative distance
ip route 128.10.200.0 255.255.255.192 128.10.200.129 150
! route to Singapore with administrative distance
ip route 128.10.202.0 255.255.255.192 128.10.202.129 150
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

Serial interfaces 1 and 2 are used as leased lines to Hong Kong and Singapore. Serial interface 5 backs up serial interface 1; serial interface 6 backs up serial interface 2; and serial interface 7 is used for DDR to Tokyo.
==== Remote Sites ====
Each remote sites has a leased line as a primary link and a DDR line as a backup. For example:

<pre>interface serial 0
description leased line from San Francisco
ip address 128.10.200.65 255.255.255.192
!
interface serial 1
description interface to answer backup calls from San Francisco
ip address 128.10.200.129 255.255.255.192
dialer in-band
!
router igrp 1
network 128.10.0.0
! route back to San Francisco with administrative distance
ip route 128.10.0.0 255.255.0.0 128.10.200.130 150 </pre>

The first serial interface is the leased line, whereas the second answers calls from the central site in case the central site needs to use DDR as a backup method.
=== Floating Static Routes on Shared Interfaces ===
The central site configuration requires a large number of serial ports because each primary port has its own backup. For true redundancy, backup is a requirement. But in many cases, an interface or a set of interfaces can be shared as backup for a set of primary lines. The following configuration shows how to set up a single interface to back up all of the primary lines:

<pre>interface serial 1
description Leased connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
!
interface serial 2
description leased connection to Singapore
ip address 128.10.202.66 255.255.255.192
!
interface serial 5
description backup DDR connection for all destinations except Tokyo
ip address 128.10.200.130 255.255.255.192
ip address 128.10.202.130 255.255.255.192 secondary
dialer in-band
dialer wait-for-carrier-time 60
! map Hong Kong to a phone number
dialer map ip 128.10.200.129 0118527351625
! map Singapore to a phone number
dialer map ip 128.10.202.129 011653367085
pulse-time 1
dialer-group 1
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
passive-interface serial 5
redistribute static
!
! route to Hong Kong with administrative distance
ip route 128.10.200.0 255.255.255.192 128.10.200.129 150
! route to Singapore with administrative distance
ip route 128.10.202.0 255.255.255.192 128.10.202.129 150
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101 </pre>

Serial interface 5 is the DDR backup interface for all destinations and is configured with multiple IP addresses for routing. The '''dialer map''' commands map the next hop addresses to the telephone numbers for each of the destinations. If a dynamic route is lost, the floating static route takes over. The next hop address sends the packets to serial interface 5, where the '''dialer map''' commands place the telephone call.

If two primary lines fail at the same time, there will be contention to use serial interface 5. The fast-idle timer may disconnect the calls. If serial interface 5 were in constant use, one of the primary lines would be disconnected and packets would be dropped. The fact that the backup route is unavailable is not communicated because there is no way to announce that one of the two IP addresses on the interface are unavailable. If you use a dialer rotary group, the contention problem can be avoided.
== Using Leased Lines and Dial Backup ==
This section describes how to use the following two methods for dial backup with leased lines:
* [[Internetwork Design Guide -- Dial-on-Demand Routing#DTR Dialing|DTR Dialing]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#V.25bis Dialing|V.25bis Dialing]]

=== DTR Dialing ===
Since Software Release 8.3, a dial backup capability has been provided. Although it is somewhat more restrictive than floating static routes, dial backup can be used if V.25bis modems are not available or if protocols that do not have support for floating static routes are used.
==== Central Site ====
Dial backup requires that the modems place a call when the Data Terminal Ready (DTR) signal is raised. The telephone number is configured into the modem or other DCE device. That number is called when DTR is raised. The call is disconnected when DTR is lowered. The following configuration illustrates how to take advantage of dial backup and DTR dialing:

<pre>interface serial 1
description Leased connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
backup interface serial 4
ackup delay 0 20
!
interface serial 2
description leased connection to Singapore
ip address 128.10.202.66 255.255.255.192
backup interface serial 5
backup delay 0 20
!
interface serial 4
description backup connection for Hong Kong
ip address 128.10.200.67 255.255.255.192
pulse-time 10
!
interface serial 5
description backup connection for Singapore
ip address 128.10.202.67 255.255.255.192
pulse-time 10
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0 </pre>

This solution requires one serial port per primary line. Because the backup ports are placed on the same subnet as the primary serial port, no static routes are required. The '''backup delay''' command is used to specify how long to wait after the primary has failed before activating the backup line, and how long to delay before deactivating the backup line after the primary line comes back up. In this case, the primary link will be active for 20 seconds before disabling the backup line. This delay allows for flapping in the primary link when it returns to functioning.
==== Remote Sites ====
For the remote sites, the floating static route is not needed. The IP address of the backup interface must be on the same subnet as the primary interface. The following example illustrates the Hong Kong router configuration. Serial interface 0 is the leased line, whereas serial interface 1 answers calls as a backup method:

<pre>interface serial 0
description leased line from San Francisco
ip address 128.10.200.65 255.255.255.192
!
interface serial 1
description interface to answer backup calls from San Francisco
ip address 128.10.200.68 255.255.255.192
!
router igrp 1
network 128.10.0.0</pre>
=== V.25bis Dialing ===
V.25bis dialing capability can be preferable to DTR dialing when multiple telephone numbers are required. Using DTR dialing, most devices will call only a single number. With V.25bis, the router can attempt to call several numbers if the first number does not answer. The following configuration illustrates V.25bis dialing:

<pre>interface serial 1
description Leased connection to Hong Kong
ip address 128.10.200.66 255.255.255.192
backup interface serial 4
backup delay 0 20
!
interface serial 2
description leased connection to Singapore
ip address 128.10.202.66 255.255.255.192
backup interface serial 5
backup delay 0 20
!
interface serial 4
description backup connection for Hong Kong
ip address 128.10.200.67 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer map IP 128.10.200.68 0118527351625
dialer map IP 128.10.200.68 0118527351872
dialer-group 1
pulse-time 1
!
interface serial 5
description backup connection for Singapore
ip address 128.10.202.67 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 011653367085
dialer-group 1
pulse-time 1
!
interface serial 7
description DDR connection to Tokyo
ip address 128.10.204.66 255.255.255.192
dialer in-band
dialer wait-for-carrier-time 60
dialer string 0118127351625
pulse-time 1
dialer-group 1
!
router igrp 1
network 128.10.0.0
redistribute static
!
! route to Hong Kong
ip route 128.10.200.0 255.255.255.192 128.10.200.68
! route to Singapore
ip route 128.10.202.0 255.255.255.192 128.10.202.68
! route to Tokyo
ip route 128.10.204.0 255.255.255.192 128.10.204.65
!
dialer-list 1 protocol IP PERMIT</pre>

Multiple telephone numbers are configured for serial interface 4. The two '''dialer map''' commands have the same next hop address. The software first attempts to call the telephone number specified in the first '''dialer map''' command. If this number fails-that is, if no connection is made before the wait-for-carrier timer expires-the second number is dialed. Each of the other backup interfaces uses a dialer string for the backup telephone number. When using V.25bis with dial backup, the '''dialer-list protocol''' command shown in the preceding example should be used. The dialer list states that all IP traffic is interesting and will, therefore, cause dialing. Routing updates are included. When a serial line is used as a backup, it is normally the state of the primary link, not the fast-idle timer, that determines when to disconnect the call.
== Summary ==
As this case study indicates, there are many ways that dial-on-demand routing (DDR) can be used both for primary access and backup access. Sites can place calls, receive calls, and both place and receive calls. Additionally, using dialer rotary groups provides increased flexibility.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetworking Case Studies

2012-10-17T16:12:47Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="internetworking, network design"></meta>
{| align="center" border="1"
|align="left"|Welcome to '''Cisco DocWiki'''. We encourage [http://tools.cisco.com/RPF/register/register.do registered Cisco.com users] to contribute to this wiki to improve Cisco product documentation. Note that you cannot log in to DocWiki with Cisco.com "guest" account credentials. 
See [[DocWiki:Terms_of_use|Terms of Use]] and [[DocWiki:About|About DocWiki]] for more information about Cisco DocWiki. 
Select the "edit" tab to edit an article or select the "leave a comment" tab to submit questions or comments about the article. 

Click [http://www.cisco.com/en/US/products/ps6441/tsd_products_support_series_home.html here] to return to the Cisco IOS documentation on www.cisco.com.
|}

This article provides internetworking design, implementation case studies, and examples, with the intent to help you identify and implement practical internetworking strategies that are both flexible and scalable.

This article was developed to assist professionals preparing for Cisco Certified Internetwork Expert (CCIE) candidacy, though it is a valuable resource for all internetworking professionals. It is designed for use in conjunction with other Cisco manuals or as a standalone reference. You may find it helpful to refer to the Internetwork Design Guide, which provides detailed descriptions of the internetworking strategies and technologies used in this article.

==Dial-on-Demand Routing==
Cisco's dial-on-demand routing (DDR) feature allows you to use existing telephone lines to form a wide-area network (WAN). While using existing telephone lines, you can analyze traffic patterns to determine whether the installation of leased lines is appropriate. DDR provides significant cost savings over leased lines for links that are utilized for only a few hours each day or that experience low traffic flow.

The following article addresses the dial-on-demand routing (DDR) feature that allows you to use existing telephone lines to form a wide-area network (WAN):
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Dial-on-Demand Routing|Dial-on-Demand Routing]]

==Increasing Security on IP Networks==
Network security is a broad topic that can be addressed at the data link, or media, level (where packet snooping and encryption problems can occur), at the network, or protocol, layer (the point at which Internet Protocol (IP) packets and routing updates are controlled), and at the application layer (where, for example, host-level bugs become issues).

As more users access the Internet and as companies expand their networks, the challenge to provide security for internal networks becomes increasingly difficult. Companies must determine which areas of their internal networks they must protect, learn how to restrict user access to these areas, and determine which types of network services they should filter to prevent potential security breaches.

Cisco Systems provides several network, or protocol, layer features to increase security on IP networks. These features include controls to restrict access to routers and communication servers by way of console port, Telnet, Simple Network Management Protocol (SNMP), Terminal Access Controller Access Control System (TACACS), vendor token cards, and access lists. Firewall architecture setup is also discussed.

The following article addresses the broad topic of network security:
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Increasing Security on IP Networks|Increasing Security on IP Networks]]

==Integrating Enhanced IGRP into Existing Networks==
The Enhanced Interior Gateway Routing Protocol (IGRP) combines the ease of use of traditional routing protocols with the fast rerouting capabilities of link-state protocols, providing advanced capabilities for fast convergence and partial updates. When a network topology change occurs, the Diffusing Algorithm (DUAL) used with Enhanced IGRP provides convergence in less than five seconds in most cases. This is equivalent to the convergence achieved by link-state protocols such as Open Shortest Path First (OSPF), Novell Link Services Protocol (NLSP), and Intermediate System-to-Intermediate System (IS-IS). In addition, Enhanced IGRP sends routing update information only when changes occur, and only the changed information is sent to affected routers.

Enhanced IGRP supports three network level protocols: IP, AppleTalk, and Novell Internetwork Packet Exchange (IPX). Each of these has protocol-specific, value-added functionality. IP Enhanced IGRP supports variable-length subnet masks (VLSMs). IPX Novell Enhanced IGRP supports incremental Service Advertisement Protocol (SAP) updates, removes the Routing Information Protocol (RIP) limitation of 15 hop counts, and provides optimal path use. A router running AppleTalk Enhanced IGRP supports partial, bounded routing updates and provides load sharing and optimal path use.

The following article addresses the Enhanced Interior Gateway Routing Protocol (IGRP):
* [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Integrating Enhanced IGRP into Existing Networks|Integrating Enhanced IGRP into Existing Networks]]

==Reducing SAP Traffic in Novell IPX Networks==
One of the limiting factors in the operation of large Novell Internetwork Packet Exchange (IPX) internetworks is the amount of bandwidth consumed by the large, periodic Service Advertisement Protocol (SAP) updates. Novell servers periodically send clients information about the services they provide by broadcasting this information onto their connected local-area network (LAN) or wide-area network (WAN) interfaces.

The following article addresses how to deal with the nuances of Novel IPX networks:
* [[Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks#Reducing SAP Traffic in Novell IPX Networks|Reducing SAP Traffic in Novell IPX Networks]]

==UDP Broadcast Flooding==
A broadcast is a data packet that is destined for multiple hosts. Broadcasts can occur at the data link layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical network. Network layer broadcasts are sent to all hosts attached to a particular logical network.

The following article addresses he interworkings of broadcast data packets:
* [[Internetwork Design Guide -- UDP Broadcast Flooding#UDP Broadcast Flooding|UDP Broadcast Flooding]]

==STUN for Front-End Processors==
Serial tunneling (STUN) enables the integration of traditional systems network architecture (SNA) networks with multiprotocol networks. STUN also lowers operating costs by reducing the need for redundant remote wide-area links.

The following article addresses serial tunneling (STUN) and the integration of traditional systems network architecture (SNA) networks with multiprotocol networks:
* [[Internetwork Design Guide -- STUN for Front-End Processors#STUN for Front-End Processors|STUN for Front-End Processors]]

==Using ISDN Effectively in Multiprotocol Networks==
As telephone companies make Integrated Services Digital Network (ISDN) services available, ISDN is becoming an increasingly popular way of connecting remote sites.

The following article addresses how, as telephone companies make Integrated Services Digital Network (ISDN) services available, ISDN is becoming an increasingly popular way of connecting remote sites:
* [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Using ISDN Effectively in Multiprotocol Networks|Using ISDN Effectively in Multiprotocol Networks]]

==Using HSRP for Fault-Tolerant IP Routing==
Cisco's Hot Standby Routing Protocol (HSRP) provides automatic router backup when you configure it on Cisco routers that run the Internet Protocol (IP) over Ethernet, Fiber Distributed Data Interface (FDDI), and Token Ring local-area networks (LANs). HSRP is compatible with Novell's Internetwork Packet Exchange (IPX), AppleTalk, and Banyan VINES, and it is compatible with DECnet and Xerox Network Systems (XNS) in certain configurations.

The following article addresses Cisco's Hot Standby Routing Protocol (HSRP), which provides automatic router backup when you configure it on Cisco routers that run the Internet Protocol (IP) over Ethernet, Fiber Distributed Date Interface (FDDI), and Token Ring local-area networks (LANs):
* [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Using HSRP for Fault-Tolerant IP Routing|Using HSRP for Fault-Tolerant IP Routing]]

==LAN Switching==
Today's local-area networks (LANs) are becoming increasingly congested and overburdened. Switching is a technology that alleviates congestion in Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) LANs by reducing traffic and increasing bandwidth. Such switches, known as LAN switches, are designed to work with existing cable infrastructures so that they can be installed with minimal disruption of existing networks. Often, they replace shared hubs. This case study describes how LAN switching works, how virtual LANs work, and how to configure virtual LANs (VLANs) in a topology that consists of Catalyst 5000 LAN switches.

The following article addresses how to deal with the fact that today's local-area networks LANs) are becoming increasingly congested and overburdened:
* [[Internetwork Design Guide -- LAN Switching#LAN Switching|LAN Switching]]

==Multicasting in IP and AppleTalk Networks==
Over the past few years, the concept of end-users being able to send and receive audio and video (known collectively as multimedia) at the desktop has gained considerable attention and acceptance. With high-performance 486, Pentium, and PowerPC CPUs, more than 80 percent of the personal computers sold during 1995 were multimedia capable. Today, it is not uncommon for end-users to run video editing and image processing applications from the desktop.

The proliferation of more and more multimedia-enabled desktop computers has spawned a new class of multimedia applications that operate in networked environments. These network multimedia applications leverage existing network infrastructure to deliver video and audio applications to end users. Most notable are videoconferencing and video server applications. With these applications, video and audio streams are transferred over the network between peers or between clients and servers.

The following article addresses the concept of end-users being able to send and receive audio and video (known collectively as multimedia) at the desktop has gained considerable attention and acceptance that has become increasingly common in the past few years:
* [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Multicasting in IP and AppleTalk Networks|Multicasting in IP and AppleTalk Networks]]

==Scaling Dial-on-Demand Routing==
This case study describes the design of an access network that allows a large number of remote sites to communicate with an existing central-site network. The remote sites consist of local-area networks (LANs) that support several workstations. The workstations run transaction processing software that accesses a database located at the central site. The following objectives guided the design of the access portion of the network:
* The existing network could not be modified to accommodate access by the remote sites.
* The central site must be able to connect to any remote site at any time, and any remote site must be able to connect to the central site at any time.
* When choosing between alternative technologies, choose the most cost-effective technology.
* The design must be flexible enough to accommodate additional remote sites in the future.

The following article addresses the design of an access network that allows a large number of remote sites to communicate with an existing central-site network:
* [[Internetwork Design Guide -- Scaling Dial-on-Demand Routing#Scaling Dial-on-Demand Routing|Scaling Dial-on-Demand Routing]]

==RIP and OSPF Redistribution==
The following case study addresses the issue of integrating Routing Information Protocol (RIP) networks with Open Shortest Path First (OSPF) networks. Most OSPF networks also use RIP to communicate with hosts or to communicate with portions of the internetwork that do not use OSPF. Cisco supports both the RIP and OSPF protocols and provides a way to exchange routing information between RIP and OSPF networks:
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#RIP and OSPF Redistribution|RIP and OSPF Redistribution]]

==Using the Border Gateway Protocol for Interdomain Routing==
The Border Gateway Protocol (BGP), defined in RFC 1771, provides loop-free interdomain routing between autonomous systems. (An autonomous system [AS] is a set of routers that operate under the same administration.) BGP is often run among the networks of Internet service providers (ISPs).

The following article examines how BGP works and how you can use it to participate in routing with other networks that run BGP:
* [[Internetworking Case Studies -- Using the Border Gateway Protocol for Interdomain Routing#Using the Border Gateway Protocol for Interdomain Routing|Using the Border Gateway Protocol for Interdomain Routing]]

[[Category:Internetworking Case Studies]]

Internetworking Basics

2012-10-17T16:11:41Z

Pzimmerm:

{{Template:Required Metadata}}
<meta name="keywords" content="internetworking, network concepts"></meta>
This article along with the next six articles acts as a foundation for the technology discussions that follow. In this article, some fundamental concepts and terms used in the evolving language of internetworking are addressed. In the same way that this book provides a foundation for understanding modern networking, this article summarizes some common themes presented throughout the remainder of this book. Topics include flow control, error checking, and multiplexing, but this article focuses mainly on mapping the Open System Interconnection (OSI) model to networking/internetworking functions, and also summarizing the general nature of addressing schemes within the context of the OSI model. The OSI model represents the building blocks for internetworks. Understanding the conceptual model helps you understand the complex pieces that make up an internetwork.
{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetworking Technology Handbook# Internetworking Basics| Internetworking Basics]] [[Internetworking Technology Handbook# LAN Technologies| LAN Technologies]] [[ Internetworking Technology Handbook # WAN Technologies | WAN Technologies]] [[ Internetworking Technology Handbook # Internet Protocols | Internet Protocols]] [[ Internetworking Technology Handbook # Bridging and Switching | Bridging and Switching]] [[ Internetworking Technology Handbook # Routing | Routing]] [[ Internetworking Technology Handbook # Network Management | Network Management]] [[ Internetworking Technology Handbook # Voice/Data Integration Technologies| Voice/Data Integration Technologies]] [[ Internetworking Technology Handbook # Wireless Technologies| Wireless Technologies]] [[ Internetworking Technology Handbook # Cable Access Technologies| Cable Access Technologies]] [[ Internetworking Technology Handbook # Dial-up Technology| Dial-up Technology]] [[ Internetworking Technology Handbook # Security Technologies| Security Technologies]] [[ Internetworking Technology Handbook # Quality of Service Networking| Quality of Service Networking]] [[ Internetworking Technology Handbook # Network Caching Technologies| Network Caching Technologies]] [[ Internetworking Technology Handbook # IBM Network Management| IBM Network Management]] [[ Internetworking Technology Handbook # Multiservice Access Technologies| Multiservice Access Technologies]]
|}

== What Is an Internetwork? ==
An internetwork is a collection of individual networks, connected by intermediate networking devices, that functions as a single large network. Internetworking refers to the industry, products, and procedures that meet the challenge of creating and administering internetworks.

[[Internetworking Basics#Figure: Different Network Technologies Can Be Connected to Create an Internetwork|Figure: Different Network Technologies Can Be Connected to Create an Internetwork]] illustrates some different kinds of network technologies that can be interconnected by routers and other networking devices to create an internetwork.

=====Figure: Different Network Technologies Can Be Connected to Create an Internetwork=====

[[image:Technology_Handbook-01-2-01.jpg]]

=== History of Internetworking ===
The first networks were time-sharing networks that used mainframes and attached terminals. Such environments were implemented by both IBM's Systems Network Architecture (SNA) and Digital's network architecture.

Local-area networks (LANs) evolved around the PC revolution. LANs enabled multiple users in a relatively small geographical area to exchange files and messages, as well as access shared resources such as file servers and printers.

Wide-area networks (WANs) interconnect LANs with geographically dispersed users to create connectivity. Some of the technologies used for connecting LANs include T1, T3, ATM, ISDN, ADSL, Frame Relay, radio links, and others. New methods of connecting dispersed LANs are appearing everyday.

Today, high-speed LANs and switched internetworks are becoming widely used, largely because they operate at very high speeds and support such high-bandwidth applications as multimedia and videoconferencing.

Internetworking evolved as a solution to three key problems: isolated LANs, duplication of resources, and a lack of network management. Isolated LANs made electronic communication between different offices or departments impossible. Duplication of resources meant that the same hardware and software had to be supplied to each office or department, as did separate support staff. This lack of network management meant that no centralized method of managing and troubleshooting networks existed.
=== Internetworking Challenges ===
Implementing a functional internetwork is no simple task. Many challenges must be faced, especially in the areas of connectivity, reliability, network management, and flexibility. Each area is key in establishing an efficient and effective internetwork.

The challenge when connecting various systems is to support communication among disparate technologies. Different sites, for example, may use different types of media operating at varying speeds, or may even include different types of systems that need to communicate.

Because companies rely heavily on data communication, internetworks must provide a certain level of reliability. This is an unpredictable world, so many large internetworks include redundancy to allow for communication even when problems occur.

Furthermore, network management must provide centralized support and troubleshooting capabilities in an internetwork. Configuration, security, performance, and other issues must be adequately addressed for the internetwork to function smoothly. Security within an internetwork is essential. Many people think of network security from the perspective of protecting the private network from outside attacks. However, it is just as important to protect the network from internal attacks, especially because most security breaches come from inside. Networks must also be secured so that the internal network cannot be used as a tool to attack other external sites.

Early in the year 2000, many major web sites were the victims of distributed denial of service (DDOS) attacks. These attacks were possible because a great number of private networks currently connected with the Internet were not properly secured. These private networks were used as tools for the attackers.

Because nothing in this world is stagnant, internetworks must be flexible enough to change with new demands.

== Open Systems Interconnection Reference Model ==
The Open Systems Interconnection (OSI) reference model describes how information from a software application in one computer moves through a network medium to a software application in another computer. The OSI reference model is a conceptual model composed of seven layers, each specifying particular network functions. The model was developed by the International Organization for Standardization (ISO) in 1984, and it is now considered the primary architectural model for intercomputer communications. The OSI model divides the tasks involved with moving information between networked computers into seven smaller, more manageable task groups. A task or group of tasks is then assigned to each of the seven OSI layers. Each layer is reasonably self-contained so that the tasks assigned to each layer can be implemented independently. This enables the solutions offered by one layer to be updated without adversely affecting the other layers. The following list details the seven layers of the Open Systems Interconnection (OSI) reference model:
* Layer 7-Application
* Layer 6-Presentation
* Layer 5-Session
* Layer 4-Transport
* Layer 3-Network
* Layer 2-Data link
* Layer 1-Physical

{{note|A handy way to remember the seven layers is the sentence "All people seem to need data processing." The beginning letter of each word corresponds to a layer.}}

* All-Application layer
* People-Presentation layer
* Seem-Session layer
* To-Transport layer
* Need-Network layer
* Data-Data link layer
* Processing-Physical layer

[[Internetworking Basics#Figure: The OSI Reference Model Contains Seven Independent Layers|Figure: The OSI Reference Model Contains Seven Independent Layers]] illustrates the seven-layer OSI reference model.

=====Figure: The OSI Reference Model Contains Seven Independent Layers=====

[[image:CT840102.jpg]]

=== Characteristics of the OSI Layers ===
The seven layers of the OSI reference model can be divided into two categories: upper layers and lower layers.

The upper layers of the OSI model deal with application issues and generally are implemented only in software. The highest layer, the application layer, is closest to the end user. Both users and application layer processes interact with software applications that contain a communications component. The term upper layer is sometimes used to refer to any layer above another layer in the OSI model.

The lower layers of the OSI model handle data transport issues. The physical layer and the data link layer are implemented in hardware and software. The lowest layer, the physical layer, is closest to the physical network medium (the network cabling, for example) and is responsible for actually placing information on the medium.

 [[Internetworking Basics#Figure: Two Sets of Layers Make Up the OSI Layers|Figure: Two Sets of Layers Make Up the OSI Layers]] illustrates the division between the upper and lower OSI layers.

=====Figure: Two Sets of Layers Make Up the OSI Layers=====
[[image:CT840103.jpg]]
=== Protocols ===
The OSI model provides a conceptual framework for communication between computers, but the model itself is not a method of communication. Actual communication is made possible by using communication protocols. In the context of data networking, a protocol is a formal set of rules and conventions that governs how computers exchange information over a network medium. A protocol implements the functions of one or more of the OSI layers.

A wide variety of communication protocols exist. Some of these protocols include LAN protocols, WAN protocols, network protocols, and routing protocols. LAN protocols operate at the physical and data link layers of the OSI model and define communication over the various LAN media. WAN protocols operate at the lowest three layers of the OSI model and define communication over the various wide-area media. Routing protocols are network layer protocols that are responsible for exchanging information between routers so that the routers can select the proper path for network traffic. Finally, network protocols are the various upper-layer protocols that exist in a given protocol suite. Many protocols rely on others for operation. For example, many routing protocols use network protocols to exchange information between routers. This concept of building upon the layers already in existence is the foundation of the OSI model.
=== OSI Model and Communication Between Systems ===
Information being transferred from a software application in one computer system to a software application in another must pass through the OSI layers. For example, if a software application in System A has information to transmit to a software application in System B, the application program in System A will pass its information to the application layer (Layer 7) of System A. The application layer then passes the information to the presentation layer (Layer 6), which relays the data to the session layer (Layer 5), and so on down to the physical layer (Layer 1). At the physical layer, the information is placed on the physical network medium and is sent across the medium to System B. The physical layer of System B removes the information from the physical medium, and then its physical layer passes the information up to the data link layer (Layer 2), which passes it to the network layer (Layer 3), and so on, until it reaches the application layer (Layer 7) of System B. Finally, the application layer of System B passes the information to the recipient application program to complete the communication process.
==== Interaction Between OSI Model Layers ====
A given layer in the OSI model generally communicates with three other OSI layers: the layer directly above it, the layer directly below it, and its peer layer in other networked computer systems. The data link layer in System A, for example, communicates with the network layer of System A, the physical layer of System A, and the data link layer in System B.

 [[Internetworking Basics#Figure: OSI Model Layers Communicate with Other Layers|Figure: OSI Model Layers Communicate with Other Layers]] illustrates this example.

=====Figure: OSI Model Layers Communicate with Other Layers=====

[[image:CT840104.jpg]]

===== OSI Layer Services =====
One OSI layer communicates with another layer to make use of the services provided by the second layer. The services provided by adjacent layers help a given OSI layer communicate with its peer layer in other computer systems. Three basic elements are involved in layer services: the service user, the service provider, and the service access point (SAP).

In this context, the service user is the OSI layer that requests services from an adjacent OSI layer. The service provider is the OSI layer that provides services to service users. OSI layers can provide services to multiple service users. The SAP is a conceptual location at which one OSI layer can request the services of another OSI layer.

 [[Internetworking Basics#Figure: Service Users, Providers, and SAPs Interact at the Network and Data Link Layers|Figure: Service Users, Providers, and SAPs Interact at the Network and Data Link Layers]] illustrates how these three elements interact at the network and data link layers.

=====Figure: Service Users, Providers, and SAPs Interact at the Network and Data Link Layers=====

[[image:CT840105.jpg]]

==== OSI Model Layers and Information Exchange ====
The seven OSI layers use various forms of control information to communicate with their peer layers in other computer systems. This control information consists of specific requests and instructions that are exchanged between peer OSI layers.

Control information typically takes one of two forms: headers and trailers. Headers are prepended to data that has been passed down from upper layers. Trailers are appended to data that has been passed down from upper layers. An OSI layer is not required to attach a header or a trailer to data from upper layers.

Headers, trailers, and data are relative concepts, depending on the layer that analyzes the information unit. At the network layer, for example, an information unit consists of a Layer 3 header and data. At the data link layer, however, all the information passed down by the network layer (the Layer 3 header and the data) is treated as data.

In other words, the data portion of an information unit at a given OSI layer potentially can contain headers, trailers, and data from all the higher layers. This is known as encapsulation.

 [[Internetworking Basics#Figure: Headers and Data Can Be Encapsulated During Information Exchange|Figure: Headers and Data Can Be Encapsulated During Information Exchange]] shows how the header and data from one layer are encapsulated into the header of the next lowest layer.

=====Figure: Headers and Data Can Be Encapsulated During Information Exchange=====

[[image:Technology_Handbook-01-2-06.jpg]]

===== Information Exchange Process =====
The information exchange process occurs between peer OSI layers. Each layer in the source system adds control information to data, and each layer in the destination system analyzes and removes the control information from that data.

If System A has data from a software application to send to System B, the data is passed to the application layer. The application layer in System A then communicates any control information required by the application layer in System B by prepending a header to the data. The resulting information unit (a header and the data) is passed to the presentation layer, which prepends its own header containing control information intended for the presentation layer in System B. The information unit grows in size as each layer prepends its own header (and, in some cases, a trailer) that contains control information to be used by its peer layer in System B. At the physical layer, the entire information unit is placed onto the network medium.

The physical layer in System B receives the information unit and passes it to the data link layer. The data link layer in System B then reads the control information contained in the header prepended by the data link layer in System A. The header is then removed, and the remainder of the information unit is passed to the network layer. Each layer performs the same actions: The layer reads the header from its peer layer, strips it off, and passes the remaining information unit to the next highest layer. After the application layer performs these actions, the data is passed to the recipient software application in System B, in exactly the form in which it was transmitted by the application in System A.
=== OSI Model Physical Layer ===
The physical layer defines the electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating the physical link between communicating network systems. Physical layer specifications define characteristics such as voltage levels, timing of voltage changes, physical data rates, maximum transmission distances, and physical connectors. Physical layer implementations can be categorized as either LAN or WAN specifications.

 [[Internetworking Basics#Figure: Physical Layer Implementations Can Be LAN or WAN Specifications|Figure: Physical Layer Implementations Can Be LAN or WAN Specifications]] illustrates some common LAN and WAN physical layer implementations.

=====Figure: Physical Layer Implementations Can Be LAN or WAN Specifications=====

[[image:CT840107.jpg]]

=== OSI Model Data Link Layer ===
The data link layer provides reliable transit of data across a physical network link. Different data link layer specifications define different network and protocol characteristics, including physical addressing, network topology, error notification, sequencing of frames, and flow control. Physical addressing (as opposed to network addressing) defines how devices are addressed at the data link layer. Network topology consists of the data link layer specifications that often define how devices are to be physically connected, such as in a bus or a ring topology. Error notification alerts upper-layer protocols that a transmission error has occurred, and the sequencing of data frames reorders frames that are transmitted out of sequence. Finally, flow control moderates the transmission of data so that the receiving device is not overwhelmed with more traffic than it can handle at one time.

The Institute of Electrical and Electronics Engineers (IEEE) has subdivided the data link layer into two sublayers: Logical Link Control (LLC) and Media Access Control (MAC).

 [[Internetworking Basics#Figure: The Data Link Layer Contains Two Sublayers|Figure: The Data Link Layer Contains Two Sublayers]] illustrates the IEEE sublayers of the data link layer.

=====Figure: The Data Link Layer Contains Two Sublayers=====

[[image:CT840108.jpg]]

The Logical Link Control (LLC) sublayer of the data link layer manages communications between devices over a single link of a network. LLC is defined in the IEEE 802.2 specification and supports both connectionless and connection-oriented services used by higher-layer protocols. IEEE 802.2 defines a number of fields in data link layer frames that enable multiple higher-layer protocols to share a single physical data link. The Media Access Control (MAC) sublayer of the data link layer manages protocol access to the physical network medium. The IEEE MAC specification defines MAC addresses, which enable multiple devices to uniquely identify one another at the data link layer.
=== OSI Model Network Layer ===
The network layer defines the network address, which differs from the MAC address. Some network layer implementations, such as the Internet Protocol (IP), define network addresses in a way that route selection can be determined systematically by comparing the source network address with the destination network address and applying the subnet mask. Because this layer defines the logical network layout, routers can use this layer to determine how to forward packets. Because of this, much of the design and configuration work for internetworks happens at Layer 3, the network layer.
=== OSI Model Transport Layer ===
The transport layer accepts data from the session layer and segments the data for transport across the network. Generally, the transport layer is responsible for making sure that the data is delivered error-free and in the proper sequence. Flow control generally occurs at the transport layer.

Flow control manages data transmission between devices so that the transmitting device does not send more data than the receiving device can process. Multiplexing enables data from several applications to be transmitted onto a single physical link. Virtual circuits are established, maintained, and terminated by the transport layer. Error checking involves creating various mechanisms for detecting transmission errors, while error recovery involves acting, such as requesting that data be retransmitted, to resolve any errors that occur.

The transport protocols used on the Internet are TCP and UDP.
=== OSI Model Session Layer ===
The session layer establishes, manages, and terminates communication sessions. Communication sessions consist of service requests and service responses that occur between applications located in different network devices. These requests and responses are coordinated by protocols implemented at the session layer. Some examples of session-layer implementations include Zone Information Protocol (ZIP), the AppleTalk protocol that coordinates the name binding process; and Session Control Protocol (SCP), the DECnet Phase IV session layer protocol.
=== OSI Model Presentation Layer ===
The presentation layer provides a variety of coding and conversion functions that are applied to application layer data. These functions ensure that information sent from the application layer of one system would be readable by the application layer of another system. Some examples of presentation layer coding and conversion schemes include common data representation formats, conversion of character representation formats, common data compression schemes, and common data encryption schemes.

Common data representation formats, or the use of standard image, sound, and video formats, enable the interchange of application data between different types of computer systems. Conversion schemes are used to exchange information with systems by using different text and data representations, such as EBCDIC and ASCII. Standard data compression schemes enable data that is compressed at the source device to be properly decompressed at the destination. Standard data encryption schemes enable data encrypted at the source device to be properly deciphered at the destination.

Presentation layer implementations are not typically associated with a particular protocol stack. Some well-known standards for video include QuickTime and Motion Picture Experts Group (MPEG). QuickTime is an Apple Computer specification for video and audio, and MPEG is a standard for video compression and coding.

Among the well-known graphic image formats are Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), and Tagged Image File Format (TIFF). GIF is a standard for compressing and coding graphic images. JPEG is another compression and coding standard for graphic images, and TIFF is a standard coding format for graphic images.
=== OSI Model Application Layer ===
The application layer is the OSI layer closest to the end user, which means that both the OSI application layer and the user interact directly with the software application.

This layer interacts with software applications that implement a communicating component. Such application programs fall outside the scope of the OSI model. Application layer functions typically include identifying communication partners, determining resource availability, and synchronizing communication.

When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit. When determining resource availability, the application layer must decide whether sufficient network resources for the requested communication exist. In synchronizing communication, all communication between applications requires cooperation that is managed by the application layer.

Some examples of application layer implementations include Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).

== Information Formats ==
The data and control information that is transmitted through internetworks takes a variety of forms. The terms used to refer to these information formats are not used consistently in the internetworking industry but sometimes are used interchangeably. Common information formats include frames, packets, datagrams, segments, messages, cells, and data units.

A frame is an information unit whose source and destination are data link layer entities. A frame is composed of the data link layer header (and possibly a trailer) and upper-layer data. The header and trailer contain control information intended for the data link layer entity in the destination system. Data from upper-layer entities is encapsulated in the data link layer header and trailer.

 [[Internetworking Basics#Figure: Data from Upper-Layer Entities Makes Up the Data Link Layer Frame|Figure: Data from Upper-Layer Entities Makes Up the Data Link Layer Frame]] illustrates the basic components of a data link layer frame.

=====Figure: Data from Upper-Layer Entities Makes Up the Data Link Layer Frame=====

[[image:CT840109.jpg]]

A packet is an information unit whose source and destination are network layer entities. A packet is composed of the network layer header (and possibly a trailer) and upper-layer data. The header and trailer contain control information intended for the network layer entity in the destination system. Data from upper-layer entities is encapsulated in the network layer header and trailer.

 [[Internetworking Basics#Figure: Three Basic Components Make Up a Network Layer Packet|Figure: Three Basic Components Make Up a Network Layer Packet]] illustrates the basic components of a network layer packet.

=====Figure: Three Basic Components Make Up a Network Layer Packet=====

[[image:CT840110.jpg]]

The term datagram usually refers to an information unit whose source and destination are network layer entities that use connectionless network service.

The term segment usually refers to an information unit whose source and destination are transport layer entities.

A message is an information unit whose source and destination entities exist above the network layer (often at the application layer).

A cell is an information unit of a fixed size whose source and destination are data link layer entities. Cells are used in switched environments, such as Asynchronous Transfer Mode (ATM) and Switched Multimegabit Data Service (SMDS) networks. A cell is composed of the header and payload. The header contains control information intended for the destination data link layer entity and is typically 5 bytes long. The payload contains upper-layer data that is encapsulated in the cell header and is typically 48 bytes long.

The length of the header and the payload fields always are the same for each cell.

 [[Internetworking Basics#Figure: Two Components Make Up a Typical Cell|Figure: Two Components Make Up a Typical Cell]] depicts the components of a typical cell.

=====Figure: Two Components Make Up a Typical Cell=====

[[image:CT840111.jpg]]

Data unit is a generic term that refers to a variety of information units. Some common data units are service data units (SDUs), protocol data units, and bridge protocol data units (BPDUs). SDUs are information units from upper-layer protocols that define a service request to a lower-layer protocol. PDU is OSI terminology for a packet. BPDUs are used by the spanning-tree algorithm as hello messages.
== ISO Hierarchy of Networks ==
Large networks typically are organized as hierarchies. A hierarchical organization provides such advantages as ease of management, flexibility, and a reduction in unnecessary traffic. Thus, the International Organization for Standardization (ISO) has adopted a number of terminology conventions for addressing network entities. Key terms defined in this section include end system (ES), intermediate system (IS), area, and autonomous system (AS).

An ES is a network device that does not perform routing or other traffic forwarding functions. Typical ESs include such devices as terminals, personal computers, and printers. An IS is a network device that performs routing or other traffic-forwarding functions. Typical ISs include such devices as routers, switches, and bridges. Two types of IS networks exist: intradomain IS and interdomain IS. An intradomain IS communicates within a single autonomous system, while an interdomain IS communicates within and between autonomous systems. An area is a logical group of network segments and their attached devices. Areas are subdivisions of autonomous systems (AS's). An AS is a collection of networks under a common administration that share a common routing strategy. Autonomous systems are subdivided into areas, and an AS is sometimes called a domain.

[[Internetworking Basics#Figure: A Hierarchical Network Contains Numerous Components|Figure: A Hierarchical Network Contains Numerous Components]] illustrates a hierarchical network and its components.

=====Figure: A Hierarchical Network Contains Numerous Components=====

[[image:CT840112.jpg]]

== Connection-Oriented and Connectionless Network Services ==
In general, transport protocols can be characterized as being either connection-oriented or connectionless. Connection-oriented services must first establish a connection with the desired service before passing any data. A connectionless service can send the data without any need to establish a connection first. In general, connection-oriented services provide some level of delivery guarantee, whereas connectionless services do not.

Connection-oriented service involves three phases: connection establishment, data transfer, and connection termination.

During connection establishment, the end nodes may reserve resources for the connection. The end nodes also may negotiate and establish certain criteria for the transfer, such as a window size used in TCP connections. This resource reservation is one of the things exploited in some denial of service (DOS) attacks. An attacking system will send many requests for establishing a connection but then will never complete the connection. The attacked computer is then left with resources allocated for many never-completed connections. Then, when an end node tries to complete an actual connection, there are not enough resources for the valid connection.

The data transfer phase occurs when the actual data is transmitted over the connection. During data transfer, most connection-oriented services will monitor for lost packets and handle resending them. The protocol is generally also responsible for putting the packets in the right sequence before passing the data up the protocol stack.

When the transfer of data is complete, the end nodes terminate the connection and release resources reserved for the connection.

Connection-oriented network services have more overhead than connectionless ones. Connection-oriented services must negotiate a connection, transfer data, and tear down the connection, whereas a connectionless transfer can simply send the data without the added overhead of creating and tearing down a connection. Each has its place in internetworks.
== Internetwork Addressing ==
Internetwork addresses identify devices separately or as members of a group. Addressing schemes vary depending on the protocol family and the OSI layer. Three types of internetwork addresses are commonly used: data link layer addresses, Media Access Control (MAC) addresses, and network layer addresses.
=== Data Link Layer Addresses ===
A data link layer address uniquely identifies each physical network connection of a network device. Data-link addresses sometimes are referred to as physical or hardware addresses. Data-link addresses usually exist within a flat address space and have a pre-established and typically fixed relationship to a specific device.

End systems generally have only one physical network connection and thus have only one data-link address. Routers and other internetworking devices typically have multiple physical network connections and therefore have multiple data-link addresses.

 [[Internetworking Basics#Figure: Each Interface on a Device Is Uniquely Identified by a Data-Link Address|Figure: Each Interface on a Device Is Uniquely Identified by a Data-Link Address]] illustrates how each interface on a device is uniquely identified by a data-link address.

=====Figure: Each Interface on a Device Is Uniquely Identified by a Data-Link Address=====

[[image:Technology_Handbook-01-2-13.jpg]]

=== MAC Addresses ===
Media Access Control (MAC) addresses consist of a subset of data link layer addresses. MAC addresses identify network entities in LANs that implement the IEEE MAC addresses of the data link layer. As with most data-link addresses, MAC addresses are unique for each LAN interface.

 [[Internetworking Basics#Figure: MAC Addresses, Data-Link Addresses, and the IEEE Sublayers of the Data Link Layer Are All Related|Figure: MAC Addresses, Data-Link Addresses, and the IEEE Sublayers of the Data Link Layer Are All Related]] illustrates the relationship between MAC addresses, data-link addresses, and the IEEE sublayers of the data link layer.

=====Figure: MAC Addresses, Data-Link Addresses, and the IEEE Sublayers of the Data Link Layer Are All Related=====

[[image:CT840114.jpg]]

MAC addresses are 48 bits in length and are expressed as 12 hexadecimal digits. The first 6 hexadecimal digits, which are administered by the IEEE, identify the manufacturer or vendor and thus comprise the Organizationally Unique Identifier (OUI). The last 6 hexadecimal digits comprise the interface serial number, or another value administered by the specific vendor. MAC addresses sometimes are called burned-in addresses (BIAs) because they are burned into read-only memory (ROM) and are copied into random-access memory (RAM) when the interface card initializes.

 [[Internetworking Basics#Figure: The MAC Address Contains a Unique Format of Hexadecimal Digits|Figure: The MAC Address Contains a Unique Format of Hexadecimal Digits]] illustrates the MAC address format.

=====Figure: The MAC Address Contains a Unique Format of Hexadecimal Digits=====

[[image:CT840115.jpg]]

=== Mapping Addresses ===
Because internetworks generally use network addresses to route traffic around the network, there is a need to map network addresses to MAC addresses. When the network layer has determined the destination station's network address, it must forward the information over a physical network using a MAC address. Different protocol suites use different methods to perform this mapping, but the most popular is Address Resolution Protocol (ARP).

Different protocol suites use different methods for determining the MAC address of a device. The following three methods are used most often. Address Resolution Protocol (ARP) maps network addresses to MAC addresses. The Hello protocol enables network devices to learn the MAC addresses of other network devices. MAC addresses either are embedded in the network layer address or are generated by an algorithm.

Address Resolution Protocol (ARP) is the method used in the TCP/IP suite. When a network device needs to send data to another device on the same network, it knows the source and destination network addresses for the data transfer. It must somehow map the destination address to a MAC address before forwarding the data. First, the sending station will check its ARP table to see if it has already discovered this destination station's MAC address. If it has not, it will send a broadcast on the network with the destination station's IP address contained in the broadcast. Every station on the network receives the broadcast and compares the embedded IP address to its own. Only the station with the matching IP address replies to the sending station with a packet containing the MAC address for the station. The first station then adds this information to its ARP table for future reference and proceeds to transfer the data.

When the destination device lies on a remote network, one beyond a router, the process is the same except that the sending station sends the ARP request for the MAC address of its default gateway. It then forwards the information to that device. The default gateway will then forward the information over whatever networks necessary to deliver the packet to the network on which the destination device resides. The router on the destination device's network then uses ARP to obtain the MAC of the actual destination device and delivers the packet.

The Hello protocol is a network layer protocol that enables network devices to identify one another and indicate that they are still functional. When a new end system powers up, for example, it broadcasts hello messages onto the network. Devices on the network then return hello replies, and hello messages are also sent at specific intervals to indicate that they are still functional. Network devices can learn the MAC addresses of other devices by examining Hello protocol packets.

Three protocols use predictable MAC addresses. In these protocol suites, MAC addresses are predictable because the network layer either embeds the MAC address in the network layer address or uses an algorithm to determine the MAC address. The three protocols are Xerox Network Systems (XNS), Novell Internetwork Packet Exchange (IPX), and DECnet Phase IV.
=== Network Layer Addresses ===
A network layer address identifies an entity at the network layer of the OSI layers. Network addresses usually exist within a hierarchical address space and sometimes are called virtual or logical addresses.

The relationship between a network address and a device is logical and unfixed; it typically is based either on physical network characteristics (the device is on a particular network segment) or on groupings that have no physical basis (the device is part of an AppleTalk zone). End systems require one network layer address for each network layer protocol that they support. (This assumes that the device has only one physical network connection.) Routers and other internetworking devices require one network layer address per physical network connection for each network layer protocol supported. For example, a router with three interfaces each running AppleTalk, TCP/IP, and OSI must have three network layer addresses for each interface. The router therefore has nine network layer addresses.

[[Internetworking Basics#Figure: Each Network Interface Must Be Assigned a Network Address for Each Protocol Supported|Figure: Each Network Interface Must Be Assigned a Network Address for Each Protocol Supported]] illustrates how each network interface must be assigned a network address for each protocol supported.

=====Figure: Each Network Interface Must Be Assigned a Network Address for Each Protocol Supported=====

[[image:CT840116.jpg]]

=== Hierarchical Versus Flat Address Space ===
Internetwork address space typically takes one of two forms: hierarchical address space or flat address space. A hierarchical address space is organized into numerous subgroups, each successively narrowing an address until it points to a single device (in a manner similar to street addresses). A flat address space is organized into a single group (in a manner similar to U.S. Social Security numbers).

Hierarchical addressing offers certain advantages over flat-addressing schemes. Address sorting and recall is simplified using comparison operations. For example, "Ireland" in a street address eliminates any other country as a possible location.

 [[Internetworking Basics#Figure: Hierarchical and Flat Address Spaces Differ in Comparison Operations|Figure: Hierarchical and Flat Address Spaces Differ in Comparison Operations]] illustrates the difference between hierarchical and flat address spaces.

=====Figure: Hierarchical and Flat Address Spaces Differ in Comparison Operations=====

[[image:Technology_Handbook-01-2-17.jpg]]

=== Address Assignments ===
Addresses are assigned to devices as one of two types: static and dynamic. Static addresses are assigned by a network administrator according to a preconceived internetwork addressing plan. A static address does not change until the network administrator manually changes it. Dynamic addresses are obtained by devices when they attach to a network, by means of some protocol-specific process. A device using a dynamic address often has a different address each time that it connects to the network. Some networks use a server to assign addresses. Server-assigned addresses are recycled for reuse as devices disconnect. A device is therefore likely to have a different address each time that it connects to the network.
=== Addresses Versus Names ===
Internetwork devices usually have both a name and an address associated with them. Internetwork names typically are location-independent and remain associated with a device wherever that device moves (for example, from one building to another). Internetwork addresses usually are location-dependent and change when a device is moved (although MAC addresses are an exception to this rule). As with network addresses being mapped to MAC addresses, names are usually mapped to network addresses through some protocol. The Internet uses Domain Name System (DNS) to map the name of a device to its IP address. For example, it's easier for you to remember www.cisco.com instead of some IP address. Therefore, you type www.cisco.com into your browser when you want to access Cisco's web site. Your computer performs a DNS lookup of the IP address for Cisco's web server and then communicates with it using the network address.
== Flow Control Basics ==
Flow control is a function that prevents network congestion by ensuring that transmitting devices do not overwhelm receiving devices with data. A high-speed computer, for example, may generate traffic faster than the network can transfer it, or faster than the destination device can receive and process it. The three commonly used methods for handling network congestion are buffering, transmitting source-quench messages, and windowing.

Buffering is used by network devices to temporarily store bursts of excess data in memory until they can be processed. Occasional data bursts are easily handled by buffering. Excess data bursts can exhaust memory, however, forcing the device to discard any additional datagrams that arrive.

Source-quench messages are used by receiving devices to help prevent their buffers from overflowing. The receiving device sends source-quench messages to request that the source reduce its current rate of data transmission. First, the receiving device begins discarding received data due to overflowing buffers. Second, the receiving device begins sending source-quench messages to the transmitting device at the rate of one message for each packet dropped. The source device receives the source-quench messages and lowers the data rate until it stops receiving the messages. Finally, the source device then gradually increases the data rate as long as no further source-quench requests are received.

Windowing is a flow-control scheme in which the source device requires an acknowledgment from the destination after a certain number of packets have been transmitted. With a window size of 3, the source requires an acknowledgment after sending three packets, as follows. First, the source device sends three packets to the destination device. Then, after receiving the three packets, the destination device sends an acknowledgment to the source. The source receives the acknowledgment and sends three more packets. If the destination does not receive one or more of the packets for some reason, such as overflowing buffers, it does not receive enough packets to send an acknowledgment. The source then retransmits the packets at a reduced transmission rate.
== Error-Checking Basics ==
Error-checking schemes determine whether transmitted data has become corrupt or otherwise damaged while traveling from the source to the destination. Error checking is implemented at several of the OSI layers.

One common error-checking scheme is the cyclic redundancy check (CRC), which detects and discards corrupted data. Error-correction functions (such as data retransmission) are left to higher-layer protocols. A CRC value is generated by a calculation that is performed at the source device. The destination device compares this value to its own calculation to determine whether errors occurred during transmission. First, the source device performs a predetermined set of calculations over the contents of the packet to be sent. Then, the source places the calculated value in the packet and sends the packet to the destination. The destination performs the same predetermined set of calculations over the contents of the packet and then compares its computed value with that contained in the packet. If the values are equal, the packet is considered valid. If the values are unequal, the packet contains errors and is discarded.
== Multiplexing Basics ==
Multiplexing is a process in which multiple data channels are combined into a single data or physical channel at the source. Multiplexing can be implemented at any of the OSI layers. Conversely, demultiplexing is the process of separating multiplexed data channels at the destination. One example of multiplexing is when data from multiple applications is multiplexed into a single lower-layer data packet.

[[Internetworking Basics#Figure: Multiple Applications Can Be Multiplexed into a Single Lower-Layer Data Packet|Figure: Multiple Applications Can Be Multiplexed into a Single Lower-Layer Data Packet]] illustrates this example.

=====Figure: Multiple Applications Can Be Multiplexed into a Single Lower-Layer Data Packet=====

[[image:CT840118.jpg]]

Another example of multiplexing is when data from multiple devices is combined into a single physical channel (using a device called a multiplexer).

[[Internetworking Basics#Figure: Multiple Devices Can Be Multiplexed into a Single Physical Channel|Figure: Multiple Devices Can Be Multiplexed into a Single Physical Channel]] illustrates this example.

=====Figure: Multiple Devices Can Be Multiplexed into a Single Physical Channel=====

[[image:Technology_Handbook-01-2-19.jpg]]

A multiplexer is a physical layer device that combines multiple data streams into one or more output channels at the source. Multiplexers demultiplex the channels into multiple data streams at the remote end and thus maximize the use of the bandwidth of the physical medium by enabling it to be shared by multiple traffic sources.

Some methods used for multiplexing data are time-division multiplexing (TDM), asynchronous time-division multiplexing (ATDM), frequency-division multiplexing (FDM), and statistical multiplexing.

In TDM, information from each data channel is allocated bandwidth based on preassigned time slots, regardless of whether there is data to transmit. In ATDM, information from data channels is allocated bandwidth as needed by using dynamically assigned time slots. In FDM, information from each data channel is allocated bandwidth based on the signal frequency of the traffic. In statistical multiplexing, bandwidth is dynamically allocated to any data channels that have information to transmit.
== Standards Organizations ==
A wide variety of organizations contribute to internetworking standards by providing forums for discussion, turning informal discussion into formal specifications, and proliferating specifications after they are standardized.

Most standards organizations create formal standards by using specific processes: organizing ideas, discussing the approach, developing draft standards, voting on all or certain aspects of the standards, and then formally releasing the completed standard to the public.

Some of the best-known standards organizations that contribute to internetworking standards include these:
* '''International Organization for Standardization (ISO)'''-ISO is an international standards organization responsible for a wide range of standards, including many that are relevant to networking. Its best-known contribution is the development of the OSI reference model and the OSI protocol suite.
* '''American National Standards Institute (ANSI)'''-ANSI, which is also a member of the ISO, is the coordinating body for voluntary standards groups within the United States. ANSI developed the Fiber Distributed Data Interface (FDDI) and other communications standards.
* '''Electronic Industries Association (EIA)'''-EIA specifies electrical transmission standards, including those used in networking. The EIA developed the widely used EIA/TIA-232 standard (formerly known as RS-232).
* '''Institute of Electrical and Electronic Engineers (IEEE)'''-IEEE is a professional organization that defines networking and other standards. The IEEE developed the widely used LAN standards IEEE 802.3 and IEEE 802.5.
* '''International Telecommunication Union Telecommunication Standardization Sector (ITU-T)'''-Formerly called the Committee for International Telegraph and Telephone (CCITT), ITU-T is now an international organization that develops communication standards. The ITU-T developed X.25 and other communications standards.
* '''Internet Activities Board (IAB)'''-IAB is a group of internetwork researchers who discuss issues pertinent to the Internet and set Internet policies through decisions and task forces. The IAB designates some Request For Comments (RFC) documents as Internet standards, including Transmission Control Protocol/Internet Protocol (TCP/IP) and the Simple Network Management Protocol (SNMP).
== Summary ==
This article introduced the building blocks on which internetworks are built. Under-standing where complex pieces of internetworks fit into the OSI model will help you understand the concepts better. Internetworks are complex systems that, when viewed as a whole, are too much to understand. Only by breaking the network down into the conceptual pieces can it be easily understood. As you read and experience internetworks, try to think of them in terms of OSI layers and conceptual pieces.

Understanding the interaction between various layers and protocols makes designing, configuring, and diagnosing internetworks possible. Without understanding of the building blocks, you cannot understand the interaction between them.
== Review Questions ==

'''Q''' - ''What are the layers of the OSI model?''

'''A''' - Application, presentation, session, transport, network, data link, physical. Remember the sentence "All people seem to need data processing."

'''Q''' - ''Which layer determines path selection in an internetwork?''

'''A''' - Layer 3, the network layer.

'''Q''' - ''What types of things are defined at the physical layer?''

'''A''' - Voltage levels, time of voltage changes, physical data rates, maximum transmission distances, physical connectors, and type of media.

'''Q''' - ''What is one method of mapping network addresses to MAC addresses?''

'''A''' - ARP, Hello, predictable.

'''Q''' - ''Which includes more overhead, connection-oriented or connectionless services?''

'''A''' - Connection-oriented.

== For More Information ==
Cisco's web site (www.cisco.com) is a wonderful source for more information about these topics. The Documentation section includes in-depth discussions on many of the topics covered in this article.

Teare, Diane. ''Designing Cisco Networks.'' Indianapolis: Cisco Press, July 1999.

[[Category:IOS Technology Handbook]]

Internetworking Technology Handbook

2012-10-16T21:40:34Z

Pzimmerm:

{{Template:Required Metadata}}
<meta name="keywords" content="network technology, network concepts, internetworking, technology"></meta>
{| align="center" border="1"
|align="left"|Welcome to '''Cisco DocWiki'''. We encourage [http://tools.cisco.com/RPF/register/register.do registered Cisco.com users] to contribute to this wiki to improve Cisco product documentation. Note that you cannot log in to DocWiki with Cisco.com "guest" account credentials. 
See [[DocWiki:Terms_of_use|Terms of Use]] and [[DocWiki:About|About DocWiki]] for more information about Cisco DocWiki. Select the "Edit" tab to edit an article or select the "Leave a Comment" tab to submit questions or comments about the article. 

This article provides guidance for understanding internetworking technology. Different components of internetwork and the protocols used are described.
Click [http://www.cisco.com/en/US/products/ps6441/tsd_products_support_series_home.html here] to return to the Cisco IOS documentation on www.cisco.com.
|}

==Creating a PDF of the Internetworking Technology Handbook==

[[Internetworking Technology Handbook -- Creating a PDF|Create a PDF of the Internetworking Technology Handbook]] that you can save on your computer and print.

==Internetworking Basics==
An internetwork is a collection of individual networks, connected by intermediate networking devices, that functions as a single large network. Internetworking refers to the industry, products, and procedures that meet the challenge of creating and administering internetworks.

The following articles provide information about internetworking basics:
* [[Internetworking Basics]]
* [[Introduction to LAN Protocols]]
* [[Introduction to WAN Technologies]]
* [[Bridging and Switching Basics]]
* [[Routing Basics]]
* [[Network Management Basics]]
* [[Open System Interconnection Protocols]]

==LAN Technologies ==
A LAN is a high-speed data network that covers a relatively small geographic area. It typically connects workstations, personal computers, printers, servers, and other devices. LANs offer computer users many advantages, including shared access to devices and applications, file exchange between connected users, and communication between users via electronic mail and other applications.

The following articles provide information different LAN technologies:
* [[Ethernet Technologies]]
* [[Token Ring/IEEE 802.5]]

==WAN Technologies==
A WAN is a data communications network that covers a relatively broad geographic area and that often uses transmission facilities provided by common carriers, such as telephone companies. WAN technologies generally function at the lower three layers of the OSI reference model: the physical layer, the data link layer, and the network layer.

The following articles provide information about the various protocols and technologies used in WAN environments:
* [[Frame Relay]]
* [[High-Speed Serial Interface]]
* [[Integrated Services Digital Network]]
* [[Point-to-Point Protocol]]
* [[Switched Multimegabit Data Service]]
* [[Synchronous Data Link Control and Derivatives]]
* [[X.25]]
* [[Digital Subscriber Line]]

==Internet Protocols==
The Internet protocols are the world's most popular open-system (nonproprietary) protocol suite because they can be used to communicate across any set of interconnected networks and are equally well suited for LAN and WAN communications. The Internet protocols consist of a suite of communication protocols, of which the two best known are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). The Internet protocol suite not only includes lower-layer protocols (such as TCP and IP), but it also specifies common applications such as electronic mail, terminal emulation, and file transfer. This article provides a broad introduction to specifications that comprise the Internet protocols. Discussions include IP addressing and key upper-layer protocols used in the Internet. Specific routing protocols are addressed individually later in this document.

The following articles provide information about different IOS IP technologies:
* [[Internet Protocols]]
** [[AppleTalk]]
** [[Banyan VINES]]
** [[IBM Systems Network Architecture Protocols]]
** [[DECnet]]
** [[Simple Multicast Routing Protocol]]
* [[Internet Protocol Multicast]]
* [[IPv6]]

== Bridging and Switching==
Bridges and switches are data communication devices that operate principally at Layer 2 of the OSI reference model. As such, they are widely referred to as data link layer devices.
Several kinds of bridging have proven important as internetworking devices. Transparent bridging is found primarily in Ethernet environments, while source-route bridging occurs primarily in Token Ring environments. Translational bridging provides translation between the formats and transit principles of different media types (usually Ethernet and Token Ring). Finally, source-route transparent bridging combines the algorithms of transparent bridging and source-route bridging to enable communication in mixed Ethernet/Token Ring environments.
Today, switching technology has emerged as the evolutionary heir to bridging-based internetworking solutions. Switching implementations now dominate applications in which bridging technologies were implemented in prior network designs. Superior throughput performance, higher port density, lower per-port cost, and greater flexibility have contributed to the emergence of switches as replacement technology for bridges and as complements to routing technology.

The following articles provide information about the technologies employed in devices loosely referred to as bridges and switches:
* [[Transparent Bridging]]
* [[Mixed-Media Bridging]]
* [[Source-Route Bridging]]
* [[Asynchronous Transfer Mode Switching]]
* [[LAN Switching and VLANs]]
* [[MPLS/Tag Switching]]
* [[Data-Link Switching]]
* [[Tag Switching]]

==Routing==
Routing is the act of moving information across an internetwork from a source to a destination. Along the way, at least one intermediate node typically is encountered. Routing is often contrasted with bridging, which might seem to accomplish precisely the same thing to the casual observer. The primary difference between the two is that bridging occurs at Layer 2 (the link layer) of the OSI reference model, whereas routing occurs at Layer 3 (the network layer). This distinction provides routing and bridging with different information to use in the process of moving information from source to destination, so the two functions accomplish their tasks in different ways.

The following articles provide information different routing technologies:
* [[Fiber Distributed Data Interface]]
* [[IBM Systems Network Architecture Routing]]
* [[NetWare Link-Services Protocol]]
* [[Open System Interconnection Routing Protocol]]
* [[Open Shortest Path First]]
* [[Routing Information Protocol]]
* [[Border Gateway Protocol]]
* [[Interior Gateway Routing Protocol]]
* [[Enhanced Interior Gateway Routing Protocol]]
* [[Xerox Network Systems]]

==Network Management==
Network management means different things to different people. In some cases, it involves a solitary network consultant monitoring network activity with an outdated protocol analyzer. In other cases, network management involves a distributed database, auto polling of network devices, and high-end workstations generating real-time graphical views of network topology changes and traffic. In general, network management is a service that employs a variety of tools, applications, and devices to assist human network managers in monitoring and maintaining networks.

The following articles provide information different network management technologies:
* [[Virtual Private Networks]]
* [[Directory-Enabled Networking]]
* [[Remote Monitoring]]
* [[Simple Network Management Protocol]]

== Voice/Data Integration Technologies==
Voice/data integration is important to network designers of both service providers and enterprise. Service providers are attracted by the lower-cost model-the cost of packet voice is currently estimated to be only 20 to 50 percent of the cost of a traditional circuit-based voice network. Likewise, enterprise network designers are interested in direct cost savings associated with toll-bypass and tandem switching. Both are also interested in so-called "soft savings" associated with reduced maintenance costs and more efficient network control and management. Finally, packet-based voice systems offer access to newly enhanced services such as Unified Messaging and application control. These, in turn, promise to increase the productivity of users and differentiate services.

Integration of voice and data technologies has accelerated rapidly in recent years because of both supply- and demand-side interactions. On the demand side, customers are leveraging investment in network infrastructure to take advantage of integrated applications such as voice applications. On the supply side, vendors have been able to take advantage of breakthroughs in many areas, including standards, technology, and network performance.

The following article provides information about Voice/Data Integration Technologies:
* [[Voice/Data Integration Technologies]]

== Wireless Technologies==
Wireless communication is the transfer of information over a distance without the use of electrical conductors or "wires".[1] The distances involved may be short (a few meters as in television remote control) or long (thousands or millions of kilometers for radio communications). When the context is clear, the term is often shortened to "wireless". Wireless communication is generally considered to be a branch of telecommunications.

It encompasses various types of fixed, mobile, and portable two way radios, cellular telephones, personal digital assistants (PDAs), and wireless networking. Other examples of wireless technology include GPS units, garage door openers and or garage doors, wireless computer mice, keyboards and headsets, satellite television and cordless telephones.

The following article provides information about Wireless Technologies:
* [[Wireless Technologies]]

== Cable Access Technologies==
Historically, CATV has been a unidirectional medium designed to carry broadcast analog video channels to the maximum number of customers at the lowest possible cost. CATV was introduced in the 1940s and 1950s and for many decades little changed beyond increasing the number of channels supported. The technology to provide high-margin, two-way services remained elusive to the operator.

The 2000s and the rise of IPTV saw this delivery model change. Today CATV providers utilize IP protocols for two-way data traffic while simultaneously delivering interactive video programing.

The following article provides information about Cable Access Technologies:
* [[Cable Access Technologies]]

== Dial-up Technology==
Dialup is simply the application of the Public Switched Telephone Network (PSTN) to carry data on behalf of the end user. It involves customer premises equipment (CPE) device sending the telephone switch a phone number to direct a connection to. The AS3600, AS5200, AS5300, and AS5800 are all examples of routers that have the capability to run a PRI along with banks of digital modems. The AS2511, on the other hand, is an example of a router that communicates with external modems.

Since the time of Internetworking Technologies Handbook, 2nd edition, the carrier market has continued to grow, and there have been demands for higher modem densities. The answer to this need was a higher degree of interoperation with the telco equipment and the refinement of the digital modem: a modem capable of direct digital access to the PSTN. This has allowed the development of faster CPE modems that take advantage of the clarity of signal that the digital modems enjoy. The fact that the digital modems connecting into the PSTN through a PRI or a BRI can transmit data at more than 53 K using the V.90 communication standard attests to the success of the idea.

The following article provides information about Dial-up Technology:
* [[Dial-up Technology]]

== Security Technologies==
With the rapid growth of interest in the Internet, network security has become a major concern to companies throughout the world. The fact that the information and tools needed to penetrate the security of corporate networks are widely available has increased that concern.

Because of this increased focus on network security, network administrators often spend more effort protecting their networks than on actual network setup and administration. Tools that probe for system vulnerabilities, such as the Security Administrator Tool for Analyzing Networks (SATAN), and some of the newly available scanning and intrusion detection packages and appliances, assist in these efforts, but these tools only point out areas of weakness and may not provide a means to protect networks from all possible attacks. Thus, as a network administrator, you must constantly try to keep abreast of the large number of security issues confronting you in today's world. This article describes many of the security issues that arise when connecting a private network to the Internet.

The following article provides information about Security Technologies:
* [[Security Technologies]]

== Quality of Service Networking==
Quality of Service (QoS) refers to the capability of a network to provide better service to selected network traffic over various technologies, including Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies. The primary goal of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency (required by some real-time and interactive traffic), and improved loss characteristics. Also important is making sure that providing priority for one or more flows does not make other flows fail. QoS technologies provide the elemental building blocks that will be used for future business applications in campus, WAN, and service provider networks. This article outlines the features and benefits of the QoS provided by the Cisco IOS QoS.

The following articles provide information about Quality of Service:
* [[Quality of Service Networking]]
* [[Resource Reservation Protocol]]

== Network Caching Technologies==
Although the volume of Web traffic on the Internet is staggering, a large percentage of that traffic is redundant-multiple users at any given site request much of the same content. This means that a significant percentage of the WAN infrastructure carries the identical content (and identical requests for it) day after day. Eliminating a significant amount of recurring telecommunications charges offers an enormous savings opportunity for enterprise and service provider customers.

Web caching performs the local storage of Web content to serve these redundant user requests more quickly, without sending the requests and the resulting content over the WAN.

The following article provides information about Network Caching Technologies:
* [[Network Caching Technologies]]

== IBM Network Management==
IBM network management refers to any architecture used to manage IBM Systems Network Architecture (SNA) networks or Advanced Peer-to-Peer Networking (APPN) networks. IBM network management is part of the IBM Open-Network Architecture (ONA) and is performed centrally by using management platforms such as NetView and others. It is divided into five functions that are similar to the network management functions specified under the Open System Interconnection (OSI) model. This article summarizes the IBM network management functional areas, ONA network management architecture, and management platforms.

The following article provides information about IBM Network Management:
* [[IBM Network Management]]

== Multiservice Access Technologies==
Multiservice networking is emerging as a strategically important issue for enterprise and public service provider infrastructures alike. The proposition of multiservice networking is the combination of all types of communications, all types of data, voice, and video over a single packet-cell-based infrastructure. The benefits of multiservice networking are reduced operational costs, higher performance, greater flexibility, integration and control, and faster new application and service deployment.

The following article provides information about Multiservice Access Technologies:
* [[Multiservice Access Technologies]]

[[Category:IOS Technology Handbook]]

Internetwork Design Guide

2012-10-16T21:39:32Z

Pzimmerm:

{{Template:Required Metadata}}
<meta name="keywords" content="network design, network planning, internetworking, design"></meta>

{| align="center" border="1"
|align="left"|Welcome to '''Cisco DocWiki'''. We encourage [http://tools.cisco.com/RPF/register/register.do registered Cisco.com users] to contribute to this wiki to improve Cisco product documentation. Note that you cannot log in to DocWiki with Cisco.com "guest" account credentials. 
See [[DocWiki:Terms_of_use|Terms of Use]] and [[DocWiki:About|About DocWiki]] for more information about Cisco DocWiki. 
Select the "edit" tab to edit an article or select the "leave a comment" tab to submit questions or comments about the article. 

Click [http://www.cisco.com/en/US/products/ps6441/tsd_products_support_series_home.html here] to return to the Cisco IOS documentation on www.cisco.com.
|}

This article provides internetworking design and implementation information and helps you identify and implement practical internetworking strategies that are both flexible and scalable.

This article was developed to assist professionals preparing for Cisco Certified Internetwork Expert (CCIE) candidacy, though it is a valuable resource for all internetworking professionals. It is designed for use in conjunction with other Cisco manuals or as a standalone reference. You may find it helpful to refer to the Internetworking Case Studies, which provides case studies and examples of the network design strategies described in this article.

==Internetworking Design Basics==
Internetworking-the communication between two or more networks-encompasses every aspect of connecting computers together. Internetworks have grown to support vastly disparate end-system communication requirements. An internetwork requires many protocols and features to permit scalability and manageability without constant manual intervention. Large internetworks can consist of the following three distinct components:
* Campus networks, which consist of locally connected users in a building or group of buildings
* Wide-area networks (WANs), which connect campuses together
* Remote connections, which link branch offices and single users (mobile users and/or telecommuters) to a local campus or the Internet

The following articles provide information about internetworking design basics:
* [[Internetwork Design Guide -- Introduction#Introduction|Introduction]]
* [[Internetwork Design Guide -- Internetworking Design Basics#Internetworking Design Basics|Internetworking Design Basics]]

==Designing various internetworks==
Designing an internetwork can be a challenging task. An internetwork that consists of only 50 meshed routing nodes can pose complex problems that lead to unpredictable results. Attempting to optimize internetworks that feature thousands of nodes can pose even more complex problems.

Despite improvements in equipment performance and media capabilities, internetwork design is becoming more difficult. The trend is toward increasingly complex environments involving multiple media, multiple protocols, and interconnection to networks outside any single organization's dominion of control. Carefully designing internetworks can reduce the hardships associated with growth as a networking environment evolves.

The following articles provide information about designing various internetworks:
* [[Internetwork Design Guide -- Designing Large-Scale IP Internetworks#Designing Large-Scale IP Internetworks|Designing Large-Scale IP Internetworks]]
* [[Internetwork Design Guide -- Designing SRB Internetworks#Designing SRB Internetworks|Designing SRB Internetworks]]
* [[Internetwork Design Guide -- Designing SDLC, SDLLC, and QLLC Internetworks#Designing SDLC, SDLLC, and QLLC Internetworks|Designing SDLC, SDLLC, and QLLC Internetworks]]
* [[Internetwork Design Guide -- Designing APPN Internetworks#Designing APPN Internetworks|Designing APPN Internetworks]]
* [[Internetwork Design Guide -- Designing DLSw+ Internetworks#Designing DLSw+ Internetworks|Designing DLSw+ Internetworks]]
* [[Internetwork Design Guide -- Designing ATM Internetworks#Designing ATM Internetworks|Designing ATM Internetworks]]
* [[Internetwork Design Guide -- Designing Packet Service Internetworks#Designing Packet Service Internetworks|Designing Packet Service Internetworks]]
* [[Internetwork Design Guide -- Designing DDR Internetworks#Designing DDR Internetworks|Designing DDR Internetworks]]
* [[Internetwork Design Guide -- Designing ISDN Internetworks#Designing ISDN Internetworks|Designing ISDN Internetworks]]
* [[Internetwork Design Guide -- Designing Switched LAN Internetworks#Designing Switched LAN Internetworks|Designing Switched LAN Internetworks]]
* [[Internetwork Design Guide -- Designing Internetworks for Multimedia#Designing Internetworks for Multimedia|Designing Internetworks for Multimedia]]

==Network Enhancements==
In network management, functions such as security, monitoring, control, allocation, deployment, coordination and planning are executed. Network management is governed by a large number of protocols that exist for its support, including SNMP, CMIP, WBEM, Common Information Model, Java Management Extensions, Transaction Language 1, and Netconf.

The following articles provide information about enhancing a network:
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Increasing Security on IP Networks|Increasing Security on IP Networks]]
* [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Integrating Enhanced IGRP into Existing Networks|Integrating Enhanced IGRP into Existing Networks]]
* [[Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks#Reducing SAP Traffic in Novell IPX Networks|Reducing SAP Traffic in Novell IPX Networks]]
* [[Internetwork Design Guide -- STUN for Front-End Processors#STUN for Front-End Processors|STUN for Front-End Processors]]
* [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Multicasting in IP and AppleTalk Networks|Multicasting in IP and AppleTalk Networks]]
* [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Using ISDN Effectively in Multiprotocol Networks|Using ISDN Effectively in Multiprotocol Networks]]
* [[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Broadcasts in Switched LAN Internetworks|Broadcasts in Switched LAN Internetworks]]
* [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#SNA Host Configuration for SRB Networks|SNA Host Configuration for SRB Networks]]
* [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#SNA Host Configuration for SDLC Networks|SNA Host Configuration for SDLC Networks]]

==IP Routing Concepts==
IP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to travel across multiple networks from its source to its destination. Data is routed from its source to its destination through a series of routers, and across multiple networks. The IP Routing protocols enable routers to build up a forwarding table that correlates final destinations with next hop addresses.

Following articles provide information about diferrent IP routing concepts:
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#RIP and OSPF Redistribution|RIP and OSPF Redistribution]]
* [[Internetwork Design Guide -- Dial-on-Demand Routing#Dial-on-Demand Routing|Dial-on-Demand Routing]]
* [[Internetwork Design Guide -- Scaling Dial-on-Demand Routing#Scaling Dial-on-Demand Routing|Scaling Dial-on-Demand Routing]]
* [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Using HSRP for Fault-Tolerant IP Routing|Using HSRP for Fault-Tolerant IP Routing]]

==UDP Broadcast Flooding==
A broadcast is a data packet that is destined for multiple hosts. Broadcasts can occur at the data link layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical network. Network layer broadcasts are sent to all hosts attached to a particular logical network. The Transmission Control Protocol/Internet Protocol (TCP/IP) supports the following types of broadcast packets:
* All ones-By setting the broadcast address to all ones (255.255.255.255), all hosts on the network receive the broadcast.
* Network-By setting the broadcast address to a specific network number in the network portion of the IP address and setting all ones in the host portion of the broadcast address, all hosts on the specified network receive the broadcast. For example, when a broadcast packet is sent with the broadcast address of 131.108.255.255, all hosts on network number 131.108 receive the broadcast.
* Subnet-By setting the broadcast address to a specific network number and a specific subnet number, all hosts on the specified subnet receive the broadcast. For example, when a broadcast packet is set with the broadcast address of 131.108.4.255, all hosts on subnet 4 of network 131.108 receive the broadcast.

The following article provides information about UDP Broadcast Flooding:
* [[Internetwork Design Guide -- UDP Broadcast Flooding#UDP Broadcast Flooding|UDP Broadcast Flooding]]

==Large-Scale H.323 Network Design for Service Providers==
In today's highly competitive communications industry, service providers must find new ways to increase revenue and leverage their existing network infrastructure. Many service providers have already deployed networks consisting of Cisco solutions to provide data services to their subscribers. For them, packet telephony is a readily deployable, value-added, revenue-generating application that leverages the Cisco technology's data-handling capabilities.

The following article provides information about Large-Scale H.323 Network Design for Service Providers:
* [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]]

==LAN Switching==
Today's local-area networks (LANs) are becoming increasingly congested and overburdened. In addition to an ever-growing population of network users, several factors have combined to stress the capabilities of traditional LANs:
* Faster CPUs-In the mid-1980s, the most common desktop workstation was a PC. At the time, most PCs could execute 1 million instructions per second (MIPS). Today, workstations with 50 to 75 MIPS of processing power are common, and I/O speeds have increased accordingly. Two modern engineering workstations on the same LAN can easily saturate it.
* Faster operating systems-Until recently, operating system design had constrained network access. Of the three most common desktop operating systems (DOS/Windows, the UNIX operating system, and the Mac OS), only the UNIX operating system could multitask. Multitasking allows users to initiate simultaneous network transactions. With the release of Windows 95, which reflected a redesign of DOS/Windows that included multitasking, PC users could increase their demands for network resources.
* Network-intensive applications-Use of client-server applications, such as Network File System (NFS), LAN Manager, NetWare, and World Wide Web is increasing. Client-server applications allow administrators to centralize information, thus making it easy to maintain and protect. Client-server applications free users from the burden of maintaining information and the cost of providing enough hard disk space to store it. Given the cost benefit of client-server applications, such applications are likely to become even more widely used in the future.

The following article provides information about LAN Switching:
* [[Internetwork Design Guide -- LAN Switching#LAN Switching|LAN Switching]]

==Subnetting an IP Address Space==
The following article provides a partial listing of a Class B area intended to be divided into approximately 500 Open Shortest Path First (OSPF) areas. For the purposes of this example, the network is assumed to be a Class B network with the address 150.100.0.0:
* [[Internetwork Design Guide -- Subnetting an IP Address Space#Subnetting an IP Address Space|Subnetting an IP Address Space]]

==IBM Serial Link Implementation Notes==
Half-duplex and full-duplex serial links can often be confusing. One reason for the confusion is that there are several different contexts in which these two terms are used. These contexts include asynchronous line implementations, IBM Systems Network Architecture (SNA)-specific implementations, and data communications equipment (DCE) implementations.

The following article clarify some common misconceptions and points of confusion associated with half-duplex, full-duplex, and multipoint connections:
* [[Internetwork Design Guide -- IBM Serial Link Implementation Notes#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]]

==References and Recommended Reading==
The following article provides a list of reference books for further reading on internetworking design:
* [[Internetwork Design Guide -- References and Recommended Reading#References and Recommended Reading|References and Recommended Reading]]

[[Category: Internetwork Design]]

Internetwork Design Guide -- References and Recommended Reading

2012-10-16T21:38:49Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="network design, design concepts, planning, internetworking"></meta>

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Books and Periodicals ==
Apple Computer, Inc. ''AppleTalk Network System Overview. ''Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1989.

Apple Computer, Inc. ''Planning and Managing AppleTalk Networks.'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1991.

Black, U. ''Data Networks: Concepts, Theory and Practice. ''Englewood Cliffs, New Jersey: Prentice Hall; 1989.

Black, U.'' Physical Level Interfaces and Protocols.'' Los Alamitos, California: IEEE Computer Society Press; 1988.

Case, J.D., J.R. Davins, M.S. Fedor, and M.L. Schoffstall. "Network Management and the Design of SNMP."'' ConneXions: The Interoperability Report,'' Vol. 3: March 1989.

Case, J.D., J.R. Davins, M.S. Fedor, and M.L. Schoffstall. "Introduction to the Simple Gateway Monitoring Protocol." ''IEEE Network:'' March 1988.

Clark, W. "SNA Internetworking." ''ConneXions: The Interoperability Report,'' Vol. 6, No. 3: March 1992.

Coltun, R. "OSPF: An Internet Routing Protocol." ''ConneXions: The Interoperability Report,'' Vol. 3, No. 8: August 1989.

Comer, D.E.'' Internetworking with TCP/IP: Principles, Protocols, and Architecture, ''Vol. I, 2nd ed. Englewood Cliffs, New Jersey: Prentice Hall; 1991.

Davidson, J. ''An Introduction to TCP/IP.'' New York, New York: Springer-Verlag; 1992.

Ferrari, D.'' Computer Systems Performance Evaluation.'' Englewood Cliffs, New Jersey: Prentice Hall; 1978.

Garcia-Luna-Aceves, J.J. "Loop-Free Routing Using Diffusing Computations."'' IEEE/ACM Transactions on Networking, ''Vol. 1, No. 1, 1993.

Green, J.K. ''Telecommunications,'' 2nd ed. Homewood, Illinois: Business One Irwin; 1992.

Hagans, R. "Components of OSI: ES-IS Routing."'' ConneXions: The Interoperability Report,'' Vol. 3, No. 8: August 1989.

Hares, S. "Components of OSI: Inter-Domain Routing Protocol (IDRP)."'' ConneXions: The Interoperability Report,'' Vol. 6, No. 5: May 1992.

Jones, N.E.H. and D. Kosiur.'' Macworld Networking Handbook. ''San Mateo, California: IDG Books Worldwide, Inc.; 1992.

Joyce, S.T. and J.Q. Walker II. "Advanced Peer-to-Peer Networking (APPN): An Overview." ''ConneXions: The Interoperability Report, ''Vol. 6, No. 10: October 1992.

Kousky, K. "Bridging the Network Gap." ''LAN Technology,'' Vol. 6, No. 1: January 1990.

LaQuey, Tracy. ''The Internet Companion: A Beginner's Guide to Global Networking,'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1994.

Leinwand, A. and K. Fang. ''Network Management: A Practical Perspective.'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1993.

Lippis, N. "The Internetwork Decade." ''Data Communications,'' Vol. 20, No. 14: October 1991.

McNamara, J.E. ''Local Area Networks.'' Digital Press, Educational Services, Digital Equipment Corporation, 12 Crosby Drive, Bedford, MA 01730.

Malamud, C.'' Analyzing DECnet/OSI Phase ''V. New York, New York: Van Nostrand Reinhold; 1991.

Malamud, C.'' Analyzing Novell Networks.'' New York, New York: Van Nostrand Reinhold; 1991.

Malamud, C. ''Analyzing Sun Networks.'' New York, New York: Van Nostrand Reinhold; 1991.

Martin, J. ''SNA: IBM's Networking Solution.'' Englewood Cliffs, New Jersey: Prentice Hall; 1987.

Martin, J., with K.K. Chapman and the ARBEN Group, Inc. ''Local Area Networks. Architectures and Implementations. ''Englewood Cliffs, New Jersey: Prentice Hall; 1989.

Medin, M. "The Great IGP Debate-Part Two: The Open Shortest Path First (OSPF) Routing Protocol." ''ConneXions: The Interoperability Report, ''Vol. 5, No. 10: October 1991.

Meijer, A. ''Systems Network Architecture: A tutorial. ''New York, New York: John Wiley & Sons, Inc.; 1987.

Miller, M.A. ''LAN Protocol Handbook. ''San Mateo, California: M&T Books; 1990.

Miller, M.A. ''LAN Troubleshooting Handbook.'' San Mateo, California: M&T Books; 1989.

O'Reilly, T. and G. Todino.'' Managing UUCP and Usenet, ''10th ed. Sebastopol, California: O'Reilly & Associates, Inc.; 1992.

Perlman, R.'' Interconnections: Bridges and Routers.'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1992.

Perlman, R. and R. Callon. "The Great IGP Debate-Part One: IS-IS and Integrated Routing." ''ConneXions: The Interoperability Report, ''Vol. 5, No. 10: October 1991.

Rose, M.T. ''The Open Book: A Practical Perspective on OSI. ''Englewood Cliffs, New Jersey: Prentice Hall; 1990.

Rose, M.T. ''The Simple Book: An Introduction to Management of TCP/IP-based Internets.'' Englewood Cliffs, New Jersey: Prentice Hall; 1991.

Ross, F.E. "FDDI-A Tutorial." ''IEEE Communications Magazine,'' Vol. 24, No. 5: May 1986.

Schlar, S.K. ''Inside X.25: A Manager's Guide. ''New York, New York: McGraw-Hill, Inc.; 1990.

Schwartz, M.'' Telecommunications Networks: Protocols, Modeling, and Analysis.'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1987.

Sherman, K. ''Data Communications: A User's Guide. ''Englewood Cliffs, New Jersey: Prentice Hall; 1990.

Sidhu, G.S., R.F. Andrews, and A.B. Oppenheimer. ''Inside AppleTalk, ''2nd ed. Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1990.

Spragins, J.D. et al. ''Telecommunications Protocols and Design.'' Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1991.

Stallings, W.'' Data and Computer Communications.'' New York, New York: Macmillan Publishing Company; 1991.

Stallings, W. ''Handbook of Computer-Communications Standards,'' Vols. 1-3. Carmel, Indiana: Howard W. Sams, Inc.; 1990.

Stallings, W.'' Local Networks,'' 3rd ed. New York, New York: Macmillan Publishing Company; 1990.

Sunshine, C.A. (ed.).'' Computer Network Architectures and Protocols,'' 2nd ed. New York, New York: Plenum Press; 1989.

Tannenbaum, A.S. ''Computer Networks,'' 2nd ed. Englewood Cliffs, New Jersey: Prentice Hall; 1988.

Terplan, K. ''Communication Networks Management.'' Englewood Cliffs, New Jersey: Prentice Hall; 1992.

Tsuchiya, P. "Components of OSI: IS-IS Intra-Domain Routing." ''ConneXions: The Interoperability Report,'' Vol. 3, No. 8: August 1989.

Tsuchiya, P. "Components of OSI: Routing (An Overview)."'' ConneXions: The Interoperability Report,'' Vol. 3, No. 8: August 1989.

Zimmerman, H. "OSI Reference Model-The ISO Model of Architecture for Open Systems Interconnection." ''IEEE Transactions on Communications ''COM-28, No. 4: April 1980.
== Technical Publications and Standards ==
Advanced Micro Devices. ''The Supernet Family for FDDI. ''Technical Manual Number 09779A. Sunnyvale, California; 1989.

---''The Supernet Family for FDDI.'' 1989 Data Book Number 09734C. Sunnyvale, California; 1989.

American National Standards Institute X3T9.5 Committee. ''FDDI Station Management (SMT)''. Rev. 6.1; March 15, 1990.

---. Revised Text of ISO/DIS 8802/2 for the Second DIS Ballot, "Information Processing Systems-Local Area Networks." Part 2: Logical Link Control. 1987-01-14.

--- T1.606. Integrated Services Digital Network (ISDN)-Architectural Framework and Service Description for Frame-Relaying Bearer Service. 1990.

--- T1.617. Integrated Services Digital Network (ISDN)-Signaling Specification for Frame Relay Bearer Service for Digital Subscriber Signaling System Number 1 (DSS1). 1991.

--- T1.618. Integrated Services Digital Network (ISDN)-Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service. 1991.

ATM Data Exchange Interface (DXI) Specification, Version 1.0. Document ATM_FORUM/93-590R1; August 4,1993.

Banyan Systems, Inc. ''VINES Protocol Definition. ''DA254-00, Rev. 1.0. Westboro, Massachusetts; February 1990.

Bellcore.'' Generic System Requirements in Support of a Switched Multi-Megabit Data Service.'' Technical Advisory, TA-TSY-000772; October 1989.

---. Local Access System Generic Requirements, Objectives, and Interface Support of Switched Multi-Megabit Data Service. Technical Advisory TA-TSY-000773, Issue 1; December 1985.

---. ''Switched Multi-Megabit Data Service (SMDS) Operations Technology Network Element Generic Requirements.'' Technical Advisory TA-TSY-000774.

Chapman, J.T. and M. Halabi.'' HSSI: High-Speed Serial Interface Design Specification.'' Menlo Park, California and Santa Clara, California: Cisco Systems and T3Plus Networking, Inc.; 1990.

Consultative Committee for International Telegraph and Telephone. ''CCITT Data Communications Networks-Services and Facilities, Terminal Equipment and Interfaces, Recommendations X.1-X.29.'' Yellow Book, Vol. VIII, Fascicle VIII.2; 1980.

---. ''CCITT Data Communications Networks-Interfaces, Recommendations X.20-X.32.'' Red Book, Vol. VIII, Fascicle VIII.3; 1984.

''DDN Protocol Handbook. ''Four volumes; 1989.

Defense Communications Agency. ''Defense Data Network X.25 Host Interface Specification.'' Order number AD A137 427; December 1983.

Digital Equipment Corporation. ''DECnet/OSI Phase V: Making the Transition from Phase IV.'' EK-PVTRN-BR; 1989.

---. ''DECserver 200 Local Area Transport (LAT) Network Concepts. ''AA-LD84A-TK; June 1988.

---. ''DIGITAL Network Architecture (Phase V).'' EK-DNAPV-GD-001; September 1987.

Digital Equipment Corporation, Intel Corporation, Xerox Corporation. ''The Ethernet, A Local-Area Network, Data Link Layer and Physical Layer Specifications.'' Ver. 2.0; November 1982.

Feinler, E.J., et al. ''DDN Protocol Handbook,'' Vols. 1-4, NIC 50004, 50005, 50006, 50007. Defense Communications Agency. Alexandria, Virginia; December 1985.

Garcia-Luna-Aceves, J.J. "A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States." ACM 089791-332-9/89/0009/0212, pp. 212-223; September 1989.

Hemrick, C. and L. Lang. "Introduction to Switched Multi-megabit Data Service (SMDS), an Early Broadband Service." ''Proceedings of the XIII International Switching Symposium'' (ISS 90), May 27-June 1, 1990.

''Hewlett-Packard Company. X.25: The PSN Connection; An Explanation of Recommendation X.25. 5958-3402; October 1985.''

IEEE 802.2-''Local Area Networks Standard, 802.2 Logical Link Control. ''ANSI/IEEE Standard; October 1985.

IEEE 802.3-''Local Area Networks Standard, 802.3 Carrier Sense Multiple Access. ''ANSI/IEEE Standard; October 1985.

IEEE 802.5-''Local Area Networks Standard, 802.5 Token Ring Access Method.'' ANSI/IEEE Standard; October 1985.

IEEE 802.6-''Local & Metropolitan Area Networks Standard, 802.6 Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN).'' ANSI/IEEE Standard; December 1990.

''International Business Machines Corporation. ACF/NCP/VS network control program, system support programs: general information. GC30-3058.''

---. ''Advanced Communications Function for VTAM (ACF/VTAM), general information: introduction. GS27-0462.''

---. ''Advanced Communications Function for VTAM, general information: concepts. GS27-0463.''

---. ''Dictionary of Computing''. SC20-1699-7; 1987.

---. ''Local Area Network Technical Reference.'' SC30-3883.

---. ''Network Problem Determination Application: general information.'' GC34-2010.

---. ''Synchronous Data Link Control: general information.'' GA27-3093.

---. ''Systems Network Architecture: concepts and products.'' GC30-3072.

---. ''Systems Network Architecture: technical overview.'' GC30-3073-1; 1985.

---. ''Token-Ring Network Architecture Reference.'' SC30-3374.

---. ''Token-Ring Problem Determination Guide.'' SX27-3710-04; 1990.

International Organization for Standardization ''Information Processing System-Open System Interconnection; Specification of Abstract Syntax Notation One (ASN.1).'' International Standard 8824; December 1987.

McGraw-Hill/Data Communications. ''McGraw-Hill's Compilation of Data Communications Standards. ''Edition III; 1986.

National Security Agency. ''Blacker Interface Control Document.'' March 21, 1989.

Novell, Inc. IPX Router Specification, Version 1.10. Part Number 107-000029-001. October 16, 1992.

---. NetWare Link Services Protocol (NLSP) Specification, Revision 0.9. Part Number 100-001708-001. March 1993.

StrataCom. ''Frame Relay Specification with Extensions.'' 001-208966, Rev.1.0; September 18, 1990.

Xerox Corporation.'' Internet Transport Protocols. ''XNSS 029101; January 1991.

[[Category: Internetwork Design]]

Internetwork Design Guide -- IBM Serial Link Implementation Notes

2012-10-16T21:37:57Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="ibm serial link, internetworking"></meta>

The following discussions clarify some common misconceptions and points of confusion associated with half-duplex, full-duplex, and multipoint connections.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Comparing Half Duplex and Full Duplex ==
Half-duplex and full-duplex serial links can often be confusing. One reason for the confusion is that there are several different contexts in which these two terms are used. These contexts include asynchronous line implementations, IBM Systems Network Architecture (SNA)-specific implementations, and data communications equipment (DCE) implementations. Each is addressed in the discussions that follow.
=== Asynchronous Line Definitions ===
Duplex, as seen on asynchronous communication lines (and in terminal emulation software parameters), implies full duplex as it applies to the echoing of transmitted characters by a host back to a terminal. This is also referred to as echoplex mode. In this context, half-duplex mode involves no character echo. Some common misconfigurations of terminals and hosts follow:
* Full duplex specified on a terminal when the host is set for half duplex results in typing blind at the terminal.
* Half duplex specified on a terminal when the host is set for full duplex results in double characters on the terminal. This is because the terminal displays entered characters if the terminal's configuration indicates that the host will not echo characters.

{{note|This interpretation of duplex does not apply in a router context. }}

=== IBM SNA-Specific Definitions ===
IBM's master glossary for VTAM, NCP, and NetView terms defines duplex, full duplex, and half duplex as follows:
* Duplex-In data communications, pertaining to a simultaneous two-way independent transmission in both directions; synonymous with full duplex; contrast with half duplex.
* Half duplex-In data communications, pertaining to an alternate, one-way-at-a-time, independent transmission; contrast with duplex.
* These definitions can be applied in two contexts that are the main source of duplex definition confusion:
* First, there is full-duplex and half-duplex data transfer. This typically applies to the capability or inability of data terminal equipment (DTE) to support simultaneous, two-way data flow. SNA PU 4 devices (front-end processors such as 3705, 3720, 3725, and 3745 devices) are capable of full-duplex data transfer. Each such device employs a separate data and control path into the control program's transmit and receive buffers.
* Some PU 2.1 devices are also capable of full duplex data mode, which is negotiable in the XID-3 format frame-unless the NCP PU definition statement DATMODE=FULL is specified. If FULL is specified, full-duplex mode is forced. PU 2s and PU 1s operate in half-duplex data mode.
=== DCE Definitions ===
Finally, there is full duplex and half duplex as it applies to the communication facility, or DCE. This is where most of the technological advancement has been achieved with respect to half and full duplex. DCE installations primarily consist of channel service units (CSUs), data service units (DSUs), or modem devices, and a communications line. The modem can be synchronous or asynchronous and can be analog or digital. The communications line can be two-wire or four-wire and can be leased or switched (that is, dial-up).

Older modems are capable of transmitting or receiving only at a given time. When a DTE wants to transmit data using an older modem, the DTE asserts the Request To Send (RTS) signal to the modem. If the modem is not in receive mode, the modem enables its carrier signal in preparation for transmitting data and asserts Clear To Send (CTS). If the modem is in receive mode, its Data Carrier Detect (DCD) signal (that is, the carrier signal from the remote modem) is in the active state. The modem does not activate the CTS signal, and the DTE does not transmit, because DCD is in the active state.

Contemporary modems are capable of transmitting and receiving simultaneously over two-wire or four-wire and leased or switched lines. One method uses multiple carrier signals at different frequencies, so that the local modem's transmit and receive signals, as well as the remote modem's transmit and receive signals, each have their own carrier frequency.

DTE equipment in an SDLC environment have configuration options that specify which mode of operation is supported by DCE equipment. The default parameters for most PU 2 devices are set for half duplex, although they can also support full-duplex operation. If the facility is capable of full duplex, RTS can be asserted at all times. If the facility supports half duplex or is operating in a multipoint environment using modem-sharing devices (as opposed to multipoint provided by a Postal Telephone and Telegraph [PTT] or by a telephone company), RTS must only be asserted when transmitting. A full-duplex-capable communication facility that connects a PU 4 to a PU 2 device or to a PU 1 device (with each PU device specifying full-duplex DCE capability) experiences improved response time because of reduced turnaround delays.

Older PU 2 and PU 1 devices cannot be configured for full-duplex DCE mode. Also, because older PU 2 and PU 1 devices can only support half-duplex data transfer, transmit and receive data cannot be on the line at the same time (in contrast to a PU 4-to-PU 4 full-duplex exchange).
== Understanding Multipoint Connections ==
Multipoint operation is a method of sharing a communication facility with multiple locations. The telephone company or PTT communications authorities offer two-wire and four-wire multipoint configurations for analog service (modem attachment) or four-wire for digital service (CSU/DSU attachment). Most implementations are master-polling, multiple-slave drop implementations. The master only connects to one drop at a time. The switching takes place at a designated local exchange in proximity to the master DTE site. Some service providers offer analog multipoint services that support two-way simultaneous communication, which allows DTEs to be configured for permanent RTS.

Modem-sharing devices and line-sharing devices also provide multipoint capability. These implementations allow a single point-to-point link to be shared by multiple devices. Some of these devices have configurable ports for DTE or DCE operation, which allow for configurations that can accommodate multiple sites (called cascaded configurations). The main restriction of these devices is that when RTS is active, other users are locked out. You cannot configure DTEs for permanent RTS and you must accept the turnaround delays associated with this mode of operation.

[[Category: Internetwork Design]]

Internetwork Design Guide -- Subnetting an IP Address Space

2012-10-16T21:37:21Z

Pzimmerm:

{{Template:Required Metadata}}
<meta name="keywords" content="subnet, ip address, internetworking"></meta>
This article provides a partial listing of a Class B area intended to be divided into approximately 500 Open Shortest Path First (OSPF) areas. For the purposes of this example, the network is assumed to be a Class B network with the address 150.100.0.0.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

{{note|Although a 500-area OSPF internetwork is unrealistic, using an address space like this can help to illustrate the general methodology employed to subnet an OSPF address space.}}

Only the address space for two of 512 areas is shown in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]]. These areas are defined with the base address 150.100.2.0. Illustrating the entire address space for 150.100.0.0 would require hundreds of additional pages of addressing information. Each area would require the equivalent number of entries for each of the example areas illustrated here.

[[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] illustrates the assignment of 255 IP addresses that have been split between two OSPF areas. [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] also illustrates the boundaries of the subnets and of the two OSPF areas shown (area 8 and area 17).

For the purposes of this discussion, consider a network that requires point-to-point serial links in each area to be assigned a subnet mask that allows two hosts per subnet. All other subnets are to be allowed 14 hosts per subnet. The use of bit-wise subnetting and variable-length subnet masks (VLSMs) permit you to customize your address space by facilitating the division of address spaces into smaller groupings than is allowed when subnetting along octet boundaries. The address layout shown in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] illustrates a structured approach to assigning addresses that uses VLSM. [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] presents two subnet masks: 255.255.255.240 and of 255.255.255.252. The first mask creates subnet address spaces that are four bits wide; the second mask creates subnet address spaces that are two bits wide.

Because of the careful assignment of addresses, each area can be summarized with a single '''area''' router configuration command (used to define address range). The first set of addresses starting with 150.100.2.0xxxxxxx (last octet represented here in binary) can be summarized into the backbone with the following command:

area 8 range 150.100.2.0 255.255.255.128

This command assigns all addresses from 150.100.2.0 to 150.100.2.127 to area 8. Similarly, the addresses from 150.100.2.128 to 150.100.2.255 for the second area can be summarized as follows:

area 17 range 150.100.2.128 255.255.255.128

This command assigns all addresses from 150.100.2.128 to 150.100.2.255 to area 17.

Allocation of subnets allows you to decide where to draw the line between the subnet and host (using a subnet mask) within each area. Note that in this example there are only seven bits remaining to use because of the creation of the artificial area mask. The nine bits to the left of the area mask are actually part of the subnet portion of the address. By keeping these nine bits the same for all addresses in a given area, route summarization is easily achieved at area border routers, as illustrated by the scheme used in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]].

[[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] lists individual subnets, valid IP addresses, subnet identifiers, and broadcast addresses. This method of assigning addresses for the VLSM portion of the address space guarantees that there is no address overlap. If the requirement had been different, any number of the larger subnets might be chosen and divided into smaller ranges with fewer hosts, or combined into several ranges to create subnets with more hosts.

The design approach used in this article allows the area mask boundary and subnet masks to be assigned to any point in the address space, which provides significant design flexibility. A change in the specification of the area mask boundary or subnet masks may be required if a network outgrows its initial address space design. In [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]], the area mask boundary is to the right of the most significant bit of the last octet of the address, as shown by [[Internetwork Design Guide -- Subnetting an IP Address Space#Figure: Breakdown of the addresses assigned by the example|Figure: Breakdown of the addresses assigned by the example]].

===== Figure: Breakdown of the addresses assigned by the example=====

[[image:nd20a01.jpg]]

With a subnet mask of 255.255.255.240, the a and b bits together represent the subnet portion of the address, whereas the c and d bits together provide four-bit host identifiers. When a subnet mask of 255.255.255.252 (a typical subnet mask for point-to-point serial lines), the a, b, and c bits together represent the subnet portion of the address, and the d bits provide two-bit host identifiers. As mentioned earlier, the purpose of the area mask is to keep all of the a bits constant in a given OSPF area (independent of the subnet mask) so that route summarization is easy to apply.

The following steps outline the process used to allocate addresses:
# Determine the number of areas required for your OSPF network. A value of 500 is used for this example.
# Create an artificial area mask boundary in your address space. This example uses nine bits of subnet addressing space to identify the areas uniquely. Because 29= 512, nine bits of subnet meet our requirement of 500 areas.
# Determine the number of subnets required in each area and the maximum number of hosts required per subnet. This allows you to determine the placement of the subnet mask(s). In [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]], the requirement is for seven subnets with 14 hosts each and four subnets with two hosts each.

===== Table: Partial Example of Subnet Address Assignment Using VLSM=====

{| border = 1
|-
!''' IP Address (Decimal)'''

!'''Subnet Portion of Last Octet (Binary)'''

!'''Host Portion of Last Octet (Binary)'''

! '''Subnet Number'''

! '''Subnet Mask'''

! '''Notes'''
|-
|

150.100.2.0
|

0000
|

0000
|

150.100.2.0
|

255.255.255.240
|

Subnet identifier; area boundary; area 8 starts
|-
|

150.100.2.1
|

0000
|

0001
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.2
|

0000
|

0010
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.3
|

0000
|

0011
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.4
|

0000
|

0100
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.5
|

0000
|

0101
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.6
|

0000
|

0110
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.7
|

0000
|

0111
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.8
|

0000
|

1000
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.9
|

0000
|

1001
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.10
|

0000
|

1010
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.11
|

0000
|

1011
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.12
|

0000
|

1100
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.13
|

0000
|

1101
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.14
|

0000
|

1110
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.15
|

0000
|

1111
|

150.100.2.0
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.16
|

0001
|

0000
|

150.100.2.16
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.17
|

0001
|

0001
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.18
|

0001
|

0010
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.19
|

0001
|

0011
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.20
|

0001
|

0100
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.21
|

0001
|

0101
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.22
|

0001
|

0110
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.23
|

0001
|

0111
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.24
|

0001
|

1000
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.25
|

0001
|

1001
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.26
|

0001
|

1010
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.27
|

0001
|

1011
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.28
|

0001
|

1100
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.29
|

0001
|

1101
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.30
|

0001
|

1110
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.31
|

0001
|

1111
|

150.100.2.16
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.32
|

0010
|

0000
|

150.100.2.32
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.33
|

0010
|

0001
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.34
|

0010
|

0010
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.35
|

0010
|

0011
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.36
|

0010
|

0100
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.37
|

0010
|

0101
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.38
|

0010
|

0110
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.39
|

0010
|

0111
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.40
|

0010
|

1000
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.41
|

0010
|

1001
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.42
|

0010
|

1010
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.43
|

0010
|

1011
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.44
|

0010
|

1100
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.45
|

0010
|

1101
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.46
|

0010
|

1110
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.47
|

0010
|

1111
|

150.100.2.32
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.48
|

0011
|

0000
|

150.100.2.48
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.49
|

0011
|

0001
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.50
|

0011
|

0010
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.51
|

0011
|

0011
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.52
|

0011
|

0100
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.53
|

0011
|

0101
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.54
|

0011
|

0110
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.55
|

0011
|

0111
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.56
|

0011
|

1000
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.57
|

0011
|

1001
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.58
|

0011
|

1010
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.59
|

0011
|

1011
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.60
|

0011
|

1100
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.61
|

0011
|

1101
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.62
|

0011
|

1110
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.63
|

0011
|

1111
|

150.100.2.48
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.64
|

010000
|

00
|

150.100.2.64
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.65
|

010000
|

01
|

150.100.2.64
|

255.255.255.252
|
|-
|

150.100.2.66
|

010000
|

10
|

150.100.2.64
|

255.255.255.252
|
|-
|

150.100.2.67
|

010000
|

11
|

150.100.2.64
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.68
|

010001
|

00
|

150.100.2.68
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.69
|

010001
|

01
|

150.100.2.68
|

255.255.255.252
|
|-
|

150.100.2.70
|

010001
|

10
|

150.100.2.68
|

255.255.255.252
|
|-
|

150.100.2.71
|

010001
|

11
|

150.100.2.68
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.72
|

010010
|

00
|

150.100.2.72
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.73
|

010010
|

01
|

150.100.2.72
|

255.255.255.252
|
|-
|

150.100.2.74
|

010010
|

10
|

150.100.2.72
|

255.255.255.252
|
|-
|

150.100.2.75
|

010010
|

11
|

150.100.2.72
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.76
|

010011
|

00
|

150.100.2.76
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.77
|

010011
|

01
|

150.100.2.76
|

255.255.255.252
|
|-
|

150.100.2.78
|

010011
|

10
|

150.100.2.76
|

255.255.255.252
|
|-
|

150.100.2.79
|

010011
|

11
|

150.100.2.76
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.80
|

0101
|

0000
|

150.100.2.80
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.81
|

0101
|

0001
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.82
|

0101
|

0010
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.83
|

0101
|

0011
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.84
|

0101
|

0100
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.85
|

0101
|

0101
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.86
|

0101
|

0110
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.87
|

0101
|

0111
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.88
|

0101
|

1000
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.89
|

0101
|

1001
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.90
|

0101
|

1010
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.91
|

0101
|

1011
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.92
|

0101
|

1100
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.93
|

0101
|

1101
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.94
|

0101
|

1110
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.95
|

0101
|

1111
|

150.100.2.80
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.96
|

0110
|

0000
|

150.100.2.96
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.97
|

0110
|

0001
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.98
|

0110
|

0010
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.99
|

0110
|

0011
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.100
|

0110
|

0100
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.101
|

0110
|

0101
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.102
|

0110
|

0110
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.103
|

0110
|

0111
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.104
|

0110
|

1000
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.105
|

0110
|

1001
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.106
|

0110
|

1010
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.107
|

0110
|

1011
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.108
|

0110
|

1100
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.109
|

0110
|

1101
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.110
|

0110
|

1110
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.111
|

0110
|

1111
|

150.100.2.96
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.112
|

0111
|

0000
|

150.100.2.112
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.113
|

0111
|

0001
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.114
|

0111
|

0010
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.115
|

0111
|

0011
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.116
|

0111
|

0100
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.117
|

0111
|

0101
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.118
|

0111
|

0110
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.119
|

0111
|

0111
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.120
|

0111
|

1000
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.121
|

0111
|

1001
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.122
|

0111
|

1010
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.123
|

0111
|

1011
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.124
|

0111
|

1100
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.125
|

0111
|

1101
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.126
|

0111
|

1110
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.127
|

0111
|

1111
|

150.100.2.112
|

255.255.255.240
|

Subnet broad- cast; area bound- ary; area 8 ends
|-
|

150.100.2.128
|

1000
|

0000
|

150.100.2.128
|

255.255.255.240
|

Subnet identifier; area boundary; area 17 starts
|-
|

150.100.2.129
|

1000
|

0001
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.130
|

1000
|

0010
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.131
|

1000
|

0011
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.132
|

1000
|

0100
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.133
|

1000
|

0101
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.134
|

1000
|

0110
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.135
|

1000
|

0111
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.136
|

1000
|

1000
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.137
|

1000
|

1001
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.138
|

1000
|

1010
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.139
|

1000
|

1011
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.140
|

1000
|

1100
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.141
|

1000
|

1101
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.142
|

1000
|

1110
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.143
|

1000
|

1111
|

150.100.2.128
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.144
|

1001
|

0000
|

150.100.2.144
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.145
|

1001
|

0001
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.146
|

1001
|

0010
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.147
|

1001
|

0011
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.148
|

1001
|

0100
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.149
|

1001
|

0101
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.150
|

1001
|

0110
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.151
|

1001
|

0111
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.152
|

1001
|

1000
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.153
|

1001
|

1001
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.154
|

1001
|

1010
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.155
|

1001
|

1011
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.156
|

1001
|

1100
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.157
|

1001
|

1101
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.158
|

1001
|

1110
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.159
|

1001
|

1111
|

150.100.2.144
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.160
|

1010
|

0000
|

150.100.2.160
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.161
|

1010
|

0001
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.162
|

1010
|

0010
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.163
|

1010
|

0011
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.164
|

1010
|

0100
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.165
|

1010
|

0101
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.166
|

1010
|

0110
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.167
|

1010
|

0111
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.168
|

1010
|

1000
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.169
|

1010
|

1001
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.170
|

1010
|

1010
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.171
|

1010
|

1011
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.172
|

1010
|

1100
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.173
|

1010
|

1101
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.174
|

1010
|

1110
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.175
|

1010
|

1111
|

150.100.2.160
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.176
|

101100
|

00
|

150.100.2.176
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.177
|

101100
|

01
|

150.100.2.176
|

255.255.255.252
|
|-
|

150.100.2.178
|

101100
|

10
|

150.100.2.176
|

255.255.255.252
|
|-
|

150.100.2.179
|

101100
|

11
|

150.100.2.176
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.180
|

101101
|

00
|

150.100.2.180
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.181
|

101101
|

01
|

150.100.2.180
|

255.255.255.252
|
|-
|

150.100.2.182
|

101101
|

10
|

150.100.2.180
|

255.255.255.252
|
|-
|

150.100.2.183
|

101101
|

11
|

150.100.2.180
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.184
|

101110
|

00
|

150.100.2.184
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.185
|

101110
|

01
|

150.100.2.184
|

255.255.255.252
|
|-
|

150.100.2.186
|

101110
|

10
|

150.100.2.184
|

255.255.255.252
|
|-
|

150.100.2.187
|

101110
|

11
|

150.100.2.184
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.188
|

101111
|

00
|

150.100.2.188
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.189
|

101111
|

01
|

150.100.2.188
|

255.255.255.252
|
|-
|

150.100.2.190
|

101111
|

10
|

150.100.2.188
|

255.255.255.252
|
|-
|

150.100.2.191
|

101111
|

11
|

150.100.2.188
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.192
|

1100
|

0000
|

150.100.2.192
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.193
|

1100
|

0001
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.194
|

1100
|

0010
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.195
|

1100
|

0011
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.196
|

1100
|

0100
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.197
|

1100
|

0101
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.198
|

1100
|

0110
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.199
|

1100
|

0111
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.200
|

1100
|

1000
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.201
|

1100
|

1001
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.202
|

1100
|

1010
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.203
|

1100
|

1011
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.204
|

1100
|

1100
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.205
|

1100
|

1101
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.206
|

1100
|

1110
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.207
|

1100
|

1111
|

150.100.2.192
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.208
|

1101
|

0000
|

150.100.2.208
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.209
|

1101
|

0001
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.210
|

1101
|

0010
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.211
|

1101
|

0011
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.212
|

1101
|

0100
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.213
|

1101
|

0101
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.214
|

1101
|

0110
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.215
|

1101
|

0111
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.216
|

1101
|

1000
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.217
|

1101
|

1001
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.218
|

1101
|

1010
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.219
|

1101
|

1011
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.220
|

1101
|

1100
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.221
|

1101
|

1101
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.222
|

1101
|

1110
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.223
|

1101
|

1111
|

150.100.2.208
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.224
|

1110
|

0000
|

150.100.2.224
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.225
|

1110
|

0001
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.226
|

1110
|

0010
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.227
|

1110
|

0011
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.228
|

1110
|

0100
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.229
|

1110
|

0101
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.230
|

1110
|

0110
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.231
|

1110
|

0111
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.232
|

1110
|

1000
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.233
|

1110
|

1001
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.234
|

1110
|

1010
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.235
|

1110
|

1011
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.236
|

1110
|

1100
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.237
|

1110
|

1101
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.238
|

1110
|

1110
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.239
|

1110
|

1111
|

150.100.2.224
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.240
|

1111
|

0000
|

150.100.2.240
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.241
|

1111
|

0001
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.242
|

1111
|

0010
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.243
|

1111
|

0011
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.244
|

1111
|

0100
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.245
|

1111
|

0101
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.246
|

1111
|

0110
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.247
|

1111
|

0111
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.248
|

1111
|

1000
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.249
|

1111
|

1001
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.250
|

1111
|

1010
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.251
|

1111
|

1011
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.252
|

1111
|

1100
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.253
|

1111
|

1101
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.254
|

1111
|

1110
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.255
|

1111
|

1111
|

150.100.2.240
|

255.255.255.240
|

Subnet broadcast; area boundary; area 17 ends
|}

[[Category: Internetwork Design]]

Internetwork Design Guide -- Subnetting an IP Address Space

2012-10-16T21:36:51Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="subnet, internetworking"></meta>
This article provides a partial listing of a Class B area intended to be divided into approximately 500 Open Shortest Path First (OSPF) areas. For the purposes of this example, the network is assumed to be a Class B network with the address 150.100.0.0.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

{{note|Although a 500-area OSPF internetwork is unrealistic, using an address space like this can help to illustrate the general methodology employed to subnet an OSPF address space.}}

Only the address space for two of 512 areas is shown in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]]. These areas are defined with the base address 150.100.2.0. Illustrating the entire address space for 150.100.0.0 would require hundreds of additional pages of addressing information. Each area would require the equivalent number of entries for each of the example areas illustrated here.

[[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] illustrates the assignment of 255 IP addresses that have been split between two OSPF areas. [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] also illustrates the boundaries of the subnets and of the two OSPF areas shown (area 8 and area 17).

For the purposes of this discussion, consider a network that requires point-to-point serial links in each area to be assigned a subnet mask that allows two hosts per subnet. All other subnets are to be allowed 14 hosts per subnet. The use of bit-wise subnetting and variable-length subnet masks (VLSMs) permit you to customize your address space by facilitating the division of address spaces into smaller groupings than is allowed when subnetting along octet boundaries. The address layout shown in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] illustrates a structured approach to assigning addresses that uses VLSM. [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] presents two subnet masks: 255.255.255.240 and of 255.255.255.252. The first mask creates subnet address spaces that are four bits wide; the second mask creates subnet address spaces that are two bits wide.

Because of the careful assignment of addresses, each area can be summarized with a single '''area''' router configuration command (used to define address range). The first set of addresses starting with 150.100.2.0xxxxxxx (last octet represented here in binary) can be summarized into the backbone with the following command:

area 8 range 150.100.2.0 255.255.255.128

This command assigns all addresses from 150.100.2.0 to 150.100.2.127 to area 8. Similarly, the addresses from 150.100.2.128 to 150.100.2.255 for the second area can be summarized as follows:

area 17 range 150.100.2.128 255.255.255.128

This command assigns all addresses from 150.100.2.128 to 150.100.2.255 to area 17.

Allocation of subnets allows you to decide where to draw the line between the subnet and host (using a subnet mask) within each area. Note that in this example there are only seven bits remaining to use because of the creation of the artificial area mask. The nine bits to the left of the area mask are actually part of the subnet portion of the address. By keeping these nine bits the same for all addresses in a given area, route summarization is easily achieved at area border routers, as illustrated by the scheme used in [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]].

[[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]] lists individual subnets, valid IP addresses, subnet identifiers, and broadcast addresses. This method of assigning addresses for the VLSM portion of the address space guarantees that there is no address overlap. If the requirement had been different, any number of the larger subnets might be chosen and divided into smaller ranges with fewer hosts, or combined into several ranges to create subnets with more hosts.

The design approach used in this article allows the area mask boundary and subnet masks to be assigned to any point in the address space, which provides significant design flexibility. A change in the specification of the area mask boundary or subnet masks may be required if a network outgrows its initial address space design. In [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]], the area mask boundary is to the right of the most significant bit of the last octet of the address, as shown by [[Internetwork Design Guide -- Subnetting an IP Address Space#Figure: Breakdown of the addresses assigned by the example|Figure: Breakdown of the addresses assigned by the example]].

===== Figure: Breakdown of the addresses assigned by the example=====

[[image:nd20a01.jpg]]

With a subnet mask of 255.255.255.240, the a and b bits together represent the subnet portion of the address, whereas the c and d bits together provide four-bit host identifiers. When a subnet mask of 255.255.255.252 (a typical subnet mask for point-to-point serial lines), the a, b, and c bits together represent the subnet portion of the address, and the d bits provide two-bit host identifiers. As mentioned earlier, the purpose of the area mask is to keep all of the a bits constant in a given OSPF area (independent of the subnet mask) so that route summarization is easy to apply.

The following steps outline the process used to allocate addresses:
# Determine the number of areas required for your OSPF network. A value of 500 is used for this example.
# Create an artificial area mask boundary in your address space. This example uses nine bits of subnet addressing space to identify the areas uniquely. Because 29= 512, nine bits of subnet meet our requirement of 500 areas.
# Determine the number of subnets required in each area and the maximum number of hosts required per subnet. This allows you to determine the placement of the subnet mask(s). In [[Internetwork Design Guide -- Subnetting an IP Address Space#Table: Partial Example of Subnet Address Assignment Using VLSM|Table: Partial Example of Subnet Address Assignment Using VLSM]], the requirement is for seven subnets with 14 hosts each and four subnets with two hosts each.

===== Table: Partial Example of Subnet Address Assignment Using VLSM=====

{| border = 1
|-
!''' IP Address (Decimal)'''

!'''Subnet Portion of Last Octet (Binary)'''

!'''Host Portion of Last Octet (Binary)'''

! '''Subnet Number'''

! '''Subnet Mask'''

! '''Notes'''
|-
|

150.100.2.0
|

0000
|

0000
|

150.100.2.0
|

255.255.255.240
|

Subnet identifier; area boundary; area 8 starts
|-
|

150.100.2.1
|

0000
|

0001
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.2
|

0000
|

0010
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.3
|

0000
|

0011
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.4
|

0000
|

0100
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.5
|

0000
|

0101
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.6
|

0000
|

0110
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.7
|

0000
|

0111
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.8
|

0000
|

1000
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.9
|

0000
|

1001
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.10
|

0000
|

1010
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.11
|

0000
|

1011
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.12
|

0000
|

1100
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.13
|

0000
|

1101
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.14
|

0000
|

1110
|

150.100.2.0
|

255.255.255.240
|
|-
|

150.100.2.15
|

0000
|

1111
|

150.100.2.0
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.16
|

0001
|

0000
|

150.100.2.16
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.17
|

0001
|

0001
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.18
|

0001
|

0010
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.19
|

0001
|

0011
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.20
|

0001
|

0100
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.21
|

0001
|

0101
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.22
|

0001
|

0110
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.23
|

0001
|

0111
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.24
|

0001
|

1000
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.25
|

0001
|

1001
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.26
|

0001
|

1010
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.27
|

0001
|

1011
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.28
|

0001
|

1100
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.29
|

0001
|

1101
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.30
|

0001
|

1110
|

150.100.2.16
|

255.255.255.240
|
|-
|

150.100.2.31
|

0001
|

1111
|

150.100.2.16
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.32
|

0010
|

0000
|

150.100.2.32
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.33
|

0010
|

0001
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.34
|

0010
|

0010
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.35
|

0010
|

0011
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.36
|

0010
|

0100
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.37
|

0010
|

0101
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.38
|

0010
|

0110
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.39
|

0010
|

0111
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.40
|

0010
|

1000
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.41
|

0010
|

1001
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.42
|

0010
|

1010
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.43
|

0010
|

1011
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.44
|

0010
|

1100
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.45
|

0010
|

1101
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.46
|

0010
|

1110
|

150.100.2.32
|

255.255.255.240
|
|-
|

150.100.2.47
|

0010
|

1111
|

150.100.2.32
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.48
|

0011
|

0000
|

150.100.2.48
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.49
|

0011
|

0001
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.50
|

0011
|

0010
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.51
|

0011
|

0011
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.52
|

0011
|

0100
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.53
|

0011
|

0101
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.54
|

0011
|

0110
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.55
|

0011
|

0111
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.56
|

0011
|

1000
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.57
|

0011
|

1001
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.58
|

0011
|

1010
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.59
|

0011
|

1011
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.60
|

0011
|

1100
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.61
|

0011
|

1101
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.62
|

0011
|

1110
|

150.100.2.48
|

255.255.255.240
|
|-
|

150.100.2.63
|

0011
|

1111
|

150.100.2.48
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.64
|

010000
|

00
|

150.100.2.64
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.65
|

010000
|

01
|

150.100.2.64
|

255.255.255.252
|
|-
|

150.100.2.66
|

010000
|

10
|

150.100.2.64
|

255.255.255.252
|
|-
|

150.100.2.67
|

010000
|

11
|

150.100.2.64
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.68
|

010001
|

00
|

150.100.2.68
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.69
|

010001
|

01
|

150.100.2.68
|

255.255.255.252
|
|-
|

150.100.2.70
|

010001
|

10
|

150.100.2.68
|

255.255.255.252
|
|-
|

150.100.2.71
|

010001
|

11
|

150.100.2.68
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.72
|

010010
|

00
|

150.100.2.72
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.73
|

010010
|

01
|

150.100.2.72
|

255.255.255.252
|
|-
|

150.100.2.74
|

010010
|

10
|

150.100.2.72
|

255.255.255.252
|
|-
|

150.100.2.75
|

010010
|

11
|

150.100.2.72
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.76
|

010011
|

00
|

150.100.2.76
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.77
|

010011
|

01
|

150.100.2.76
|

255.255.255.252
|
|-
|

150.100.2.78
|

010011
|

10
|

150.100.2.76
|

255.255.255.252
|
|-
|

150.100.2.79
|

010011
|

11
|

150.100.2.76
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.80
|

0101
|

0000
|

150.100.2.80
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.81
|

0101
|

0001
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.82
|

0101
|

0010
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.83
|

0101
|

0011
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.84
|

0101
|

0100
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.85
|

0101
|

0101
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.86
|

0101
|

0110
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.87
|

0101
|

0111
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.88
|

0101
|

1000
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.89
|

0101
|

1001
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.90
|

0101
|

1010
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.91
|

0101
|

1011
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.92
|

0101
|

1100
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.93
|

0101
|

1101
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.94
|

0101
|

1110
|

150.100.2.80
|

255.255.255.240
|
|-
|

150.100.2.95
|

0101
|

1111
|

150.100.2.80
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.96
|

0110
|

0000
|

150.100.2.96
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.97
|

0110
|

0001
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.98
|

0110
|

0010
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.99
|

0110
|

0011
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.100
|

0110
|

0100
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.101
|

0110
|

0101
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.102
|

0110
|

0110
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.103
|

0110
|

0111
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.104
|

0110
|

1000
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.105
|

0110
|

1001
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.106
|

0110
|

1010
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.107
|

0110
|

1011
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.108
|

0110
|

1100
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.109
|

0110
|

1101
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.110
|

0110
|

1110
|

150.100.2.96
|

255.255.255.240
|
|-
|

150.100.2.111
|

0110
|

1111
|

150.100.2.96
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.112
|

0111
|

0000
|

150.100.2.112
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.113
|

0111
|

0001
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.114
|

0111
|

0010
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.115
|

0111
|

0011
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.116
|

0111
|

0100
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.117
|

0111
|

0101
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.118
|

0111
|

0110
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.119
|

0111
|

0111
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.120
|

0111
|

1000
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.121
|

0111
|

1001
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.122
|

0111
|

1010
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.123
|

0111
|

1011
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.124
|

0111
|

1100
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.125
|

0111
|

1101
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.126
|

0111
|

1110
|

150.100.2.112
|

255.255.255.240
|
|-
|

150.100.2.127
|

0111
|

1111
|

150.100.2.112
|

255.255.255.240
|

Subnet broad- cast; area bound- ary; area 8 ends
|-
|

150.100.2.128
|

1000
|

0000
|

150.100.2.128
|

255.255.255.240
|

Subnet identifier; area boundary; area 17 starts
|-
|

150.100.2.129
|

1000
|

0001
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.130
|

1000
|

0010
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.131
|

1000
|

0011
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.132
|

1000
|

0100
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.133
|

1000
|

0101
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.134
|

1000
|

0110
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.135
|

1000
|

0111
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.136
|

1000
|

1000
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.137
|

1000
|

1001
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.138
|

1000
|

1010
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.139
|

1000
|

1011
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.140
|

1000
|

1100
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.141
|

1000
|

1101
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.142
|

1000
|

1110
|

150.100.2.128
|

255.255.255.240
|
|-
|

150.100.2.143
|

1000
|

1111
|

150.100.2.128
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.144
|

1001
|

0000
|

150.100.2.144
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.145
|

1001
|

0001
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.146
|

1001
|

0010
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.147
|

1001
|

0011
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.148
|

1001
|

0100
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.149
|

1001
|

0101
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.150
|

1001
|

0110
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.151
|

1001
|

0111
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.152
|

1001
|

1000
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.153
|

1001
|

1001
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.154
|

1001
|

1010
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.155
|

1001
|

1011
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.156
|

1001
|

1100
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.157
|

1001
|

1101
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.158
|

1001
|

1110
|

150.100.2.144
|

255.255.255.240
|
|-
|

150.100.2.159
|

1001
|

1111
|

150.100.2.144
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.160
|

1010
|

0000
|

150.100.2.160
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.161
|

1010
|

0001
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.162
|

1010
|

0010
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.163
|

1010
|

0011
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.164
|

1010
|

0100
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.165
|

1010
|

0101
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.166
|

1010
|

0110
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.167
|

1010
|

0111
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.168
|

1010
|

1000
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.169
|

1010
|

1001
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.170
|

1010
|

1010
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.171
|

1010
|

1011
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.172
|

1010
|

1100
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.173
|

1010
|

1101
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.174
|

1010
|

1110
|

150.100.2.160
|

255.255.255.240
|
|-
|

150.100.2.175
|

1010
|

1111
|

150.100.2.160
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.176
|

101100
|

00
|

150.100.2.176
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.177
|

101100
|

01
|

150.100.2.176
|

255.255.255.252
|
|-
|

150.100.2.178
|

101100
|

10
|

150.100.2.176
|

255.255.255.252
|
|-
|

150.100.2.179
|

101100
|

11
|

150.100.2.176
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.180
|

101101
|

00
|

150.100.2.180
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.181
|

101101
|

01
|

150.100.2.180
|

255.255.255.252
|
|-
|

150.100.2.182
|

101101
|

10
|

150.100.2.180
|

255.255.255.252
|
|-
|

150.100.2.183
|

101101
|

11
|

150.100.2.180
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.184
|

101110
|

00
|

150.100.2.184
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.185
|

101110
|

01
|

150.100.2.184
|

255.255.255.252
|
|-
|

150.100.2.186
|

101110
|

10
|

150.100.2.184
|

255.255.255.252
|
|-
|

150.100.2.187
|

101110
|

11
|

150.100.2.184
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.188
|

101111
|

00
|

150.100.2.188
|

255.255.255.252
|

Subnet identifier
|-
|

150.100.2.189
|

101111
|

01
|

150.100.2.188
|

255.255.255.252
|
|-
|

150.100.2.190
|

101111
|

10
|

150.100.2.188
|

255.255.255.252
|
|-
|

150.100.2.191
|

101111
|

11
|

150.100.2.188
|

255.255.255.252
|

Subnet broadcast
|-
|

150.100.2.192
|

1100
|

0000
|

150.100.2.192
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.193
|

1100
|

0001
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.194
|

1100
|

0010
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.195
|

1100
|

0011
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.196
|

1100
|

0100
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.197
|

1100
|

0101
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.198
|

1100
|

0110
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.199
|

1100
|

0111
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.200
|

1100
|

1000
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.201
|

1100
|

1001
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.202
|

1100
|

1010
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.203
|

1100
|

1011
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.204
|

1100
|

1100
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.205
|

1100
|

1101
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.206
|

1100
|

1110
|

150.100.2.192
|

255.255.255.240
|
|-
|

150.100.2.207
|

1100
|

1111
|

150.100.2.192
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.208
|

1101
|

0000
|

150.100.2.208
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.209
|

1101
|

0001
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.210
|

1101
|

0010
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.211
|

1101
|

0011
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.212
|

1101
|

0100
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.213
|

1101
|

0101
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.214
|

1101
|

0110
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.215
|

1101
|

0111
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.216
|

1101
|

1000
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.217
|

1101
|

1001
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.218
|

1101
|

1010
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.219
|

1101
|

1011
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.220
|

1101
|

1100
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.221
|

1101
|

1101
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.222
|

1101
|

1110
|

150.100.2.208
|

255.255.255.240
|
|-
|

150.100.2.223
|

1101
|

1111
|

150.100.2.208
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.224
|

1110
|

0000
|

150.100.2.224
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.225
|

1110
|

0001
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.226
|

1110
|

0010
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.227
|

1110
|

0011
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.228
|

1110
|

0100
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.229
|

1110
|

0101
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.230
|

1110
|

0110
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.231
|

1110
|

0111
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.232
|

1110
|

1000
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.233
|

1110
|

1001
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.234
|

1110
|

1010
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.235
|

1110
|

1011
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.236
|

1110
|

1100
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.237
|

1110
|

1101
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.238
|

1110
|

1110
|

150.100.2.224
|

255.255.255.240
|
|-
|

150.100.2.239
|

1110
|

1111
|

150.100.2.224
|

255.255.255.240
|

Subnet broadcast
|-
|

150.100.2.240
|

1111
|

0000
|

150.100.2.240
|

255.255.255.240
|

Subnet identifier
|-
|

150.100.2.241
|

1111
|

0001
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.242
|

1111
|

0010
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.243
|

1111
|

0011
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.244
|

1111
|

0100
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.245
|

1111
|

0101
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.246
|

1111
|

0110
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.247
|

1111
|

0111
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.248
|

1111
|

1000
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.249
|

1111
|

1001
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.250
|

1111
|

1010
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.251
|

1111
|

1011
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.252
|

1111
|

1100
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.253
|

1111
|

1101
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.254
|

1111
|

1110
|

150.100.2.240
|

255.255.255.240
|
|-
|

150.100.2.255
|

1111
|

1111
|

150.100.2.240
|

255.255.255.240
|

Subnet broadcast; area boundary; area 17 ends
|}

[[Category: Internetwork Design]]

Internetwork Design Guide -- LAN Switching

2012-10-16T21:36:21Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="lan switching, internetworking"></meta>
Today's local-area networks (LANs) are becoming increasingly congested and overburdened. In addition to an ever-growing population of network users, several factors have combined to stress the capabilities of traditional LANs:
* Faster CPUs-In the mid-1980s, the most common desktop workstation was a PC. At the time, most PCs could execute 1 million instructions per second (MIPS). Today, workstations with 50 to 75 MIPS of processing power are common, and I/O speeds have increased accordingly. Two modern engineering workstations on the same LAN can easily saturate it.
* Faster operating systems-Until recently, operating system design had constrained network access. Of the three most common desktop operating systems (DOS/Windows, the UNIX operating system, and the Mac OS), only the UNIX operating system could multitask. Multitasking allows users to initiate simultaneous network transactions. With the release of Windows 95, which reflected a redesign of DOS/Windows that included multitasking, PC users could increase their demands for network resources.
* Network-intensive applications-Use of client-server applications, such as Network File System (NFS), LAN Manager, NetWare, and World Wide Web is increasing. Client-server applications allow administrators to centralize information, thus making it easy to maintain and protect. Client-server applications free users from the burden of maintaining information and the cost of providing enough hard disk space to store it. Given the cost benefit of client-server applications, such applications are likely to become even more widely used in the future.

Switching is a technology that alleviates congestion in Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) LANs by reducing traffic and increasing bandwidth. Such switches, known as LAN switches, are designed to work with existing cable infrastructures so that they can be installed with minimal disruption of existing networks. Often, they replace shared hubs. This case study describes how LAN switching works, how virtual LANs work, and how to configure virtual LANs (VLANs) in a topology that consists of Catalyst 5000 LAN switches.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Understanding Switching Basics ==
The term switching was originally used to describe packet-switch technologies, such as Link Access Procedure, Balanced (LAPB), Frame Relay, Switched Multimegabit Data Service (SMDS), and X.25. Today, switching refers to a technology that is similar to a bridge in many ways.

The term bridging refers to a technology in which a device (known as a bridge) connects two or more LAN segments. A bridge transmits datagrams from one segment to their destinations on other segments. When a bridge is powered and begins to operate, it examines the Media Access Control (MAC) address of the datagrams that flow through it to build a table of known destinations. If the bridge knows that the destination of a datagram is on the same segment as the source of the datagram, it drops the datagram because there is no need to transmit it. If the bridge knows that the destination is on another segment, it transmits the datagram on that segment only. If the bridge does not know the destination segment, the bridge transmits the datagram on all segments except the source segment (a technique known as flooding). The primary benefit of bridging is that it limits traffic to certain network segments.

Like bridges, switches connect LAN segments, use a table of MAC addresses to determine the segment on which a datagram needs to be transmitted, and reduce traffic. Switches operate at much higher speeds than bridges, and can support new functionality, such as virtual LANs.
== Switching in the Ethernet Environment ==
The most common LAN media is traditional Ethernet, which has a maximum bandwidth of 10 Mbps. Traditional Ethernet is a half-duplex technology. Each Ethernet host checks the network to determine whether data is being transmitted before it transmits and defers transmission if the network is in use. In spite of transmission deferral, two or more Ethernet hosts can transmit at the same time, which results in a collision. When a collision occurs, the hosts enter a back-off phase and retransmit later. As more hosts are added to the network, hosts must wait more often before they can begin transmitting, and collisions are more likely to occur because more hosts are trying to transmit. Today, throughput on traditional Ethernet LANs suffers even more because users are running network-intensive software, such as client-server applications, which cause hosts to transmit more often and for longer periods of time.

An Ethernet LAN switch improves bandwidth by separating collision domains and selectively forwarding traffic to the appropriate segments. [[Internetwork Design Guide -- LAN Switching#Figure: Ethernet switching|Figure: Ethernet switching]] shows the topology of a typical Ethernet network in which a LAN switch has been installed.

===== Figure: Ethernet switching=====

[[image:nd202301.jpg]]

In [[Internetwork Design Guide -- LAN Switching#Figure: Ethernet switching|Figure: Ethernet switching]], each Ethernet segment is connected to a port on the LAN switch. If Server A on port 1 needs to transmit to Client B on port 2, the LAN switch forwards Ethernet frames from port 1 to port 2, thus sparing port 3 and port 4 from frames destined for Client B. If Server C needs to send data to Client D at the same time that Server A sends data to Client B, it can do so because the LAN switch can forward frames from port 3 to port 4 at the same time it is forwarding frames from port 1 to port 2. If Server A needs to send data to Client E, which also resides on port 1, the LAN switch does not need to forward any frames.

Performance improves in LANs in which LAN switches are installed because the LAN switch creates isolated collision domains. By spreading users over several collision domains, collisions are avoided and performance improves. Many LAN switch installations assign just one user per port, which gives that user an effective bandwidth of 10 Mbps.
== Understanding Virtual LANs ==
A virtual LAN (VLAN) is a group of hosts or network devices, such as routers (running transparent bridging) and bridges, that forms a single bridging domain. Layer 2 bridging protocols, such as IEEE 802.10 and Inter-Switch Link (ISL), allow a VLAN to exist across a variety of equipment, including LAN switches.

VLANs are formed to group related users regardless of the physical connections of their hosts to the network. The users can be spread across a campus network or even across geographically dispersed locations. A variety of strategies can be used to group users. For example, the users might be grouped according to their department or functional team. In general, the goal is to group users into VLANs so that most of their traffic stays within the VLAN. When you configure VLANs, the network can take advantage of the following benefits:
* Broadcast control-Just as switches physically isolate collision domains for attached hosts and only forward traffic out a particular port, VLANs provide logical collision domains that confine broadcast and multicast traffic to the bridging domain.
* Security-If you do not include a router in a VLAN, no users outside of that VLAN can communicate with the users in the VLAN and vice versa. This extreme level of security can be highly desirable for certain projects and applications.
* Performance-You can assign users that require high-performance networking to their own VLANs. You might, for example, assign an engineer who is testing a multicast application and the servers the engineer uses to a single VLAN. The engineer experiences improved network performance by being on a "dedicated LAN," and the rest of the engineering group experiences improved network performance because the traffic generated by the network-intensive application is isolated to another VLAN.
* Network management-Software on the switch allows you to assign users to VLANs and, later, reassign them to another VLAN. Recabling to change connectivity is no longer necessary in the switched LAN environment because network management tools allow you to reconfigure the LAN logically in seconds.

[[Internetwork Design Guide -- LAN Switching#Figure: Typical VLAN topology|Figure: Typical VLAN topology]] shows an example of a switched LAN topology in which VLANs are configured.

===== Figure: Typical VLAN topology=====

[[image:nd202302.jpg]]

In [[Internetwork Design Guide -- LAN Switching#Figure: Typical VLAN topology|Figure: Typical VLAN topology]], a 10-Mbps Ethernet connects the hosts on each floor to Catalyst 5000 LAN switches. 100-Mbps Fast Ethernet connects switches A, B, C, and D to Switch E.

{{note|The Catalyst 5000 has five slots in which modules can be installed. The supervisor engine module is always installed in slot 1. The supervisor engine module is the main system processor switch; it provides a console port and two 100-Mbps Fast Ethernet ports. A variety of other modules providing 10-Mbps Ethernet and Fast Ethernet interfaces can be installed in slots 2 through 5. Ports are identified by their slot number and their position, from left to right, on the module. For example, port 2/2 is the second port from the left on the module in slot 2.}}

The switches in [[Internetwork Design Guide -- LAN Switching#Figure: Typical VLAN topology|Figure: Typical VLAN topology]] communicate with each other using ISL, which is a protocol that maintains VLAN information as traffic flows between the switches. With ISL, an Ethernet frame is encapsulated with a 30-byte header that contains a two-byte VLAN ID.

[[Internetwork Design Guide -- LAN Switching#Figure: Typical VLAN topology|Figure: Typical VLAN topology]] shows that VLAN 20 consists of port 4 in slot 2 on Switch A and ports 1 and 3 in slot 4 on Switch B. Frames exchanged between ports 1/4 and 3/4 are switched by Switch B as normal. On Switch B, any frame generated by ports 1/4 and 3/4 that is not destined for ports 1/4 and 3/4 is encapsulated in an ISL header that includes a VLAN 20 identifier and is sent to Switch E. Switch E examines the ISL header and determines that the frame is intended for VLAN 20 and sends the frame out on port 2/2 to Switch A. Switch A examines the ISL header to determine the VLAN for which the frame is destined, removes the header, and switches it to all ports in VLAN 20 (if the frame is broadcast or multicast) or to port 2/4 if the frame is a unicast.
== Configuring the Switches ==
When a Catalyst 5000 switch first starts up, the following defaults are set:
* The console port is set to 9600 baud, 8 data bits, no parity, and 1 stop bit. If you want to change the baud rate, use the '''set system baud''' command.
* The Cisco Discovery Protocol (CDP) is enabled on every port to send a CDP message every 60 seconds. If you want to disable CDP on ports that do not have a Cisco device, use the '''set cdp disable''' command.
* The following Simple Network Management Protocol (SNMP) community strings are defined:
** "public" for the read-only access type
** "private" for the read-write access type
** "secret" for the read-write-all access type
: If you want to set other SNMP community strings, use the '''set snmp community''' command.
* All modules and all ports are enabled. To disable a module, use the '''set module disable''' command, and to disable a port, use the '''set port disable''' command.
* All 10-Mbps Ethernet ports are set to half duplex. Use the''' set port duplex''' command to set a port to full duplex.

When you first start up a switch, you should set some values that apply to the switch as a whole. For example, you might enter the following commands at the console port of Switch A:

<pre>set system contact Terry Moran
set system location Norwich
set system name SwitchA
set time fri 9/15/95 14:08:34
set prompt SwitchA>
set password
set enablepass
set interface sc0 131.108.40.1 </pre>

The '''set system contact '''command establishes "Terry Moran" as the person to contact for system administration. The '''set system name''' establishes "SwitchA" as the name of this switch. The '''set time''' command sets the current time, using a 24-hour clock format. The '''set promp'''t command sets the prompt to "SwitchA>". The default prompt is "Console".

The '''set password''' command sets password protection for the administrative interface in normal mode. When you enter the '''set password''' command, the switch prompts you to enter a password and then prompts you to reenter the password.

The '''set enablepass''' command sets password protection for the administrative interface in privileged mode. When you enter the '''set enablepass '''command, the switch prompts you to enter a password and then prompts you to reenter the password.

The '''set interface''' command assigns an IP address and netmask to interface sc0. After you make this assignment, you can Telnet to the switch to perform administrative tasks. The switch supports up to eight simultaneous Telnet connections. Alternatively, you can use the '''set interface''' command to enable a Serial Line Interface Protocol (SLIP) connection on the console interface (sl0).
=== Configuring VLANs on Switch A ===
The following commands configure VLANs 10 and 20 on Switch A:

set vlan 10 2/1,2/2
set vlan 20 2/4
set trunk 1/1 10,20

The first '''set vlan''' command creates VLAN 10 and assigns ports 1 and 2 in slot 2 to it. The second '''set vlan''' command creates VLAN 20 and assigns port 4 in slot 2 to it.

The '''set trunk''' command configures port 1 in slot 1 as a trunk and adds VLANs 10 and 20 to it. Trunks are used for Fast Ethernet connections between switches. When a port is configured as a trunk, it runs in ISL mode. To detect and break loops, trunks use the spanning-tree protocol on all VLANs that are carried across the trunk.
=== Configuring VLANs on Switch B ===
The following commands configure VLANs 10 and 20 on Switch B:

set vlan 10 2/2
set vlan 20 2/1,2/3
set trunk 1/1 10,20

The first '''set vlan''' command creates VLAN 10 and assigns port 2 in slot 2 to it. The second '''set vlan''' command creates VLAN 20 and assigns ports 1 and 3 in slot 2 to it. The '''set trunk''' command configures port 1 in slot 1 as a trunk and adds VLANs 10 and 20 to it.
=== Configuring VLANs on Switch E ===
The following commands configure VLANs 10 and 20 on Switch E:

set trunk 2/1 10,20
set trunk 2/2 10,20

The first '''set trunk''' command configures port 1 in slot 2 as a trunk and adds VLANs 10 and 20 to it. This trunk is used to communicate with Switch B. The second '''set trunk''' command configures port 2 in slot 2 as a trunk and adds VLANs 10 and 20 to it. This trunk is used to communicate with Switch A.
== Summary ==
LAN switching technology improves the performance of traditional Ethernet, FDDI, and Token Ring technologies without requiring costly wiring upgrades or time-consuming host reconfiguration. The low price per port allows the deployment of LAN switches so that they decrease segment size and increase available bandwidth. VLANs make it possible to extend the benefit of switching over a network of LAN switches and other switching devices.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers

2012-10-16T21:35:50Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="h323, internetworking"></meta>

'''by Vikas Butaney and Stephen Liu TME's VoIP'''

In today's highly competitive communications industry, service providers must find new ways to increase revenue and leverage their existing network infrastructure. Many service providers have already deployed networks consisting of Cisco solutions to provide data services to their subscribers. For them, packet telephony is a readily deployable, value-added, revenue-generating application that leverages the Cisco technology's data-handling capabilities.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== What is Packet Telephony? ==
Packet-switched technology has expanded from data-only applications to take on the functions of traditional circuit-switched equipment. While the lower cost of packet-switched networks initially drove this change, the improving quality and reliability of voice over these networks is speeding integration of voice and data services. As a result, today's voice networks will eventually be replaced by packet infrastructure over the next decade.

Cisco open packet telephony (OPT) is the foundation for these new services. Because it opens the call-control function to new services, it enables service providers to get to market faster with best-of-class solutions. Furthermore, OPT delivers carrier-class voice quality, so service providers can deploy packet voice services with confidence as they seamlessly extend the reach of traditional voice networks. OPT is based on open interfaces and standards, allowing an ecosystem of partners to work together to develop innovative network services. Built for both IP and ATM transport, OPT offers integrated services for subscribers using a wide variety of access technologies including analog, DSL, ISDN, wireless, wireless local loop, and cable. Thus OPT makes optimal use of existing bandwidth to support migration, rather than replacement, of existing equipment. This standards-based, multivendor approach also allows OPT networks to scale cost-effectively. Service providers can therefore profitably expand into new locales and additional consumer and enterprise markets.
== Where Is Packet Telephony Technology Today? ==
While various packet telephony solutions exist, H.323 is available with the features to deploy networks today. Cisco solutions incorporating H.323 are mature, widely accepted, and currently shipping, while other options are still maturing. This design guide has been created to help the reader understand the Cisco implementation of H.323 and, through a typical design example, illustrate how service providers can successfully and profitably deploy H.323v2-based packet telephony services.
== An H.323 Primer ==
H.323 is an existing specification defined by the International Telecommunication Union (ITU), which has been available since 1996. Version 2 was approved in January 1998 and Version 3 is currently being defined. The wide acceptance and maturity of this standard offers service providers a high level of confidence when deploying packet telephony solutions with Cisco equipment.

H.323 is a specification for transmitting multimedia (data, voice, and video) across any packet-based network. This packet-based network can be IP, IPX, or any other protocol. Cisco supports H.323 over IP networks. H.323 also allows for standards-based interoperability with other vendors' H.323-compatible equipment.

H.323 defines four functional components: H.323 terminals, H.323 Multi-point Control Units (MCUs), H.323 gateways, and H.323 gatekeepers, as well as the protocols used by these devices to communicate with each other.

The most elemental component of H.323 is the H.323 terminal. Other endpoints, such as gateways and MCUs, leverage the definitions specified in the H.323 terminal. The H.323 terminal is described by audio, video, data, system control, and media-streaming capabilities. At a minimum, H.323-compliant terminals are required to carry voice, while video and data are optional. For voice, H.323 mandates that the G.711 audio CODEC is supported while G.722, G.723, G.723.1, G.728, and G.729 CODECs are optional. For video CODECs, H.261 is mandatory while H.263 is an option. The T.120 specification is used for applications such as workgroup data collaboration.

In addition to referencing T.120 and various codec specifications, H.323 is further defined by a mixture of existing recommendations for call control, system control, and endpoint communication with gatekeepers. H.225 messages define call control functions and utilize a scaled-down version of Q.931 to set up the connection between two H.323 endpoints. These H.225 messages consist of Q.931 setup, call proceeding, alerting, connect, facility, and release.

H.245 specifies the system control messages in H.323. It uses TCP to provide reliable transport for capabilities exchange, mode preference from the receiving end, master/slave determination, logical channel signaling, and control and indication. Capabilities exchange specifics include things such as which CODECs are available for use in the VoIP call leg.

Registration, admission, and status (RAS) messages are used for H.323 endpoints to communicate with H.323 gatekeepers. RAS discovery messages help the end point "discover" a gatekeeper by sending a gatekeeper request (GRQ) message. After receiving a gatekeeper request, a gatekeeper can respond with a gatekeeper confirm (GCF) message, or a gatekeeper reject (GRJ) message.

Once an endpoint has discovered the available gatekeepers, it attempts to register with one of them using a registration request (RRQ) RAS message that contains information about the endpoint. The gatekeeper then responds with a registration confirm (RCF) message if it is alright to register with that gatekeeper, or a registration reject (RRJ) if it is not. Having responded with an RCF, the gatekeeper creates a table from this information that defines with which IP address each E.164 address and H.323 alias corresponds.

After successfully registering with the gatekeeper, the endpoint must ask permission of the gatekeeper before sending or receiving a phone call using admission request (ARQ) RAS messages. [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: RAS Messages|Figure: RAS Messages]] demonstrates how a gateway (GW) places a H.323 call with the help of a gatekeeper (GK). The gatekeeper then replies with an admission confirm (ACF), or an admission reject (ARJ).

===== Figure: RAS Messages=====

[[image:Design_Guide-26-2-1.jpg]]

There are several other useful types of RAS messages. Disconnect request (DRQ/DCF/DRJ) is invoked upon completion of the call. If the local gatekeeper cannot handle the call, the location request (LRQ/LCF/LRJ) can be sent to other gatekeepers to determine which one can service the particular number. Information request (IRQ/ICF/IRR) can be used to provide the periodic status of active calls. Bandwidth request (BRQ/BCF/BRJ) can increase or decrease available bandwidth to support active calls. Finally, an unregistration request (URQ/UCF/URJ) message can enable a gatekeeper to disassociate itself from an endpoint, or an endpoint to disassociate itself from a gatekeeper.

Finally, the H.323 terminal defines the use of Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) for streaming media over IP. After the H.323 call setup and control process is completed, audio and video packets are sent via User Datagram Protocol (UDP). To assist with streaming audio and video, the specification calls for an RTP header. RTP headers contain a time stamp and sequence number, allowing the receiving device to buffer as much as necessary to remove jitter and latency by synchronizing the packets to play back a continuous stream of sound.

The RTP specification stipulates that the RTP server is to use an even port number, whereas RTCP is to use the next-available odd number. RTCP, used to control RTP, gathers reliability information and periodically passes this information onto session participants. RTCP cannot use more than 5 percent of the session bandwidth used by RTP.

The H.323 gateway is simply an H.323 terminal with added responsibility. An H.323 gateway provides a gate between the IP world and other network types such as the Public Switched Telephone Network (PSTN), H.320, V.70, and H.324. To do this, the gateway must reflect all characteristics on one network to the other. For example, call signaling from the PSTN side must be accurately mapped into the Voice over IP (VoIP) side and vice versa. Likewise, media from the PSTN side must be reflected into the VoIP side and vice versa. Cisco gateways currently provide PSTN to H.323 gateway functions.

An H.323 gatekeeper performs address translation, admission control, bandwidth management, and zone management. Cisco 2600 and Cisco 3600 are examples of multimedia gatekeepers (data, voice, and video)-but cannot currently function as gateways and gatekeepers simultaneously.
== Anatomy of a VoIP Network ==
To understand a Cisco VoIP network, it is important to analyze its components and features. [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: Anatomy of a Packet Telephony Network|Figure: Anatomy of a Packet Telephony Network]] schematically depicts a typical VoIP network. At a very high level, a Cisco H.323 VoIP network consists of gatekeepers that control H.323 zones. Each zone consists of one or more points of presence (POPs), and each POP can contain one or more Cisco AS5300s.

===== Figure: Anatomy of a Packet Telephony Network=====

[[image:Design_Guide-26-2-2.jpg]]

== T1/E1 Support ==
When initially released, the Cisco AS5300 with voice feature card (VFC) supported T1 PRI signaling. With the service provider feature set release in Cisco IOS® 11.3(6) NA2, T1 CAS (both immediate and wink start) was added. The Cisco AS5300 also supports E1 PRI and, with the Cisco IOS 11.3(7) release, added support for E1 R2.
== Interactive Voice Response Support ==
Interactive voice response (IVR) support was added as a part of the service provider features in Cisco IOS 11.3(6) NA2. Among the scripts included in that release were "clid_authen," which can authenticate users either by the Automatic Number Identification (ANI) and the DNIS or by prompting the user to enter a username and password.

These scripts enable a service provider to provide second dial-tone types of services by authenticating the user based on their ANI or unique username and passcode. Since the initial release, Cisco has added additional scripts and is adding support such that Cisco staff can help customers create their own IVR scripts.
== CODEC Support ==
The initial version of the AS5300 voice feature card supported the TI 542 DSPs, and G.711 (u-law and A-law) and G.729 CODECs. In the future, support will be added for G.723.1 (both 5.3 and 6.3 Kbps CODECs), and G.729 Annex B. These CODECs will be available on 542 DSPs and also on the higher density VFCs.
== Gatekeeper Platform Support ==
Gatekeeper functionality is supported on the Cisco 2500, 2600, and 3600 series routers (models 3620 and 3640). For environments with large, scalable requirements, Cisco 3640 routers with the full 128 MB of DRAM are recommended. Cisco IOS gatekeeper software will always carry an "ix" in the image name.
== H.323 Case Study ==
To illustrate the concepts just described, we will look at an actual case study. This service provider wants to add voice on the network and expand its current services. The service provider is a tier-two/tier-three Internet Service Provider (ISP) with a base that includes business and residential subscribers within the U.S. The service provider currently has 20 dial POPs.

The new packet telephony network will support second dial tone for voice calls only (no fax), and will interface to the PSTN via T1 Primary Rate Interfaces (PRIs). Four POPs will be initially deployed in New York, Chicago, Los Angeles, and Miami with the remainder deployed within one year. The packet telephony network must be designed to facilitate this rapid expansion.

Based on the current traffic projections, the service provider wants to initially offer 96 voice ports in each of the POPs today. Cisco 7206 routers will be used for backhauling calls. Because Cisco AS5300s currently support 48 ports each, two AS5300s will be required per POP. Subscribers will dial the ISP's local access number. An IVR script on the gateway will prompt the user to authenticate based upon account number and password. The ISP is familiar with, and prefers to use, RADIUS, an accounting feature employed in VoIP gateways for producing accurate, timely billing and usage information.
== Network Dimensioning-How Assumptions Affect Design ==
The assumptions made above will have some impact on the network design, as seen in [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: How Assumptions Affect Design|Table: How Assumptions Affect Design]] below. Some major issues a designer must consider when designing a VoIP Network are the number of gateway ports, gatekeeper availability, and the amount of wide-area bandwidth required to support a given call load. The designer must also be aware of how various design variables impact these requirements. For example, silence suppression only affects the wide-area bandwidth, but does not affect gatekeeper or gateway sizing. Similarly, CODEC choice, e.g. G.711 or G.729, impacts only wide-area bandwidth. Other factors such as average holding time, the time a customer is on a call, can affect both wide-area bandwidth and the ports required on a gatekeeper and gateway. Tools such as header compression can alleviate some wide-area bandwidth requirements, but this is not supported or recommended for large ISP environments.

===== Table: How Assumptions Affect Design=====

{| border = 1
|-

|

!'''Areas of Impact'''

|-
|
''' '''
|
''' WAN Bandwidth'''
|
''' GW Ports/GK'''
|-
|

Silence Suppression:

Can't Be Applied to Applications (Such As Fax)

Percent Reduction in Per-Call Bandwidth will Vary by Application.
|

X
|

|-
|

CODEC Type:

Bandwidth Per Call Varies by CODEC Type (for example G.711 Bandwidth Is Greater than G.729)
|

X
|

|-
|

Average Hold Time:

Varies by Application, User Type, and Even Market (for example Fax Has Shorter Average Holding Time than Voice)
|

X
|

X
|-
|

Header Compression:

Reduces Bandwidth Per Call for Lower-Speed Links
|

X
|

|}

== Sizing the POPs ==
The ISP has made some assumptions regarding the sizing of the four POPs. Voice ports will be utilized 100 percent during busy hour (36 Centum Call Seconds [CCS]). Statistically, silence is present 50 percent of the time on a voice call. With the default configuration using the G.729 CODEC, a Cisco AS5300 gateway will generate a 20-byte voice sample every 20 ms or 50 pps. Adding the 12-byte RTP header, eight-byte Unreliable Datagram Protocol (UDP) header, and 20-byte IP header to the packet, the IP datagram will total 60 bytes. With 6 bytes of link-layer overhead, this generates a 66-byte packet every 20 msec (without voice activity detection [VAD]). With VAD enabled, this translates to:

66 bytes/packet * 8 bits/byte * 1/2 * 50 pps = 13.2 kbps per call or DS0

Assuming that VAD will reduce bandwidth utilization by approximately half, supporting 96 calls from each POP will require 1.27 Mbps which is less than one T1 for backhaul.
== Network Design ==
Assuming the above requirements and considerations, the network is illustrated in [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: How Assumptions Affect Design|Table: How Assumptions Affect Design]]. The nationwide network will be divided geographically into four zones (a Chicago Midwestern zone, a New York Northeastern zone, a Miami Southern zone, and a Los Angeles Western zone) to anticipate future growth. All of these nodes are connected via an existing quality-of-service (QoS)-enabled IP backbone.

Each zone will have redundant Hot-Standby Router Protocol (HSRP)-enabled Cisco 3640 gatekeepers to ensure that another redundant gatekeeper takes over, should the active gatekeeper fail. Since a gatekeeper can handle approximately 1000 active calls, 20 AS5300s (or 10 POPs) can be serviced with the current 48-port capacity of the AS5300s.

For the purposes of this example, we will assume that the PSTN circuits are in the same rate center. A rate center is a calling area consisting of several central offices usually concentrated in a geographic area. Usually a LEC will charge for intra-LATA calls crossing these rate centers. Assuming that each POP will not service calls outside it's rate center and because the network is being deployed with just four cities the network will not service the entire U.S. market. Therefore, PSTN calls to areas not covered will need to be handed off to another service provider for termination. This is referred to as off-net traffic. In this example, calls to off-net cities will hop off at the Chicago POP to a wholesale long distance carrier that offers a flat-rate charge on a per-minute basis.

===== Figure: The Packet Telephony Network Initially Consists of Four POPs=====

[[image:Design_Guide-26-2-3.jpg]]

Consider a simplified example, shown in [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: A Simplified Three-Zone Network|Figure: A Simplified Three-Zone Network]], illustrating our dial plan based on number planning areas (NPAs) or area codes only. A real-life network would require a more detailed dial plan containing NPA-NXX (area codes and local prefixes). Furthermore, there are many NPAs in Chicago and Los Angeles. However, this example addresses the following sample configuration:
* Los Angeles NPAs: 213, 310, 323
* Chicago NPAs: 224, 312, 630

Finally, we assume the gatekeepers will use direct end-point signaling to reach other zones in this network and proxy mode to protect this network from access by external zones. Although a Cisco AS5300 has two Ethernet interfaces, the H.323 process should not be bound to one or the other. Rather, a more reliable network is created if it is bound to a loopback (logical) interface.

===== Figure: A Simplified Three-Zone Network=====

[[image:Design_Guide-26-2-4.jpg]]

Let's start by looking at a fundamental block of the network. Let's focus on the western zone which contains the western-GK and a GW to look at the configurations.
=== Gateway Configuration-Los Angeles ===
[[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: LA Gateway Configuration|Table: LA Gateway Configuration]] shows the configuration for the LA gateway.

===== Table: LA Gateway Configuration=====

{| border = 1
|-
|'''Command'''

|'''Description'''

|-
|

Hostname la1-gw.west.acme.com
|

The host name of this gateway is la1-gw.west.acme.com. This is the first gateway in the western zone in the Acme Corporation.
|
|-
|

<pre>aaa new-model
aaa authentication login default radius
aaa accounting connection h323 start-stop radius
!
gw-accounting h323
!
radius-server host 10.1.11.11 auth-port 1645 acct-port 1646
radius-server key testing123
! </pre>
|

To allow for the billing and collection of the user name and password, '''aaa new model''' is enabled. For VoIP authentication and accounting Cisco gateways use RADIUS.

The gateway will send both the start and the stop records to the RADIUS server.

The '''gw-accounting h323''' command instructs the gateway to perform accounting for the H.323 calls.

And the following commands define the properties for the RADIUS server (these commands will appear at the end of the configuration).
|-
|

<pre>isdn switch-type primary-5ess
!</pre>
|

This gateway will use an ISDN PRI connection to the network, and a global switch-type command has been enabled. Specific properties have also been enabled on each of the controllers.
|-
|

<pre>Controller T1 0
Framing esf
Clock source line primary
Linecode b8zs
pri-group timeslots 1-24
! </pre>

|

Extended Super Frame (ESF) is used for framing and Binary 8 Zero Suppression (B8ZS) for line code. Clock will be taken from the T1 interface connected to the PSTN. ISDN PRI interface is defined, with 1 to 24 timeslots.
|-
|

<pre>dial-peer voice 2 voip
destination-pattern 2.......
session target ras
precedence 5
! </pre>
|

The dial-peer commands define the dial plan for the gateway. These commands instruct the gateway to check with the gatekeeper, use a TDM interface for the call, or signal to the terminating gateway directly. In this example, '''dial-peer voice 2''' is a VoIP-type of dial-peer and the destination pattern is a "2" followed by 9 dots. This maps to any destination 10-digit phone number that begins with a "2." Once the DNIS has been identified, we need to examine what to do with the call. In this example, we refer to the gatekeeper for address resolution, and when the call is set up the RTP packets will be marked with a precedence of 5. Other routers that the VoIP packets will traverse can use the precedence to prioritize the VoIP packets over other traffic traversing the network, providing good-quality voice.
|-
|

<pre>Repeat till 9.........
! </pre>
|

The same command will need to be repeated for numbers that begin with "3, 4, 5, 6, 7, 8," and "9" plus nine dots to address all possible numbers.
|-
|

<pre>dial-peer voice 213 pots
destination-pattern 213.........
application clid_authen_collect
port 0:D
!
Repeat for other NPAs served
! </pre>
|

Previously we defined the dial-peers for calls going to the packet network. Now we will define the dial-peers for TDM basic telephone service. In addition to routing the calls to the packet network, we also need to tell the gateway what the phone numbers on the TDM/plain old telephone service (POTS) interfaces are. This is referred to as a POTS dial-peer. For calls coming in from the VoIP side, a called number that begins with 213 will be sent out on port 0:D. The same command must be repeated for the other NPA and NXX peers served within the cities and also for the other controller, such as controller 1 or port 1:D.

For an incoming call from the TDM port 0:D, this command will launch the clid_authen_collect script, which will authenticate based on ANI and DNIS and, if that fails, prompt the user for USERNAME and PASSWORD for authentication.
|-
|

<pre>gateway
! </pre>
|

The gateway command is enabled, which is the global command to enable the RAS (Registration, Admission and Status) functionality on a gateway. RAS allows the gateway to communicate with the gatekeeper.
|-
|

<pre>Interface Loopback0
ip address 10.10.250.1255.255.255.0
h323-gateway voip interface
h323-gateway voip id gk.west.acme.com ipaddr 10.10.254.10 1719
h323-gateway voip h323-id la1-gw.west.acme.com h323-gateway voip tech-prefix 1#
! </pre>
|

The next section concerns the interface loopback 0. As discussed earlier, the Loopback interface helps build a more redundant and reliable network.

Next we specify that this interface will be used for H.323-based communications. The following command defines the gatekeeper's properties, such as the name and the IP address where it is available. The next command indicates that the local gateway has the H.323-ID of gw.west.acme.com. The last command will register a technology prefix of 1# to identify the capabilities of this gateway.
|-
|

<pre>Interface Ethernet0
ip address 10.10.254.5 255.255.255.0
! </pre>
|

The interface Ethernet 0 is then defined. Typically, both Ethernet 0 and Fast Ethernet 0 will be enabled.
|-
|

<pre>Interface Serial0:23
isdn switch-type primary-5ess
isdn incoming-voice modem
! </pre>
|

The serial interface 0:23 in the next section refers to the D Channel of the 0th PRI interface and its properties. A 5E custom switch is specified, and incoming voice calls are directed to the DSPs/modem.
|-
|

<pre>La1-gw.west.acme.com#show gateway
Gateway la1-gw.west.acme.com is registered to Gatekeeper gk.west.acme.com </pre>
|

Once the configuration is complete, the user will need to make sure that the commands are accurate. By typing '''show gateway''' the system administrator can determine whether the gateway was able to register with the gatekeeper. This confirms that the gatekeeper and the gateway were configured correctly and that there are no connectivity problems.
|}

=== Gatekeeper Configuration-Los Angeles ===
[[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: Western GK Configuration|Table: Western GK Configuration]] shows the gatekeeper configuration for the Western zone. These commands are for a GK running IOS 12.0(3)T or earlier.

===== Table: Western GK Configuration=====

{| border = 1
|-
!Command
!Description
|-
|

<pre>Hostname gk1.west.acme.com
! </pre>
|

The host name is gk1.west.acme.com, because this is the first gatekeeper in the Western zone in this network.
|-
|

<pre>interface Ethernet0/0
ip address 10.10.254.4 255.255.255.0
standby 1 priority 110 <-- Primary
standby 1 ip 10.10.254.10 </pre>
|

Under the Ethernet interface definition is the IP address. The HSRP commands are enabled and this is the first HSRP group. This gatekeeper has been given a priority of 110, which will force it to assume the primary role over the other gatekeeper.

An IP address is specified that all gateways and other gatekeepers will refer to, ensuring a seamless failover between gatekeepers.
|-
|

<pre>Gatekeeper
zone local gk.west.acme.com
acme.com 10.10.254.10
zone remote gk.hopoff.acme.com
acme.com 10.10.253.10 1719
zone remote gk.mwest.acme.com
acme.com 10.10.253.10 1719
zone access gk.west.acme.com
remote-zone gk.mwest.acme.com direct
zone access gk.west.acme.com
remote-zone gk.hopoff.acme.com direct
zone access gk.west.acme.com
remote-zone gk.neast.acme.com direct
zone access gk.west.acme.com
remote-zone gk.south.acme.com direct </pre>
|

Next comes the gatekeeper commands. The local gatekeeper properties for gatekeeper.west.acme.com are defined, and the IP address where the service will be running is specified. Then the remote zones within this network are defined. The hop-off gatekeeper has an IP address of 10.10.253.10, and the IP address of 1719. Similarly, the other Midwestern gatekeeper zone is defined.

The zone access is then defined, which describes how this zone can be accessed from other gateways and gatekeepers in this network. The Western zone can be approached by the Midwestern gatekeeper and the corresponding gateways in a direct signaling mode. The same properties are applied for the other gateways and other gatekeepers within the network.
|-
|

<pre>zone access gk.west.acme.com
default proxied </pre>
|

The next command, '''zone access gk.west.acme.com default proxied''', forces the remaining gatekeepers to use a proxied mode. This protects the gatekeeper or the gateways from other gatekeepers that are not authorized to approach this site.
|-
|

zone subnet gk.west.acme.com 10.10.250.0/24 enable
|

The '''zone subnet''' command defines who can register with this gatekeeper, providing a security mechanism that restricts only the gateways within the 10.10.250.0 subnet to register with this gatekeeper.
|-
|

<pre>zone prefix gk.west.acme.com 213*
zone prefix gk.west.acme.com 310*
zone prefix gk.west.acme.com 323*
zone prefix gk.mwest.acme.com 630*
zone prefix gk.mwest.acme.com 312*
zone prefix gk.hopoff.acme.com * </pre>
|

'''Zone prefix''' is a routing command, and the next six commands define how routing is set up in this network. Area code 213, or the NPA 213, resides in the Western zone, as do 310 and 323. NPA 630 resides in the Midwestern zone, as well as 224 and 312.

The last prefix command specifies that any other NPA that does not match the first six commands resides in the hop-off gatekeeper. Depending on the requirements of a specific network, all gatekeepers may have identical zone prefix commands. If routing is based on NPA and NXX, however, the local gatekeeper will have more granularity and other gatekeepers can point to the local gatekeeper for the entire NPA.
|-
|

gw-type-prefix 1#* default-technology
|

The next command, '''gw-type-prefix 1#* default-technology''', specifies the default technology. This simplifies the design, since all gateways will use the same tech prefix and there is no reason to put the tech prefix command in the dial-peer statements.
|-
|

no shutdown
|

The last command, '''no shutdown''', enables the gatekeeper service on this particular platform.
|}

=== Show Commands-Los Angeles ===
Once these commands are entered, the show commands, below, indicate how they have taken effect and how the gatekeeper is functioning. The first command, '''show gatekeeper endpoints''', identifies which gateways have already registered with this gatekeeper. In this example, la1.gw.west.acme.com has registered with this gatekeeper in the zone gk.west.acme.com.

The following command, '''show gatekeeper zone prefix''', describes the routing table for this given gatekeeper. Confirming the configuration, 213 resides within the Western gatekeeper; 224 resides within the Midwestern gatekeeper, and so on.

The last line in the output, "gk.hopoff.acme.com," confirms that the remainder of the NPA NXXs or any phone numbers would be sent to the gatekeeper in the hop-off zone.

Show commands include:

<pre>gk1.west.acme.com#show gatekeeper endpoints

GATEKEEPER ENDPOINT REGISTRATION ================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type F
--------------- ----- --------------- ----- --------- ---- -
10.10.250.1 1720 10.10.250.1 4461 gk.west.acme.com VOIP-GW
H323-ID: la1-gw.west.acme.com
gk1.mwest.acme.com#show gatekeeper zone prefix
ZONE PREFIX TABLE
=================
GK-NAME E164-PREFIX
------- -----------
gk.west.acme.com 213*
gk.mwest.acme.com 224*
gk.west.acme.com 310*
gk.mwest.acme.com 312*
gk.west.acme.com 323*
gk.mwest.acme.com 630*
gk.hopoff.acme.com * </pre>

=== Gateway Configuration-Chicago ===
Next, the Chicago gateway is configured as shown in [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: GW-Chicago|Table: GW-Chicago]]. It is very similar to the Los Angeles gateway.

===== Table: GW-Chicago=====

{| border = 1
|-
!Command
!Description
|-
|

<pre>hostname ch1-gw.mwest.acme.com
</pre>
|

The host name for this gateway is ch1-gw.midwest.acme.com, the first gateway within the Midwestern zone in Chicago.
|-
|

<pre>aaa new-model
aaa authentication login default radius
aaa accounting connection h323 start-stop radius
!
gw-accounting h323
radius-server host 10.1.11.11 auth-port 1645
acct-port 1646
radius-server key testing123 </pre>
|

To allow for the billing and collection of the user name and password, '''aaa new model''' is enabled. For VoIP authentication and accounting Cisco gateways use RADIUS.

The gateway will send both the start and the stop records to the RADIUS server.

The '''gw-accounting h323''' command instructs the gateway to perform accounting for the H.323 calls.

And the following commands define the properties for the RADIUS server (these commands will appear at the end of the configuration).
|-
|

<pre>isdn switch-type primary-5ess
! </pre>
|

This gateway will use an ISDN PRI connection to the network, and a global switch-type command has been enabled. Specific properties have also been enabled on each of the controllers.
|-
|

<pre>controller T1 0
framing esf
clock source line primary
linecode b8zs
pri-group timeslots 1-24
! </pre>
|

The '''controller T1 0''' command enables the controller T1 0 and the framing and line code properties.
|-
|

<pre>dial-peer voice 2 voip
destination-pattern 2.........
session target ras
precedence 5
! </pre>
|

The dial-peer commands define the dial plan for the gateway. These commands instruct the gateway to check with the gatekeeper, or use a TDM interface for the call, or signal to the terminating gateway directly. In this example, '''dial-peer voice 2''' is a VoIP-type of dial-peer and the destination pattern is a '''2''' followed by 9 dots. This maps to any destination 10 digit phone number that begins with a '''2'''. Once the DNIS has been identified, you must examine what to do with the call. In this example, the gatekeeper is referred to for address resolution, and when the call is set up, the RTP packets will be marked with a precedence of 5. Other routers that the VoIP packets will traverse can use the precedence to prioritize the VoIP packets over other traffic traversing the network, leading to good quality voice.
|-
|

<pre>Repeat till 9.........
! </pre>
|

Some of the other commands have been deleted due to space constraints. In a real network, the same command will need to be repeated with '''3, 4, 5, 6, 7, 8,''' and '''9''' plus nine dots to address all possible numbers with the E.164 dial plan.
|-
|

<pre>dial-peer voice 312 pots
application clid_authen_collect
destination-pattern 312.......
port 0:D
!
Repeat for other NPAs served </pre>
|

Previously we defined the dial-peers for calls going to the packet network. Now we will define the dial-peers for the TDM or basic telephone service. "Dial-peer" is the basic telephone service dial-peer that picks up. In addition to the VoIP matching to the gateway, we also need to tell the gateway the phone numbers on the TDM/POTS interfaces. This is referred to as a basic telephone service dial-peer. For an incoming call from the TDM port 0:D, this command will launch the clid_authen_collect script, which will authenticate based on ANI and DNIS and, if that fails, prompt the user for USERNAME and PASSWORD for authentication. For calls coming in from the VoIP side, a called number that begins with 213 will be sent out on port 0:D. The same command must be repeated for the other NPA and NXX peers served within the cities and also for the other controller.
|-
|

<pre>gateway
! </pre>
|

The gateway command is enabled, which is the global command to enable the RAS functionality on a gateway. RAS allows the gateway to communicate with the gatekeeper.
|-
|

<pre>interface Loopback0
ip address 10.10.249.1 255.255.255.0
h323-gateway voip interface
h323-gateway voip id gk.mwest.acme.com ipaddr 10.10.253.10 1719
h323-gateway voip h323-id ch1-gw.mwest.acme.com
h323-gateway voip tech-prefix 1#
! </pre>
|

The next section concerns the interface loopback 0. As discussed earlier, the loopback interface helps build a more redundant and reliable network.

Next we specify that this interface will be used for H.323-based communications. The following command defines the gatekeeper's properties, such as the name and the IP address where it is available. The next command indicates that the local gateway has the H.323-ID of gw.west.acme.com. The last command will register a technology prefix of 1# to identify the capabilities of this gateway.
|-
|

<pre>interface Ethernet0
ip address 10.10.253.5 255.255.255.0
no ip directed-broadcast
ntp broadcast client
! </pre>
|

The interface Ethernet 0 is then defined. Typically, both Ethernet 0 and Fast Ethernet 0 will be turned on.
|-
|

<pre>interface Serial0:23
isdn switch-type primary-5ess
isdn tei-negotiation first-call
isdn incoming-voice modem
!</pre>
|

The serial interface 0:23 in the next section refers to the D Channel of the 0th PRI interface and its properties. A 5E custom switch is specified, and incoming voice calls are directed to the DSPs/modem.
|-
|

<pre>ch1-gw.mwest.acme.com#sh gateway
Gateway ch1-gw.mwest.acme.com is Registered to Gatekeeper gk.mwest.acme.com </pre>
|

Once the configuration is complete, the user will need to make sure that the commands are accurate. By typing '''show gateway''' the system administrator can determine whether the gateway was able to register with the gatekeeper. This confirms that the gatekeeper and the gateway were configured correctly and that there are no connectivity problems.
|}

=== Gatekeeper Configuration-Chicago ===
Because the same Cisco 3640 routers are used for both the hop-off zone and Midwestern zone (a Cisco gatekeeper can support more than one local zone), the Chicago gatekeeper configuration differs from the Los Angeles configuration ([[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Table: Midwest-GK Configuration|Table: Midwest-GK Configuration]]).

===== Table: Midwest-GK Configuration=====

{| border = 1
|-
!Command
!Description
|-
|

<pre>hostname gk1.mwest.acme.com
! </pre>
|

The host name is gk1.mwest.acme.com because this is the first gatekeeper in the Midwestern zone in this network.
|-
|

<pre>interface Ethernet0/0
ip address 10.10.253.4 255.255.255.0
standby 1 priority 110 <--- Primary GateKeeper
standby 1 ip 10.10.253.10
! </pre>
|

Under the Ethernet interface definition is the IP address. The HSRP commands are turned on and this is the first HSRP group. This gatekeeper has been given a priority of 110, which will force it to assume the primary role over the other gatekeeper.

An IP address is specified that all gateways and other gatekeepers will refer to, ensuring a seamless failover between gatekeepers.
|-
|

<pre>Gatekeeper
zone local gk.mwest.acme.com acme.com 10.10.253.10
zone local gk.hopoff.acme.com acme.com
zone remote gk.west.acme.com acme.com 10.10.254.10 1719 </pre>
|

Next comes the gatekeeper commands. The local gatekeeper properties for gatekeeper.mwest.acme.com are defined, and the IP address where the service will be running is specified. Then the remote zones within this network are defined. The hop-off gatekeeper has an IP address of 10.10.253.10, and the IP address of 1719. Similarly, the other West gatekeeper zone is defined.
|-
|

<pre>zone access gk.mwest.acme.com remote-zone gk.hopoff.acme.com direct
zone access gk.mwest.acme.com remote-zone gk.neast.acme.com direct
zone access gk.mwest.acme.com remote-zone gk.south.acme.com direct
zone access gk.mwest.acme.com remote-zone gk.west.acme.com direct </pre>
|

The zone access is then defined, which describes how this zone can be accessed from other gateways and gatekeepers in this network. The Midwestern zone can be approached by the Western gatekeeper and the corresponding gateways in a direct signaling mode. The same properties are applied for the other gateways and other gatekeepers within the network.
|-
|

zone access gk.mwest.acme.com default proxied
|

The next command, '''zone access gk.mwest.acme.com default proxied''', forces the remaining gatekeepers, beyond the first five defined, to use a proxied mode. This protects the gatekeeper or the gateways from other gatekeepers that are not authorized to approach this site.
|-
|

<pre>zone access gk.hopoff.acme.com remote-zone gk.neast.acme.com direct
zone access gk.hopoff.acme.com remote-zone gk.south.acme.com direct
zone access gk.hopoff.acme.com remote-zone gk.west.acme.com direct
zone access gk.hopoff.acme.com remote-zone gk.mwest.acme.com direct </pre>
|

Similar to the previous definitions, these commands define the access rights for the hop-off zone. Since there are five zones all together, the user needs to define the rights between all of the zones.
|-
|

zone access gk.hopoff.acme.com default proxied
|

For this particular gatekeeper, because there are two local zones, the commands must be repeated for both the Midwestern and the hop-off zones.
|-
|

<pre>zone prefix gk.mwest.acme.com 224*
zone prefix gk.mwest.acme.com 312*
zone prefix gk.mwest.acme.com 630*
zone prefix gk.west.acme.com 213*
zone prefix gk.west.acme.com 310*
zone prefix gk.west.acme.com 323*
zone prefix gk.hopoff.acme.com * </pre>
|

'''Zone prefix''' is a routing command, and the next six commands define how routing is set up in this network. Area code 224, or the NPA 224, resides in the Midwestern zone, as do 312 and 630. NPA 213 resides in the Western zone, as well as 310 and 323.

The last prefix command specifies that any other NPA that does not match the first six commands resides in the hop-off gatekeeper. Depending on the requirements of a specific network, all gatekeepers may have identical zone prefix commands. If routing is based on NPA and NXX, however, the local gatekeeper will have more granularity and other gatekeepers can point to the local gatekeeper for the entire NPA.
|-
|

gw-type-prefix 1#* default-technology
|

The next command, '''gw-type-prefix 1#* default-technology''', specifies the default technology. The tech prefix is 1#. This simplifies the design, since all gateways will use the same tech prefix and there is no reason to put the tech prefix command in the dial-peer statements.
|-
|

no shutdown
|

The last command, '''no shutdown''', enables the gatekeeper service on this particular platform.
|}

=== Show Commands-Chicago ===
Show commands for the Chicago gatekeeper are illustrated below. Two zones are defined: gk.hopoff.acme.com and gk.midwest.acme.com. Two gateways have already registered with this gatekeeper. The first one is the first gateway in the hop-off zone and the other one is the first Chicago gateway. The zone gatekeeper routing table is very similar to the Los Angeles gatekeeper because we are using NPA-based routing only.

Show commands:

<pre>gk1.mwest.acme.com#show gatekeeper endpoints

GATEKEEPER ENDPOINT REGISTRATION
================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type F
--------------- ----- --------------- ----- --------- ---- -
10.10.248.1 1720 10.10.248.1 3361 gk.hopoff.acme.co VOIP-GW
H323-ID: gw1.hopoff.acme.com
10.10.249.1 1720 10.10.249.1 6883 gk.mwest.acme.com VOIP-GW
H323-ID: ch1-gw.mwest.acme.com
gk1.mwest.acme.com#show gatekeeper zone prefix
ZONE PREFIX TABLE
=================
GK-NAME E164-PREFIX
------- -----------
gk.west.acme.com 213*
gk.mwest.acme.com 224*
gk.west.acme.com 310*
gk.mwest.acme.com 312*
gk.west.acme.com 323*
gk.mwest.acme.com 630*
gk.hopoff.acme.com * </pre>

== Call Flow ==
Once the network is configured, calls follow the flow illustrated in [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: RAS Message Exchange|Figure: RAS Message Exchange]]. A call travels from Phone A to Phone B. Upon receipt of the setup message from phone A, Gateway A consults with Gatekeeper A through an ARQ (1) message. Since Gatekeeper A knows Gatekeeper B services Phone B, Gatekeeper A forwards that message via LRQ (2) to Gatekeeper B. Gatekeeper B then consults its routing table and returns an LCF (3) back to Gatekeeper A. Then Gatekeeper A responds back to Gateway A with an ACF (4).

===== Figure: RAS Message Exchange=====

[[image:Design_Guide-26-2-5.jpg]]

On admission is confirmed, Gateway A sends a H.225 (5) setup message to Gateway B which then sends out an ARQ (6) to Gatekeeper B to request permission to answer the call. The gatekeeper confirms that it can terminate the call and replies with an ACF (7) message. This ACF message, allows Gateway B to acknowledge the setup message with an H.225 connect (8). At that point, H.245 exchange occurs (9), which opens up the logical channels, and the call proceeds (10).
== Debug Commands ==
Gateways and gatekeepers have debug commands that can be used as troubleshooting tools. Ideally, the network should come up, but engineers prefer to test the network to ensure that it works as planned. The output generated by the debug commands enable them to do this. [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: RAS Messages with IP Addresses|Figure: RAS Messages with IP Addresses]] demonstrates a call going from the Chicago gateway to the LA gateway. The diagram also contains the IP addresses to make the debugs clearer.

===== Figure: RAS Messages with IP Addresses=====

[[image:Design_Guide-26-2-6.jpg]]

== Originating Gateway Debugs ==
In [[Internetwork Design Guide -- Large-Scale H.323 Network Design for Service Providers#Figure: RAS Messages with IP Addresses|Figure: RAS Messages with IP Addresses]], '''debug RAS''' has been enabled, as the call travels from Chicago to Los Angeles. Upon receipt of the message from the PSTN, the Chicago gateway sends out an ARQ to its gatekeeper in the Midwestern zone. The Midwestern zone then consults the Los Angeles gatekeeper and returns an ACF. Upon receipt of the ACF, the originating gateway in Chicago contacts the terminating gateway in Los Angeles and the call is initiated.

<pre>ch1-gw.mwest.acme.com# debug ras
ch1-gw.mwest.acme.com#
RASLibRASSendARQ ARQ (seq# 3365) sent to 10.10.253.10
RASLibRASRecvData ACF (seq# 3365) rcvd from 10.10.253.10
The Call is in progress .... and once the caller or the callee hang up the call will be disconnected with the DRQ and the DCF messages.
RASlibras_sendto msg length 55 from 10.10.253.56 to 10.10.253.10
RASLibRASSendDRQ DRQ (seq# 3366) sent to 10.10.253.10
RASLibRASRecvData successfully rcvd message of length 3 from 10.10.253.101719
RASLibRASRecvData DCF (seq# 3366) rcvd from 10.10.253.10 </pre>

== Originating Gatekeeper Debugs ==
Next we will look at the gatekeeper in Chicago. Events are triggered when the gatekeeper receives an ARQ from the originating gateway and proceeds to the gatekeeper, sending an LRQ to the terminating gatekeeper, and then responding with an ACF to the originating gateway.

<pre>gk1.mwest.acme.com# debug ras
gk1.mwest.acme.com#
RASLibRASRecvData ARQ (seq# 3365) rcvd from [10.10.253.56883] on sock [0x60AF038C]
RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
RASlibras_sendto msg length 61 from 10.10.253.107624 to 10.10.254.101719
RASLibRASSendLRQ LRQ (seq# 5) sent to 10.10.254.10
RASLibRASRecvData successfully rcvd message of length 160 from 10.10.254.101719
RASLibRASRecvData LCF (seq# 5) rcvd from [10.10.254.101719] on sock [0x60A7A68C] RASLibparse_lcf_nonstd
LCF Nonstd decode succeeded, remlen = 0
RASlibras_sendto msg length 16 from 10.10.253.101719 to 10.10.249.16883
RASLibRASSendACF ACF (seq# 3365) sent to 10.10.249.1
The call is in progress
RASLibRASRecvData successfully rcvd message of length 55 from 10.10.253.56883
RASLibRASRecvData DRQ (seq# 3366) rcvd from [10.10.253.56883] on sock [0x60AF038C]
RASlibras_sendto msg length 3 from 10.10.253.101719 to 10.10.249.16883
RASLibRASSendDCF DCF (seq# 3366) sent to 10.10.249.1
RASLibRASRecvData successfully rcvd message of length 124 from 10.10.253.56883 </pre>

== Terminating Gatekeeper Debugs ==
Next, we look at the same call from the terminating gatekeeper's point of view. This call started in the gateway in Chicago, which approached the gatekeeper in Chicago. The gatekeeper in Chicago referenced its routing table and consulted the gatekeeper in Los Angeles.

An LRQ message was received by the gatekeeper in Los Angeles. The Los Angeles gatekeeper references its routing table and returns an LCF message with an IP address off the gateway in the Western zone. This information, via the originating gatekeeper in Chicago, progresses to the originating gateway. The originating gateway then sends a setup message to the gateway in LA to terminate the call.

Upon receipt of the setup message, the Los Angeles gateway consults its gatekeeper (the terminating gatekeeper) with an ARQ message. The gatekeeper responds to the ARQ message with an ACF allowing it to accept the call. After the call is in progress, DRQ and the DCF messages tear down the call.

<pre>gk1.west.acme.com# debug ras
gk1.west.acme.com#
RASLibRASRecvData LRQ (seq# 5) rcvd from [10.10.253.107624] on sock [0x60A014FC]
RASlibras_sendto msg length 160 from 10.10.254.101719 to 10.10.253.107624
RASLibRASSendLCF LCF (seq# 5) sent to 10.10.253.10
RASLibRASRecvData successfully rcvd message of length 72 from 10.10.254.54461
RASLibRASRecvData ARQ (seq# 3426) rcvd from [10.10.254.54461] on sock [0x60A014FC]
RASlibras_sendto msg length 16 from 10.10.254.101719 to 10.10.250.14461
RASLibRASSendACF ACF (seq# 3426) sent to 10.10.250.1
RASLibRASRecvData successfully rcvd message of length 120 from 10.10.254.54461 from 10.10.254.54461

The Call is in progress ....

RASLibRASRecvData successfully rcvd message of length 55 from 10.10.254.54461
RASLibRASRecvData DRQ (seq# 3428) rcvd from [10.10.254.54461] on sock [0x60A014FC]
RASlibras_sendto msg length 3 from 10.10.254.101719 to 10.10.250.14461
RASLibRASSendDCF DCF (seq# 3428) sent to 10.10.250.1 </pre>
== Terminating Gateway Debugs ==
The job of the terminating gateway is much simpler than that of the gatekeeper. In this example, an ARQ is sent from the terminating gateway to the terminating gatekeeper. This is triggered by the setup message sent by the originating gateway to this gateway.

The gatekeeper confirms the admission with an admission confirmation or an ACF message and, once the call is in progress, the DRQ and the DCF messages, again, tear down the call properly.

<pre>la1-gw.west.acme.com# debug ras
RASLibRASSendARQ ARQ (seq# 3426) sent to 10.10.254.10
RASLibRASRecvData ACF (seq# 3426) rcvd from [10.10.254.10]

The call is in progress ....

RASLibRASSendDRQ DRQ (seq# 3428) sent to 10.10.254.10
RASLibRASRecvData DCF (seq# 3428) rcvd from [10.10.254.101719] </pre>
== Upcoming Scalability Improvement Features ==
Cisco is planning a number of improvements that will help make VoIP networks even more scalable. Current networks create a full mesh between all of the gatekeepers. Each gatekeeper needs to know about every other gatekeeper in the network, which can be tedious and burdensome as the network grows.

With LRQ forwarding, Cisco is enabling a directory gatekeeper or super-gatekeeper. With a directory gatekeeper, individual gatekeepers do not need to know about other gatekeepers. Instead, a gatekeeper consults its routing table, which provides a default route to a directory gatekeeper. This directory gatekeeper is more knowledgeable about the topology of the network and can forward messages onto the right egress gatekeeper. The egress gatekeeper can then contact the originating gatekeeper to complete the call. This feature is referred to as LRQ forwarding, and is in the Cisco IOS 12.0(3)T gatekeeper images.

Another improvement available in the Cisco IOS 12.0(4)XH timeframe will allow a gatekeeper to individually select a gateway. Today, with an NPA dialing plan, the egress gateway is selected only based upon the entire NPA. As ISPs scale their networks, however, they will terminate their T1s into individual rate centers. To terminate calls into rate centers, a single gatekeeper must be able to identify one gateway that can terminate that call without picking up the intra-LATA toll charges. With new gateway preference commands, a gatekeeper can instruct a specific gateway to handle a call based on rate centers.

Also scheduled for Cisco IOS 12.0(4)XH is the resource availability indicator (RAI) message, which will allow a gateway to inform the gatekeeper that it is short on resources (such as DS0s and DSPs). Once the gatekeeper receives the RAI, it will not assign a call to a gateway that is low on resources. Other important enhancements in Cisco IOS 12.0(4)XH include H.323V.2 support and the transport of DTMF tones over H.245 channels.
== Summary ==
For service providers considering the deployment of VoIP services, H.323 provides a proven, dependable solution today. The Cisco implementation of H.323 offers an easy migration strategy to begin deploying additional revenue-generating services to compete in the New World of telecommunications.

[[Category: Internetwork Design]]

Internetwork Design Guide -- UDP Broadcast Flooding

2012-10-16T21:35:14Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="udp broacast flooding, internetworking"></meta>
A broadcast is a data packet that is destined for multiple hosts. Broadcasts can occur at the data link layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical network. Network layer broadcasts are sent to all hosts attached to a particular logical network. The Transmission Control Protocol/Internet Protocol (TCP/IP) supports the following types of broadcast packets:
* All ones-By setting the broadcast address to all ones (255.255.255.255), all hosts on the network receive the broadcast.
* Network-By setting the broadcast address to a specific network number in the network portion of the IP address and setting all ones in the host portion of the broadcast address, all hosts on the specified network receive the broadcast. For example, when a broadcast packet is sent with the broadcast address of 131.108.255.255, all hosts on network number 131.108 receive the broadcast.
* Subnet-By setting the broadcast address to a specific network number and a specific subnet number, all hosts on the specified subnet receive the broadcast. For example, when a broadcast packet is set with the broadcast address of 131.108.4.255, all hosts on subnet 4 of network 131.108 receive the broadcast.

Because broadcasts are recognized by all hosts, a significant goal of router configuration is to control unnecessary proliferation of broadcast packets. Cisco routers support two kinds of broadcasts: directed and flooded. A directed broadcast is a packet sent to a specific network or series of networks, whereas a flooded broadcast is a packet sent to every network. In IP internetworks, most broadcasts take the form of User Datagram Protocol (UDP) broadcasts.

Although current IP implementations use a broadcast address of all ones, the first IP implementations used a broadcast address of all zeros. Many of the early implementations do not recognize broadcast addresses of all ones and fail to respond to the broadcast correctly. Other early implementations forward broadcasts of all ones, which causes a serious network overload known as a broadcast storm. Implementations that exhibit these problems include systems based on versions of BSD UNIX prior to Version 4.3.

In the brokerage community, applications use UDP broadcasts to transport market data to the desktops of traders on the trading floor. This case study gives examples of how brokerages have implemented both directed and flooding broadcast schemes in an environment that consists of Cisco routers and Sun workstations. [[Internetwork Design Guide -- UDP Broadcast Flooding#Figure: Topology that requires UDP broadcast forwarding|Figure: Topology that requires UDP broadcast forwarding]] illustrates a typical topology. Note that the addresses in this network use a 10-bit netmask of 255.255.255.192.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

===== Figure: Topology that requires UDP broadcast forwarding=====

[[image:nd201901.jpg]]

In [[Internetwork Design Guide -- UDP Broadcast Flooding#Figure: Topology that requires UDP broadcast forwarding|Figure: Topology that requires UDP broadcast forwarding]], UDP broadcasts must be forwarded from a source segment (Feed network) to many destination segments that are connected redundantly. Financial market data, provided, for example, by Reuters, enters the network through the Sun workstations connected to the Feed network and is disseminated to the TIC servers. The TIC servers are Sun workstations running Teknekron Information Cluster software. The Sun workstations on the trader networks subscribe to the TIC servers for the delivery of certain market data, which the TIC servers deliver by means of UDP broadcasts. The two routers in this network provide redundancy so that if one router becomes unavailable, the other router can assume the load of the failed router without intervention from an operator. The connection between each router and the Feed network is for network administration purposes only and does not carry user traffic.

Two different approaches can be used to configure Cisco routers for forwarding UDP broadcast traffic: IP helper addressing and UDP flooding. This case study analyzes the advantages and disadvantages of each approach.

{{note|Regardless of whether you implement IP helper addressing or UDP flooding, you must use the '''ip forward-protocol udp''' global configuration command to enable the UDP forwarding. By default, the '''ip forward-protocol udp''' command enables forwarding for ports associated with the following protocols: Trivial File Transfer Protocol, Domain Name System, Time service, NetBIOS Name Server, NetBIOS Datagram Server, Boot Protocol, and Terminal Access Controller Access Control System. To enable forwarding for other ports, you must specify them as arguments to the '''ip forward-protocol udp''' command.}}

== Implementing IP Helper Addressing ==
IP helper addressing is a form of static addressing that uses directed broadcasts to forward local and all-nets broadcasts to desired destinations within the internetwork.

To configure helper addressing, you must specify the '''ip helper-address '''command on every interface on every router that receives a broadcast that needs to be forwarded. On Router A and Router B, IP helper addresses can be configured to move data from the TIC server network to the trader networks. IP helper addressing in not the optimal solution for this type of topology because each router receives unnecessary broadcasts from the other router, as shown in [[Internetwork Design Guide -- UDP Broadcast Flooding#Figure: Flow of UDP packets from routers to trader networks using IP helper addressing|Figure: Flow of UDP packets from routers to trader networks using IP helper addressing]]

===== Figure: Flow of UDP packets from routers to trader networks using IP helper addressing=====

[[image:nd201902.jpg]]

In this case, Router A receives each broadcast sent by Router B three times, one for each segment, and Router B receives each broadcast sent by Router A three times, one for each segment. When each broadcast is received, the router must analyze it and determine that the broadcast does not need to be forwarded. As more segments are added to the network, the routers become overloaded with unnecessary traffic, which must be analyzed and discarded.

When IP helper addressing is used in this type of topology, no more than one router can be configured to forward UDP broadcasts (unless the receiving applications can handle duplicate broadcasts). This is because duplicate packets arrive on the trader network. This restriction limits redundancy in the design and can be undesirable in some implementations.

To send UDP broadcasts bidirectionally in this type of topology, a second '''ip helper address''' command must be applied to every router interface that receives UDP broadcasts. As more segments and devices are added to the network, more''' ip helper address''' commands are required to reach them, so the administration of these routers becomes more complex over time. Note, too, that bidirectional traffic in this topology significantly impacts router performance.

Although IP helper addressing is well-suited to nonredundant, nonparallel topologies that do not require a mechanism for controlling broadcast loops, in view of these drawbacks, IP helper addressing does not work well in this topology. To improve performance, network designers considered several other alternatives:
* Setting the broadcast address on the TIC servers to all ones (255.255.255.255)-This alternative was dismissed because the TIC servers have more than one interface, causing TIC broadcasts to be sent back onto the Feed network. In addition, some workstation implementations do not allow all ones broadcasts when multiple interfaces are present.
* Setting the broadcast address of the TIC servers to the major net broadcast (164.53.0.0)-This alternative was dismissed because the Sun TCP/IP implementation does not allow the use of major net broadcast addresses when the network is subnetted.
* Eliminating the subnets and letting the workstations use Address Resolution Protocol (ARP) to learn addresses-This alternative was dismissed because the TIC servers cannot quickly learn an alternative route in the event of a primary router failure.

With alternatives eliminated, the network designers turned to a simpler implementation that supports redundancy without duplicating packets and that ensures fast convergence and minimal loss of data when a router fails: UDP flooding.

== Implementing UDP Flooding ==
UDP flooding uses the spanning tree algorithm to forward packets in a controlled manner. Bridging is enabled on each router interface for the sole purpose of building the spanning tree. The spanning tree prevents loops by stopping a broadcast from being forwarded out an interface on which the broadcast was received. The spanning tree also prevents packet duplication by placing certain interfaces in the blocked state (so that no packets are forwarded) and other interfaces in the forwarding state (so that packets that need to be forwarded are forwarded).

To enable UDP flooding, the router must be running software that supports transparent bridging and bridging must be configured on each interface that is to participate in the flooding. If bridging is not configured for an interface, the interface will receive broadcasts, but the router will not forward those broadcasts and will not use that interface as a destination for sending broadcasts received on a different interface.

{{note|Releases prior to Cisco Internetwork Operating System (Cisco IOS) Software Release 10.2 do not support flooding subnet broadcasts.}}

When configured for UPD flooding, the router uses the destination address specified by the '''ip broadcast-address''' command on the output interface to assign a destination address to a flooded UDP datagram. Thus, the destination address might change as the datagram propagates through the network. The source address, however, does not change.

With UDP flooding, both routers shown in [[Internetwork Design Guide -- UDP Broadcast Flooding#Figure: Topology that requires UDP broadcast forwarding|Figure: Topology that requires UDP broadcast forwarding]] use a spanning tree to control the network topology for the purpose of forwarding broadcasts. The key commands for enabling UDP flooding are as follows:

bridge group protocol protocol
ip forward-protocol spanning tree
bridge-group group input-type-list access-list-number

The '''bridge protocol''' command can specify either the '''dec '''keyword (for the DEC spanning-tree protocol) or the''' ieee '''keyword (for the IEEE Ethernet protocol). All routers in the network must enable the same spanning tree protocol. The '''ip forward-protocol spanning tree''' command uses the database created by the '''bridge protocol '''command. Only one broadcast packet arrives at each segment, and UDP broadcasts can traverse the network in both directions.

{{note|Because bridging is enabled only to build the spanning tree database, use access lists to prevent the spanning tree from forwarding non-UDP traffic. The configuration examples later in this article configure an access list that blocks all bridged packets.}}

To determine which interface forwards or blocks packets, the router configuration specifies a path cost for each interface. The default path cost for Ethernet is 100. Setting the path cost for each interface on Router B to 50 causes the spanning tree algorithm to place the interfaces in Router B in forwarding state. Given the higher path cost (100) for the interfaces in Router A, the interfaces in Router A are in the blocked state and do not forward the broadcasts. With these interface states, broadcast traffic flows through Router B. If Router B fails, the spanning tree algorithm will place the interfaces in Router A in the forwarding state, and Router A will forward broadcast traffic.

With one router forwarding broadcast traffic from the TIC server network to the trader networks, it is desirable to have the other forward unicast traffic. For that reason, each router enables the ICMP Router Discovery Protocol (IRDP), and each workstation on the trader networks runs the '''irdp''' daemon. On Router A, the '''preference''' keyword sets a higher IRDP preference than does the configuration for Router B, which causes each '''irdp''' daemon to use Router A as its preferred default gateway for unicast traffic forwarding. Users of those workstations can use '''netstat -rn''' to see how the routers are being used.

On the routers, the '''holdtime''', '''maxadvertinterval''', and '''minadvertinterval''' keywords reduce the advertising interval from the default so that the''' irdp''' daemons running on the hosts expect to see advertisements more frequently. With the advertising interval reduced, the workstations will adopt Router B more quickly if Router A becomes unavailable. With this configuration, when a router becomes unavailable, IRDP offers a convergence time of less than one minute.

IRDP is preferred over the Routing Information Protocol (RIP) and default gateways for the following reasons:
* RIP takes longer to converge, typically from one to two minutes.
* Configuration of Router A as the default gateway on each Sun workstation on the trader networks would allow those Sun workstations to send unicast traffic to Router A, but would not provide an alternative route if Router A becomes unavailable.

{{note|Some workstation vendors include an '''irdp''' daemon with their operating systems. Source code for an '''irdp''' daemon is available by anonymous FTP at ''ftp.cisco.com''.}}

[[Internetwork Design Guide -- UDP Broadcast Flooding#Figure: Data flow with UDP flooding and IRDP|Figure: Data flow with UDP flooding and IRDP]] shows how data flows when the network is configured for UDP flooding.

===== Figure: Data flow with UDP flooding and IRDP=====

[[image:nd201903.jpg]]

{{note|This topology is broadcast intensive-broadcasts sometimes consume 20 percent of the Ethernet bandwidth. However, this is a favorable percentage when compared to the configuration of IP helper addressing, which, in the same network, causes broadcasts to consume up to 50 percent of the Ethernet bandwidth.}}

If the hosts on the trader networks do not support IRDP, the Hot Standby Routing Protocol (HSRP) can be used to select which router will handle unicast traffic. HSRP allows the standby router to take over quickly if the primary router becomes unavailable. For information about configuring HSRP, see [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Using HSRP for Fault-Tolerant IP Routing|Using HSRP for Fault-Tolerant IP Routing]].

By default, the router performs UDP flooding by process switching the UDP packets. To increase performance on AGS+ and Cisco 7000 series routers, enable fast switching of UDP packets by using the following command:

ip forward-protocol turbo-flood

{{note|Turbo flooding increases the amount of processing that is done at interrupt level, which increases the CPU load on the router. Turbo flooding may not be appropriate on routers that are already under high CPU load or that must also perform other CPU-intensive activities.}}

The following commands configure UDP flooding on Router A. Because this configuration does not specify a lower path cost than the default and because the configuration of Router B specifies a lower cost than the default with regard to UDP flooding, Router A acts as a backup to Router B. Because this configuration specifies an IRDP preference of 100 and because Router B specifies a IRDP preference of 90 (ip irdp preference 90), Router A forwards unicast traffic from the trader networks, and Router B is the backup for unicast traffic forwarding.

<pre> !Router A:
ip forward-protocol spanning-tree
ip forward-protocol udp 111
ip forward-protocol udp 3001
ip forward-protocol udp 3002
ip forward-protocol udp 3003
ip forward-protocol udp 3004
ip forward-protocol udp 3005
ip forward-protocol udp 3006
ip forward-protocol udp 5020
ip forward-protocol udp 5021
ip forward-protocol udp 5030
ip forward-protocol udp 5002
ip forward-protocol udp 1027
ip forward-protocol udp 657
!
interface ethernet 0
ip address 200.200.200.61 255.255.255.0
ip broadcast-address 200.200.200.255
no mop enabled
!
interface ethernet 1
ip address 164.53.7.61 255.255.255.192
ip broadcast-address 164.53.7.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 100
bridge-group 1
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 2
ip address 164.53.8.61 255.255.255.192
ip broadcast-address 164.53.8.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 100
bridge-group 1
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 3
ip address 164.53.9.61 255.255.255.192
ip broadcast-address 164.53.9.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 100
bridge-group 1
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 4
ip address 164.53.10.61 255.255.255.192
ip broadcast-address 164.53.10.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 100
bridge-group 1
bridge-group 1 input-type-list 201
no mop enabled
!
router igrp 1
network 164.53.0.0
!
ip name-server 255.255.255.255
snmp-server community public RW
snmp-server host 164.53.7.15 public
bridge 1 protocol dec
bridge 1 priority 255
access-list 201 deny 0xFFFF 0x0000</pre>

The following commands configure UDP flooding on Router B. Because this configuration specifies a lower path cost than the default ('''bridge-group 1 path-cost 50''') and because the configuration of Router A accepts the default, Router B forwards UDP packets. Because this configuration specifies an IRDP preference of 90 ('''ip irdp preference 90)''' and because Router A specifies a IRDP preference of 100, Router B acts as the backup for Router A for forwarding unicast traffic from the trader networks.

<pre>!Router B
ip forward-protocol spanning-tree
ip forward-protocol udp 111
ip forward-protocol udp 3001
ip forward-protocol udp 3002
ip forward-protocol udp 3003
ip forward-protocol udp 3004
ip forward-protocol udp 3005
ip forward-protocol udp 3006
ip forward-protocol udp 5020
ip forward-protocol udp 5021
ip forward-protocol udp 5030
ip forward-protocol udp 5002
ip forward-protocol udp 1027
ip forward-protocol udp 657
!
interface ethernet 0
ip address 200.200.200.62 255.255.255.0
ip broadcast-address 200.200.200.255
no mop enabled
!
interface ethernet 1
ip address 164.53.7.62 255.255.255.192
ip broadcast-address 164.53.7.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 90
bridge-group 1
bridge-group 1 path-cost 50
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 2
ip address 164.53.8.62 255.255.255.192
ip broadcast-address 164.53.8.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 90
bridge-group 1
bridge-group 1 path-cost 50
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 3
ip address 164.53.9.62 255.255.255.192
ip broadcast-address 164.53.9.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 90
bridge-group 1
bridge-group 1 path-cost 50
bridge-group 1 input-type-list 201
no mop enabled
!
interface ethernet 4
ip address 164.53.10.62 255.255.255.192
ip broadcast-address 164.53.10.63
ip irdp
ip irdp maxadvertinterval 60
ip irdp minadvertinterval 45
ip irdp holdtime 60
ip irdp preference 90
bridge-group 1
bridge-group 1 path-cost 50
bridge-group 1 input-type-list 201
no mop enabled
!
router igrp 1
network 164.53.0.0
!
ip name-server 255.255.255.255
snmp-server community public RW
snmp-server host 164.53.7.15 public
bridge 1 protocol dec
bridge 1 priority 255
access-list 201 deny 0xFFFF 0x0000 </pre>

{{note|In releases prior to Cisco IOS Software Release 10.2, the spanning tree algorithm prevented the forwarding of local broadcast addresses, but allowed the forwarding of local secondary addresses. For that reason, when running a release prior to Cisco IOS Software Release 10.2, a secondary address must be specified for each Ethernet interface that will forward local broadcast address packets. The secondary address is used to forward packets, whereas the primary address is never used. In such configurations, the secondary addresses are assigned to an Interior Gateway Routing Protocol (IGRP) group instead of the primary address.}}

== Summary ==
Although IP helper addressing is useful in networks that do not require redundancy, when configured in networks that feature redundancy, IP helper addressing results in packet duplication that severely reduces router and network performance.

By configuring UDP flooding, one router forwards UDP traffic without burdening the second router with duplicate packets. By dedicating one router to the task of forwarding UDP traffic, the second router becomes available for forwarding unicast traffic. At the same time, because each router is configured as the backup for the other router, redundancy is maintained; if either router fails, the other router can assume the work of the failed router without intervention from an operator. When compared with IP helper addressing, UDP flooding makes the most efficient use of router resources.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing

2012-10-16T21:33:51Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="hsrp, internetworking"></meta>
This case study examines Cisco's Hot Standby Routing Protocol (HSRP), which provides automatic router backup when you configure it on Cisco routers that run the Internet Protocol (IP) over Ethernet, Fiber Distributed Date Interface (FDDI), and Token Ring local-area networks (LANs). HSRP is compatible with Novell's Internetwork Packet Exchange (IPX), AppleTalk, and Banyan VINES, and it is compatible with DECnet and Xerox Network Systems (XNS) in certain configurations.

{{note|Banyan VINES serverless clients do not respond well to topology changes (regardless of whether HSRP is configured). This case study describes the effect of topology changes in networks that include Banyan VINES serverless clients.}}

For IP, HSRP allows one router to automatically assume the function of the second router if the second router fails. HSRP is particularly useful when the users on one subnet require continuous access to resources in the network.

Consider the network shown in [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: A typical WAN|Figure: A typical WAN]]. Router A is responsible for handling packets between the Tokyo segment and the Paris segment, and Router B is responsible for handling packets between the Tokyo segment and the New York segment. If the connection between Routers A and C goes down or if either router becomes unavailable, fast converging routing protocols, such as the Enhanced Interior Gateway Routing Protocol (Enhanced IGRP) and Open Shortest Path First (OSPF) can respond within seconds so that Router B is prepared to transfer packets that would otherwise have gone through Router A.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

===== Figure: A typical WAN=====

[[image:nd202201.jpg]]

However, in spite of fast convergence, if the connection between Router A and Router C goes down, or if either router becomes unavailable, the user Pat on the Tokyo segment might not be able to communicate with the user Marceau even after the routing protocol has converged. That's because IP hosts, such as Pat's workstation, usually do not participate in routing protocols. Instead, they are configured statically with the address of a single router, such as Router A. Until someone manually modifies the configuration of Pat's host to use the address of Router B instead of Router A, Pat cannot communicate with Marceau.

Some IP hosts use proxy Address Resolution Protocol (ARP) to select a router. If Pat's workstation were running proxy ARP, it would send an ARP request for the IP address of Marceau's workstation. Router A would reply on behalf of Marceau's workstation and would give to Pat's workstation its own media access control (MAC) address (instead of the IP address of Marceau's workstation). With proxy ARP, Pat's workstation behaves as if Marceau's workstation were connected to the same segment of the network as Pat's workstation. If Router A fails, Pat's workstation will continue to send packets destined for Marceau's workstation to the MAC address of Router A even though those packets have nowhere to go and are lost. Pat either waits for ARP to acquire the MAC address of Router B by sending another ARP request or reboots the workstation to force it to send an ARP request. In either case, for a significant period of time, Pat cannot communicate with Marceau-even though the routing protocol has converged, and Router B is prepared to transfer packets that would otherwise go through Router A.

Some IP hosts use the Routing Information Protocol (RIP) to discover routers. The drawback of using RIP is that it is slow to adapt to changes in the topology. If Pat's workstation is configured to use RIP, 3 to 10 minutes might elapse before RIP makes another router available.

Some newer IP hosts use the ICMP Router Discovery Protocol (IRDP) to find a new router when a route becomes unavailable. A host that runs IRDP listens for hello multicast messages from its configured router and uses an alternate router when it no longer receives those hello messages. If Pat's workstation were running IRDP, it would detect that Router A is no longer sending hello messages and would start sending its packets to Router B.

For IP hosts that do not support IRDP, Cisco's HSRP provides a way to keep communicating when a router becomes unavailable. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not physically exist; instead, it represents the common target for routers that are configured to provide backup to each other. [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: HSRP addressing on the Tokyo segment|Figure: HSRP addressing on the Tokyo segment]] shows the Tokyo segment of the WAN as it might be configured for HSRP. Each actual router is configured with the MAC address and the IP network address of the virtual router.

===== Figure: HSRP addressing on the Tokyo segment=====

[[image:nd202202.jpg]]

In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: HSRP addressing on the Tokyo segment|Figure: HSRP addressing on the Tokyo segment]], the MAC address of the virtual router is 0000.0c07.ac01. When you configure HSRP, the router automatically selects one of the virtual MAC addresses from a range of addresses in the Cisco IOS software that is within the range of Cisco's MAC address block. Ethernet and FDDI LANs use one of the preassigned MAC addresses as a virtual MAC address. Token Ring LANs use a functional address as a virtual MAC address.

In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: HSRP addressing on the Tokyo segment|Figure: HSRP addressing on the Tokyo segment]], instead of configuring the hosts on network 192.1.1.0 with the IP address of Router A, they are configured with the IP address of the virtual router as their default router. When Pat's workstation sends packets to Marceau's workstation on the Paris segment, it sends them to the MAC address of the virtual router.

In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: HSRP addressing on the Tokyo segment|Figure: HSRP addressing on the Tokyo segment]], Router A is configured as the active router. It is configured with the IP address and MAC address of the virtual router and sends any packets addressed to the virtual router out interface 1 to the Paris segment. As the standby router, Router B is also configured with the IP address and MAC address of the virtual router. If for any reason Router A stops transferring packets, the routing protocol converges, and Router B assumes the duties of Router A and becomes the active router. That is, Router B now responds to the virtual IP address and the virtual MAC address. Pat's workstation continues to use the IP address of the virtual router to address packets destined for Marceau's workstation, which Router B receives and sends to the Paris segment via the New York segment. Until Router A resumes operation, HSRP allows Router B to provide uninterrupted service to the users on the Tokyo segment that need to communicate with users on the Paris segment. While it is the active router, Router B continues to perform its normal function: handling packets between the Tokyo segment and the New York segment.

HSRP also works when the hosts are configured for proxy ARP. When the active HSRP router receives an ARP request for a host that is not on the local LAN, the router replies with the MAC address of the virtual router. If the active router becomes unavailable or its connection to the remote LAN goes down, the router that becomes the active router receives packets addressed to the virtual router and transfers them accordingly.

{{note|You can configure HSRP on any Cisco router that is running Cisco Internetwork Operating System (Cisco IOS) Software Release 10.0 or later. If you configure HSRP for one Cisco router on a Token Ring LAN, all Cisco routers on that LAN must run Cisco IOS Software Release 10.0 or later. Cisco IOS Software Releases 10.2(9), 10.3(6), and 11.0(2) allow standby IP addresses to respond to ping requests. Cisco Software Release 11.0(3)(1) provides improved support for the use of secondary IP addresses with HSRP.}}

== Understanding How HSRP Works ==
HSRP uses a priority scheme to determine which HSRP-configured router is to be the default active router. To configure a router as the active router, you assign it a priority that is higher than the priority of all the other HSRP-configured routers. The default priority is 100, so if you configure just one router to have a higher priority, that router will be the default active router.

HSRP works by the exchange of multicast messages that advertise priority among HSRP-configured routers. When the active router fails to send a hello message within a configurable period of time, the standby router with the highest priority becomes the active router. The transition of packet- forwarding functions between routers is completely transparent to all hosts on the network.

HSRP-configured routers exchange three types of multicast messages:
* Hello-The hello message conveys to other HSRP routers the router's HSRP priority and state information. By default, an HSRP router sends hello messages every three seconds.
* Coup-When a standby router assumes the function of the active router, it sends a coup message.
* Resign-A router that is the active router sends this message when it is about to shut down or when a router that has a higher priority sends a hello message.

At any time, HSRP-configured routers are in one of the following states:
* Active-The router is performing packet-transfer functions.
* Standby-The router is prepared to assume packet-transfer functions if the active router fails.
* Speaking and listening-The router is sending and receiving hello messages.
* Listening-The router is receiving hello messages.

{{note|When configured on AGS, AGS+, and Cisco 7000 series routers, HSRP takes advantage of special hardware features that are not available on other Cisco routers. This means that HSRP operates in a slightly different way on these routers. For an example, see the "[[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Using HSRP with Routed Protocols|Using HSRP with Routed Protocols]]" section later in this article.}}

== Configuring HSRP ==
[[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: Example of a network configured for HSRP|Figure: Example of a network configured for HSRP]] shows the topology of an IP network in which two routers are configured for HSRP.

===== Figure: Example of a network configured for HSRP=====

[[image:nd202203.jpg]]

All hosts on the network are configured to use the IP address of the virtual router (in this case, 1.0.0.3) as the default gateway. The command for configuring the default gateway depends on the host's operating system, TCP/IP implementation, and configuration.

{{note|The configurations shown in this case study use the Enhanced IGRP routing protocol. HSRP can be used with any routing protocol supported by the Cisco IOS software. Some configurations that use HSRP still require a routing protocol to converge when a topology change occurs. The standby router becomes active, but connectivity does not occur until the protocol converges.}}

The following is the configuration for Router A:

<pre>hostname RouterA
!
interface ethernet 0
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 1 priority 110
standby 1 authentication denmark
standby 1 timers 5 15
!
interface ethernet 1
ip address 3.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 3.0.0.0 </pre>

The following is the configuration for Router B:

<pre>hostname RouterB
!
interface ethernet 0
ip address 1.0.0.2 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 1 authentication denmark
standby 1 timers 5 15
!
interface ethernet 1
ip address 2.0.0.2 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 2.0.0.0 </pre>

The '''standby ip''' interface configuration command enables HSRP and establishes 1.0.0.3 as the IP address of the virtual router. The configurations of both routers include this command so that both routers share the same virtual IP address. The 1 establishes Hot Standby group 1. (If you do not specify a group number, the default is group 0.) The configuration for at least one of the routers in the Hot Standby group must specify the IP address of the virtual router; specifying the IP address of the virtual router is optional for other routers in the same Hot Standby group.

The '''standby preempt''' interface configuration command allows the router to become the active router when its priority is higher than all other HSRP-configured routers in this Hot Standby group. The configurations of both routers include this command so that each router can be the standby router for the other router. The 1 indicates that this command applies to Hot Standby group 1. If you do not use the '''standby preempt''' command in the configuration for a router, that router cannot become the active router.

The '''standby priority''' interface configuration command sets the router's HSRP priority to 110, which is higher than the default priority of 100. Only the configuration of Router A includes this command, which makes Router A the default active router. The 1 indicates that this command applies to Hot Standby group 1.

The '''standby authentication''' interface configuration command establishes an authentication string whose value is an unencrypted eight-character string that is incorporated in each HSRP multicast message. This command is optional. If you choose to use it, each HSRP-configured router in the group should use the same string so that each router can authenticate the source of the HSRP messages that it receives. The "1" indicates that this command applies to Hot Standby group 1.

The '''standby timers''' interface configuration command sets the interval in seconds between hello messages (called the hello time) to five seconds and sets the duration in seconds that a router waits before it declares the active router to be down (called the hold time) to eight seconds. (The defaults are three and 10 seconds, respectively.) If you decide to modify the default values, you must configure each router to use the same hello time and hold time. The "1" indicates that this command applies to Hot Standby group 1.

{{note|There can be up to 255 Hot Standby groups on any Ethernet or FDDI LAN. There can be no more than three Hot Standby groups on any Token Ring LAN.}}

== Configuring Multiple Hot Standby Groups ==
Multigroup HSRP (MHSRP) is an extension of HSRP that allows a single router interface to belong to more than one Hot Standby group. MHSRP requires the use of Cisco IOS Software Release 10.3 or later and is supported only on routers that have special hardware that allows them to associate an Ethernet interface with multiple unicast Media Access Control (MAC) addresses. These routers are the AGS and AGS+ routers and any router in the Cisco 7000 series. The special hardware allows you to configure a single interface in an AGS, AGS+, or Cisco 7000 series router so that the router is the backup router for more than one Hot Standby group, as shown in [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: Example of hot standby groups|Figure: Example of hot standby groups]].

===== Figure: Example of hot standby groups=====

[[image:nd202204.jpg]]

In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: Example of hot standby groups|Figure: Example of hot standby groups]], the Ethernet interface 0 of Router A belongs to group 1. Ethernet interface 0 of Router B belongs to groups 1, 2, and 3. The Ethernet interface 0 of Router C belongs to group 2, and the Ethernet interface 0 of Router D belongs to group 3. When you establish groups, you might want to align them along departmental organizations. In this case, group 1 might support the Engineering Department, group 2 might support the Manufacturing Department, and group 3 might support the Finance Department.

Router B is configured as the active router for groups 1 and 2 and as the standby router for group 3. Router D is configured as the active router for group 3. If Router D fails for any reason, Router B will assume the packet-transfer functions of Router D and will maintain the ability of users in the Finance Department to access data on other subnets. The following is the configuration for Router A:

<pre>hostname RouterA
!
interface ethernet 0
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.5
standby authentication sclara
!
interface serial 0
ip address 2.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 2.0.0.0 </pre>

The following is the configuration for Router B, which must be an AGS, AGS+, or Cisco 7000 series router:

<pre>hostname RouterB
!
interface ethernet 0
ip address 1.0.0.2 255.0 0.0
standby 1 ip 1.0.0.5
standby 1 priority 110
standby 1 preempt
standby 1 authentication sclara
standby 2 ip 1.0.0.6
standby 2 priority 110
standby 2 preempt
standby 2 authentication mtview
standby 3 ip 1.0.0.7
standby 3 preempt
standby 3 authentication svale
!
interface serial 0
ip address 3.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 3.0.0.0 </pre>

The following is the configuration for Router C:

<pre>hostname RouterC
!
interface ethernet 0
ip address 1.0.0.3 255.0 0.0
standby 2 ip 1.0.0.6
standby 2 authentication mtview
!
interface serial 0
ip address 4.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 4.0.0.0 </pre>

The following is the configuration for Router D:

<pre> hostname RouterD
!
interface ethernet 0
ip address 1.0.0.4 255.0 0.0
standby 3 ip 1.0.0.7
standby 1 priority 110
standby 1 preempt
standby 3 authentication svale
!
interface serial 0
ip address 4.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 5.0.0.0 </pre>

=== Interface Tracking ===
For both HSRP and MHSRP, you can use the tracking feature to adjust the Hot Standby priority of a router based on whether certain of the router's interfaces are available. When a tracked interface becomes unavailable, the HSRP priority of the router is decreased. You can use tracking to automatically reduce the likelihood that a router that already has an unavailable key interface will become the active router. To configure tracking, use the '''standby track''' interface configuration command. [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: A network with tracking configured|Figure: A network with tracking configured]] shows a network for which tracking is configured.

===== Figure: A network with tracking configured=====

[[image:nd202205.jpg]]

In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: A network with tracking configured|Figure: A network with tracking configured]], Router A is configured as the active router. Routers B and C are configured as standby routers for Router A. The following is the configuration for Router A:

<pre>hostname RouterA
!
interface ethernet 0
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.4
standby 1 preempt
standby 1 priority 110
standby authentication microdot
!
interface serial 0
ip address 2.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 3.0.0.0 </pre>

The '''standby ip''' interface configuration command enables HSRP and establishes 1.0.0.4 as the IP address of the virtual router. The "1" establishes Hot Standby group 1. The '''standby preempt''' interface configuration command allows Router A to become the active router when its priority is higher than all other HSRP-configured routers in the Hot Standby group.

The '''standby priority''' interface configuration command sets the router's HSRP priority to 110, which is highest priority assigned to the three routers in this example. Because Router A has the highest priority, it is the active router under normal operation. The following is the configuration for Router B:

<pre>hostname RouterB
!
interface ethernet 0
ip address 1.0.0.2 255.0 0.0
standby 1 ip 1.0.0.4
standby 1 preempt
standby 1 priority 105
standby track serial 0
standby 1 authentication microdot
interface serial 0
ip address 3.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 2.0.0.0 </pre>

The '''standby preempt''' interface configuration command allows Router B to become the active router immediately if its priority is highest, even before the current active router fails. The '''standby priority''' interface configuration command specifies a priority of 105 (lower than the priority of Router A and higher than the priority of Router C), so Router B is a standby router.

The''' standby track''' interface configuration command causes Ethernet interface 0 to track serial interface 0. If serial interface 0 becomes unavailable, the priority of Router B is reduced by 10 (the default). The following is the configuration for Router C:

<pre>hostname RouterC
!
interface ethernet 0
ip address 1.0.0.3 255.0 0.0
standby 1 ip 1.0.0.4
standby 1 preempt
standby 1 priority
standby track serial 0
standby 1 authentication microdot
!
interface serial 0
ip address 4.0.0.1 255.0.0.0
!
router eigrp 1
network 1.0.0.0
network 4.0.0.0 </pre>

The '''standby preempt''' interface configuration command allows Router C to become the active router if its priority is highest when the active router fails. The '''standby priority''' interface configuration command does not specify a priority, so its priority is 100 (the default).

If Router A becomes unavailable and if serial interface 0 on Router B is available, Router B (with its priority of 105) will become the active router. However, if serial interface 0 on Router B becomes unavailable before Router A becomes unavailable, the HSRP priority of Router B will be reduced from 105 to 95. If Router A then becomes unavailable, Router C (whose priority is 100) will become the active router.
=== Load Sharing ===
You can use HSRP or MHSRP when you configure load sharing. In [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Figure: Load sharing example|Figure: Load sharing example]], half of the workstations on the LAN are configured for Router A, and half of the workstations are configured for Router B.

===== Figure: Load sharing example=====

[[image:nd202206.jpg]]

The following is a partial configuration for Router A:

<pre>hostname RouterA
!
interface ethernet 0
ip address 1.0.0.1 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 priority 110
standby 1 preempt
standby 2 ip 1.0.0.4
standby 2 preempt </pre>

The following is a partial configuration for Router B:

<pre>hostname RouterB
!
interface ethernet 0
ip address 1.0.0.2 255.0.0.0
standby 1 ip 1.0.0.3
standby 1 preempt
standby 2 ip 1.0.0.4
standby 2 priority 110
standby 2 preempt </pre>

Together, the configuration files for Routers A and B establish two Hot Standby groups. For group 1, Router A is the default active router, and Router B is the standby router. For group 2, Router B is the default active router, and Router A is the standby router. During normal operation, the two routers share the IP traffic load. When either router becomes unavailable, the other router becomes active and assumes the packet-transfer functions of the router that is unavailable. The''' standby preempt''' interface configuration commands are necessary so that if a router goes down and then comes back up, preemption occurs and restores load sharing.
== Using HSRP with Routed Protocols ==
This section describes the interaction between HSRP and the following routed protocols:
* [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#AppleTalk, Banyan VINES, and Novell IPX|AppleTalk, Banyan VINES, and Novell IPX]]
* [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#DECnet and XNS|DECnet and XNS]]
=== AppleTalk, Banyan VINES, and Novell IPX ===
You can configure HSRP in networks that, in addition to IP, run AppleTalk, Banyan VINES, and Novell IPX. AppleTalk and Novell IPX continue to function when the standby router becomes the active router, but they take time to adapt to topology changes. In general, AppleTalk hosts discover a new active router in less than 30 seconds. Novell 4.x hosts discover a new active router in 10 seconds, on average. Novell 2.x or Novell 3.x hosts might require more time to adapt.

{{note|Regardless of whether HSRP is configured, Banyan VINES does not respond well to topology changes. When HSRP is configured, the effect of a topology change varies, depending on the type of router that becomes the active router.}}

When the active router becomes unavailable, or its connection to the network goes down, all Banyan VINES sessions that rely on that router stop and must be reinitiated. If an AGS, AGS+, or Cisco 7000 series router becomes the active router, Banyan VINES traffic flowing through that router is not affected as it changes from standby to active. That is because these routers have special hardware that allows them to have more than one MAC address at the same time. If the router that becomes the active router is not an AGS, AGS+, or Cisco 7000 series router, Banyan VINES traffic flowing through that router pauses and resumes after no more than 90 seconds while the router changes from standby to active.

Regardless of which type of router becomes the active router, any Banyan VINES serverless clients that obtained their network-layer address from the unavailable router might need to reboot to obtain another network-layer address.
=== DECnet and XNS ===
DECnet and XNS are compatible with HSRP and MHSRP over Ethernet, FDDI, and Token Ring on the Cisco 7000 and Cisco 7500 routers. Some constraints apply when HSRP and MHSRP are configured on other routers, such as the Cisco 2500, Cisco 3000, Cisco 4000, and Cisco 4500 series routers, which do not have the hardware required to support multiple MAC addresses. [[Internetwork Design Guide -- Using HSRP for Fault-Tolerant IP Routing#Table: HSRP and MHSRP Compatibility with DECnet and XNS|Table: HSRP and MHSRP Compatibility with DECnet and XNS]] identifies the supported and unsupported combinations.

===== Table: HSRP and MHSRP Compatibility with DECnet and XNS=====

{| border = 1
|-
!'''Protocol Combination per Interface'''

!'''Cisco2500'''

!'''Cisco3000'''

!'''Cisco 4000'''

!'''Cisco 4500'''

!'''Cisco7000'''

!'''Cisco 7500'''
|-
|

MHSRP with or without DECnet or XNS
|

No
|

No
|

No
|

No
|

Yes
|

Yes
|-
|

HSRP without DECnet or XNS
|

Yes
|

Yes
|

Yes
|

Yes
|

Yes
|

Yes
|-
|

HSRP with DECnet or XNS
|

No
|

No
|

No
|

No
|

Yes
|

Yes
|}

== Summary ==
HSRP and MHSRP provide fault-tolerant routing of IP packets for networks that require nonstop access by hosts on all segments to resources on all segments. To provide fault tolerance, HSRP and MHSRP require a routing protocol that converges rapidly, such as Enhanced Interior Gateway Routing Protocol (Enhanced IGRP). A fast-converging protocol ensures that router state changes propagate fast enough to make the transition from standby to active mode transparent to network users.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- RIP and OSPF Redistribution

2012-10-16T21:33:23Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="rip, ospf, redistribution, internetworking"></meta>
This case study addresses the issue of integrating Routing Information Protocol (RIP) networks with Open Shortest Path First (OSPF) networks. Most OSPF networks also use RIP to communicate with hosts or to communicate with portions of the internetwork that do not use OSPF. Cisco supports both the RIP and OSPF protocols and provides a way to exchange routing information between RIP and OSPF networks. This case study provides examples of how to complete the following phases in redistributing information between RIP and OSPF networks, including the following topics:
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#Configuring a RIP Network|Configuring a RIP Network]]
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#Adding OSPF to the Center of a RIP Network|Adding OSPF to the Center of a RIP Network]]
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#Adding OSPF Areas|Adding OSPF Areas]]
* [[Internetwork Design Guide -- RIP and OSPF Redistribution#Setting Up Mutual Redistribution|Setting Up Mutual Redistribution]]

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Configuring a RIP Network ==
[[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: A RIP network|Figure: A RIP network]] illustrates a RIP network. Three sites are connected with serial lines. The RIP network uses a Class B address and an 8-bit subnet mask. Each site has a contiguous set of network numbers.

===== Figure: A RIP network=====

[[image:nd201401.jpg]]

[[Internetwork Design Guide -- RIP and OSPF Redistribution#Table: RIP Network Address Assignments|Table: RIP Network Address Assignments]] lists the network address assignments for the RIP network, including the network number, subnet range, and subnet masks. All interfaces indicate network 130.10.0.0; however, the specific address includes the subnet and subnet mask. For example, serial interface 0 on Router C has an IP address of 130.10.63.3 with a subnet mask of 255.255.255.0.

===== Table: RIP Network Address Assignments=====

{| border = 1
|-
!'''Network Number'''

!'''Subnets'''

!'''Subnet Masks'''
|-
|

130.10.0.0
|

'''Site A:''' 8 through 15
|

255.255.255.0
|-
|

130.10.0.0
|

'''Site B:''' 16 through 23
|

255.255.255.0
|-
|

130.10.0.0
|

'''Site C:''' 24 through 31
|

255.255.255.0
|-
|

130.10.0.0
|

'''Serial Backbone:''' 62 through 64
|

255.255.255.0
|}

===== Configuration File Examples =====
The following commands in the configuration file for Router A determine the IP address for each interface and enable RIP on those interfaces:

<pre> interface serial 0
ip address 130.10.62.1 255.255.255.0
interface serial 1
ip address 130.10.63.1 255.255.255.0
interface ethernet 0
ip address 130.10.8.1 255.255.255.0
interface tokenring 0
ip address 130.10.9.1 255.255.255.0
router rip
network 130.10.0.0 </pre>

The following commands in the configuration file for Router B determine the IP address for each interface and enable RIP on those interfaces:

<pre> interface serial 0
ip address 130.10.62.2 255.255.255.0
interface serial 1
ip address 130.10.64.2 255.255.255.0
interface ethernet 0
ip address 130.10.17.2 255.255.255.0
interface tokenring 0
ip address 130.10.16.2 255.255.255.0
router rip
network 130.10.0.0 </pre>

The following commands in the configuration file for Router C determine the IP address for each interface and enable RIP on those interfaces:

<pre>interface serial 0
ip address 130.10.63.3 255.255.255.0
interface serial 1
ip address 130.10.64.3 255.255.255.0
interface ethernet 0
ip address 130.10.24.3 255.255.255.0
router rip
network 130.10.0.0 </pre>

== Adding OSPF to the Center of a RIP Network ==
A common first step in converting a RIP network to OSPF is to add backbone routers that run both RIP and OSPF, while the remaining network devices run RIP. These backbone routers are OSPF autonomous system boundary routers. Each autonomous system boundary router controls the flow of routing information between OSPF and RIP. In [[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: RIP network with OSPF at the center|Figure: RIP network with OSPF at the center]], Router A is configured as the autonomous system boundary router.

===== Figure: RIP network with OSPF at the center=====

[[image:nd201402.jpg]]

RIP does not need to run between the backbone routers; therefore, RIP is suppressed on Router A with the following commands:

<pre>router rip
passive-interface serial 0
passive-interface serial 1 </pre>

The RIP routes are redistributed into OSPF by all three routers with the following commands:

<pre>router ospf 109
redistribute rip subnets </pre>

The subnets keyword tells OSPF to redistribute all subnet routes. Without the subnets keyword, only networks that are not subnetted will be redistributed by OSPF. Redistributed routes appear as external type 2 routes in OSPF. Each RIP domain receives information about networks in other RIP domains and in the OSPF backbone area from the following commands that redistribute OSPF routes into RIP:

<pre>router rip
redistribute ospf 109 match internal external 1 external 2
default-metric 10 </pre>

The '''redistribute''' command uses the ospf keyword to specify that OSPF routes are to be redistributed into RIP. The keyword '''internal''' indicates the OSPF intra-area and interarea routes: External 1 is the external route type 1, and external 2 is the external route type 2. Because the command in the example uses the default behavior, these keywords may not appear when you use the '''write terminal''' or '''show configuration''' commands.

Because metrics for different protocols cannot be directly compared, you must specify the default metric in order to designate the cost of the redistributed route used in RIP updates. All routes that are redistributed will use the default metric.

In [[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: RIP network with OSPF at the center|Figure: RIP network with OSPF at the center]], there are no paths directly connecting the RIP clouds. However, in typical networks, these paths, or "back doors," frequently exist, allowing the potential for feedback loops. You can use access lists to determine the routes that are advertised and accepted by each router. For example, access list 11 in the configuration file for Router A allows OSPF to redistribute information learned from RIP only for networks 130.10.8.0 through 130.10.15.0:

<pre>router ospf 109
redistribute rip subnet
distribute-list 11 out rip
access-list 11 permit 130.10.8.0 0.0.7.255
access-list 11 deny 0.0.0.0 255.255.255.255</pre>

These commands prevent Router A from advertising networks in other RIP domains onto the OSPF backbone, thereby preventing other boundary routers from using false information and forming a loop.
===== Configuration File Examples =====
The full configuration for Router A follows:

<pre> interface serial 0
ip address 130.10.62.1 255.255.255.0
interface serial 1
ip address 130.10.63.1 255.255.255.0
interface ethernet 0
ip address 130.10.8.1 255.255.255.0
interface tokenring 0
ip address 130.10.9.1 255.255.255.0
!
router rip
default-metric 10
network 130.10.0.0
passive-interface serial 0
passive-interface serial 1
redistribute ospf 109 match internal external 1 external 2
!
router ospf 109
network 130.10.62.0 0.0.0.255 area 0
network 130.10.63.0 0.0.0.255 area 0
redistribute rip subnets
distribute-list 11 out rip
!
access-list 11 permit 130.10.8.0 0.0.7.255
access-list 11 deny 0.0.0.0 255.255.255.255 </pre>

The full configuration for Router B follows:

<pre>interface serial 0
ip address 130.10.62.2 255.255.255.0
interface serial 1
ip address 130.10.64.2 255.255.255.0
interface ethernet 0
ip address 130.10.17.2 255.255.255.0
interface tokenring 0
ip address 130.10.16.2 255.255.255.0
!
router rip
default-metric 10
network 130.10.0.0
passive-interface serial 0
passive-interface serial 1
redistribute ospf 109 match internal external 1 external 2
!
router ospf 109
network 130.10.62.0 0.0.0.255 area 0
network 130.10.64.0 0.0.0.255 area 0
redistribute rip subnets
distribute-list 11 out rip
access-list 11 permit 130.10.16.0 0.0.7.255
access-list 11 deny 0.0.0.0 255.255.255.255 </pre>

The full configuration for Router C follows:

<pre>interface serial 0
ip address 130.10.63.3 255.255.255.0
interface serial 1
ip address 130.10.64.3 255.255.255.0
interface ethernet 0
ip address 130.10.24.3 255.255.255.0
!
router rip
default-metric 10
!
network 130.10.0.0
passive-interface serial 0
passive-interface serial 1
redistribute ospf 109 match internal external 1 external 2
!
router ospf 109
network 130.10.63.0 0.0.0.255 area 0
network 130.10.64.0 0.0.0.255 area 0
redistribute rip subnets
distribute-list 11 out rip
access-list 11 permit 130.10.24.0 0.0.7.255
access-list 11 deny 0.0.0.0 255.255.255.255 </pre>
== Adding OSPF Areas ==
[[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: Configuring route summarization between OSPF areas|Figure: Configuring route summarization between OSPF areas]] illustrates how each of the RIP clouds can be converted into an OSPF area. All three routers are area border routers. Area border routers control network information distribution between OSPF areas and the OSPF backbone. Each router keeps a detailed record of the topology of its area and receives summarized information from the other area border routers on their respective areas.

===== Figure: Configuring route summarization between OSPF areas=====

[[image:nd201403.jpg]]

[[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: Configuring route summarization between OSPF areas|Figure: Configuring route summarization between OSPF areas]] also illustrates variable-length subnet masks (VLSMs). VLSMs use different size network masks in different parts of the network for the same network number. VLSM conserves address space by using a longer mask in portions of the network that have fewer hosts. [[Internetwork Design Guide -- RIP and OSPF Redistribution#Table: OSPF Address Assignments|Table: OSPF Address Assignments]] lists the network address assignments for the network, including the network number, subnet range, and subnet masks. All interfaces indicate network 130.10.0.0.

===== Table: OSPF Address Assignments=====

{| border = 1
|-
!Network Number
!Subnets
!Subnet Masks
|-
|

130.10.0.0
|

'''Area 0:''' 62 through 64
|

255.255.255.248
|-
|

130.10.0.0
|

'''Area 1:''' 8 through 15
|

255.255.255.0
|-
|

130.10.0.0
|

'''Area 2:''' 16 through 23
|

255.255.255.0
|-
|

130.10.0.0
|

'''Area 3:''' 24 through 31
|

255.255.255.0
|}

To conserve address space, a mask of 255.255.255.248 is used for all the serial lines in area 0. If an area contains a contiguous range of network numbers, an area border router uses the''' range''' keyword with the '''area''' command to summarize the routes that are injected into the backbone:

<pre>router ospf 109
network 130.10.8.0 0.0.7.255 area 1
area 1 range 130.10.8.0 255.255.248.0</pre>

These commands allow Router A to advertise one route, 130.10.8.0 255.255.248.0, which covers all subnets in Area 1 into Area 0. Without the''' range''' keyword in the '''area''' command, Router A would advertise each subnet individually; for example, one route for 130.10.8.0 255.255.255.0, one route for 130.10.9.0 255.255.255.0, and so forth.

Because Router A no longer needs to redistribute RIP routes, the '''router rip''' command can now be removed from the configuration file; however, it is common in some environments for hosts to use RIP to discover routers. When RIP is removed from the routers, the hosts must use an alternative technique to find the routers. Cisco routers support the following alternatives to RIP:
* ICMP Router Discovery Protocol (IRDP)-This technique is illustrated in the example at the end of this section. IRDP is the recommended method for discovering routers. The '''ip irdp''' command enables IRDP on the router. Hosts must also run IRDP.
* Proxy Address Resolution Protocol (ARP)-If the router receives an ARP request for a host that is not on the same network as the ARP request sender, and if the router has the best route to that host, the router sends an ARP reply packet giving the router's own local data link address. The host that sent the ARP request then sends its packets to the router, which forwards them to the intended host. Proxy ARP is enabled on routers by default. Proxy ARP is transparent to hosts.
===== Configuration File Examples =====
The full configuration for Router A follows:

<pre>interface serial 0
ip address 130.10.62.1 255.255.255.248
interface serial 1
ip address 130.10.63.1 255.255.255.248
interface ethernet 0
ip address 130.10.8.1 255.255.255.0
ip irdp
interface tokenring 0
ip address 130.10.9.1 255.255.255.0
ip irdp
router ospf 109
network 130.10.62.0 0.0.0.255 area 0
network 130.10.63.0 0.0.0.255 area 0
network 130.10.8.0 0.0.7.255 area 1
area 1 range 130.10.8.0 255.255.248.0 </pre>

The full configuration for Router B follows:

<pre>interface serial 0
ip address 130.10.62.2 255.255.255.248
interface serial 1
ip address 130.10.64.2 255.255.255.248
interface ethernet 0
ip address 130.10.17.2 255.255.255.0
ip irdp
interface tokenring 0
ip address 130.10.16.2 255.255.255.0
ip irdp
router ospf 109
network 130.10.62.0 0.0.0.255 area 0
network 130.10.64.0 0.0.0.255 area 0
network 130.10.16.0 0.0.7.255 area 2
area 2 range 130.10.16.0 255.255.248.0 </pre>

The full configuration for Router C follows:

<pre>interface serial 0
ip address 130.10.63.2 255.255.255.248
interface serial 1
ip address 130.10.64.2 255.255.255.248
interface ethernet 0
ip address 130.10.24.3 255.255.255.0
ip irdp
router ospf 109
network 130.10.63.0 0.0.0.255 area 0
network 130.10.64.0 0.0.0.255 area 0
network 130.10.24.0 0.0.0.255 area 3
area 3 range 130.10.24.0 255.255.248.0</pre>

== Setting Up Mutual Redistribution ==
It is sometimes necessary to accommodate more complex network topologies such as independent RIP and OSPF clouds that must perform mutual redistribution. In this scenario, it is critically important to prevent potential routing loops by filtering routes. The router in [[Internetwork Design Guide -- RIP and OSPF Redistribution#Figure: Mutual redistribution between RIP and OSPF networks|Figure: Mutual redistribution between RIP and OSPF networks]] is running both OSPF and RIP.

===== Figure: Mutual redistribution between RIP and OSPF networks=====

[[image:nd201404.jpg]]

With the following commands, OSPF routes will be redistributed into RIP. You must specify the default metric to designate the cost of the redistributed route in RIP updates. All routes redistributed into RIP will have this default metric.

<pre>! passive interface subcommand from previous example is left out for clarity!
router rip
default-metric 10
network 130.10.0.0
redistribute ospf 109 </pre>

It is a good practice to strictly control which routes are advertised when redistribution is configured. In the following example, a '''distribute-list out''' command causes RIP to ignore routes coming from the OSPF that originated from the RIP domain.

<pre>router rip
distribute-list 10 out ospf 109
!
access-list 10 deny 130.10.8.0 0.0.7.255
access-list 10 permit 0.0.0.0 255.255.255.255 </pre>
===== Router A =====
The full configuration for the router follows:

<pre>interface serial 0
ip add 130.10.62.1 255.255.255.0
!
interface serial 1
ip add 130.10.63.1 255.255.255.0
!
interface ethernet 0
ip add 130.10.8.1 255.255.255.0
!
interface tokenring 0
ip add 130.10.9.1 255.255.255.0
!
router rip
default-metric 10
network 130.10.0.0
passive-interface serial 0
passive-interface serial 1
redistribute ospf 109
distribute-list 10 out ospf 109
!
router ospf 109
network 130.10.62.0 0.0.0.255 area 0
network 130.10.63.0 0.0.0.255 area 0
redistribute rip subnets
distribute-list 11 out rip
!
access-list 10 deny 130.10.8.0 0.0.7.255
access-list 10 permit 0.0.0.0 255.255.255.255
access-list 11 permit 130.10.8.0 0.0.7.255
access-list 11 deny 0.0.0.0 255.255.255.255 </pre>
== Summary ==
Because it is common for OSPF and RIP to be used together, it is important to use the practices described here in order to provide functionality for both protocols on an internetwork. You can configure autonomous system boundary routers that run both RIP and OSPF and redistribute RIP routes into the OSPF and vice versa. You can also create OSPF areas using area border routers that provide route summarizations. Use VLSM to conserve address space.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- SNA Host Configuration for SDLC Networks

2012-10-16T21:32:46Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="sdlc, internetworking"></meta>

This article outlines router implementation information related to the following topics:
* Front-end processor (FEP) configuration for SDLC links
* 3174 SDLC configuration worksheet example

[[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: 3x74 SDLC Point-to-Point Connection Support for AGS+, MGS, and CGS DCE Appliques|Table: 3x74 SDLC Point-to-Point Connection Support for AGS+, MGS, and CGS DCE Appliques]] outlines 3x74 SDLC point-to-point connection support for AGS+, MGS, and CGS DCE appliques.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

===== Table: 3x74 SDLC Point-to-Point Connection Support for AGS+, MGS, and CGS DCE Appliques=====

{| border = 1
|-
!'''Controller Type'''

!'''RS-232 DCE'''

!'''RS-232 NRZI/DCE'''
|-
|

'''3274 1st Generation'''
* 3274-1C
|

Supported
|

Supported
|-
|

'''3274 2nd Generation'''
* 3274-21C
|

Not tested
|

Supported
|-
|

'''3274 3rd Generation'''
* 3274-31C
* 3274-51C
|

Supported

Supported
|

Not tested

Not tested
|-
|

'''3274 4th Generation'''

3274-41C

3274-61C

Telex 274

Telex 1274
|

Need to tie DSR and DTR together on CU side, break DSR to router

Same as 3274-41C

Supported

Supported
|

Not tested

Supported

Not tested

Not tested
|-
|

DCA/IRMA 3274 emulation for DOS workstations

DEC SNA gateway

RS 6000 multiprotocol adapter
|

Not tested

Not tested

Not tested
|

Supported

Supported

Supported
|-
|

'''3174 Subsystem CUs'''
* 3174-01R
* 3174-03R
* 3174-51R
|

Not tested

Same as 3174-01R

Same as 3174-01R
|

3174 ties pin 11 low, (-11VDC) which forces the applique into DTE mode (DCE mode is set when pin 11 is set high)

Same as 3174-01R

Same as 3174-01R
|-
|

'''3174 Establishment CUs'''
* 3174-11R
* 3174-13R
* 3174-61R
* 3174-91R
* Telex 1174
|

Not tested

Same as 3174-11R

Same as 3174-11R

Same as 3174-11R

Supported
|

Supported

Not tested

Not tested

Supported

Not tested
|}

== FEP Configuration for SDLC Links ==

[[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: FEP SDLC Configuration Sample GROUP Parameter Listing and Definitions|Table: FEP SDLC Configuration Sample GROUP Parameter Listing and Definitions]] through [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: FEP SDLC Configuration Sample LU Parameter Listing and Definitions|Table: FEP SDLC Configuration Sample LU Parameter Listing and Definitions]] present relevant parameter definitions for an FEP configured to operate within a router-based environment. These parameters are configured as part of the system generation process associated with the Network Control Program (NCP) on an IBM host.

===== Table: FEP SDLC Configuration Sample GROUP Parameter Listing and Definitions=====

{| border = 1
|-
!Parameter
!Sample Value
!Description and Implementation Notes
|-
|

LNCTL
|

SDLC
|

Line control parameter that specifies link protocol.
|-
|

REPLYTO
|

2
|

T1 timer; this timer specifies the reply timeout value for LINEs in this GROUP.
|}

===== Table: FEP SDLC Configuration Sample LINE Parameter Listing and Definitions=====

{| border = 1
|-
!Parameter
!Sample Value
!Description and Implementation Notes
|-
|

ADDRESS
|

(001,HALF)
|

The value 001 is the physical LINE interface address of the FEP. The second parameter specifies whether half- or full-duplex data transfer within the FEP is used. It also effects the DUPLEX parameter: If FULL is specified here, DUPLEX defaults to FULL and attempts to modify this characteristic are ignored.
|-
|

DUPLEX
|

HALF
|

This parameter specifies whether the communication line and modem constitute a half-duplex or full-duplex facility. If HALF is specified, the RTS modem signal is activated only when sending data. If FULL is specified, RTS always remains active. Refer to the ADDRESS parameter in this table.
|-
|

NRZI
|

YES
|

Encoding for this line; options are NRZ or NRZI.
|-
|

RETRIES
|

(6,5,3)
|

Number of retries when REPLYTO expires. Entry options: (''m, t, n'') where ''m'' = number of retries, ''t'' = pause in seconds between retry cycles, and ''n'' = number of retry cycles to repeat. This example would retry six times-pausing the value of the REPLYTO between each RETRY (two seconds per [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: FEP SDLC Configuration Sample GROUP Parameter Listing and Definitions|Table: FEP SDLC Configuration Sample GROUP Parameter Listing and Definitions]]), pause five seconds, and repeat this sequence three times for a total of 63 seconds. At the end of this period, the session is terminated.
|-
|

PAUSE
|

2
|

The delay time in milliseconds between poll cycles. The cycle extends from the time NCP polls the first entry in the service order table to the moment polling next begins at the same entry. During this pause, any data available to send to the end station is sent. If end stations have data to send when polled and the time to send the data extends beyond the PAUSE parameter, the next poll cycle begins immediately.
|}

===== Table: FEP SDLC Configuration Sample PU Parameter Listing and Definitions=====

{| border = 1
|-
!Parameter
!Sample Value
!Description and Implementation Notes
|-
|

ADDR
|

C1
|

SDLC address of secondary end station.
|-
|

MAXDATA
|

265
|

Maximum amount of data in bytes (including headers) that the UP can receive in one data transfer; that is, one entire PIU or a PIU segment.
|-
|

MAXOUT
|

7
|

Maximum number of unacknowledged frames that NCP can have outstanding before requesting a response from the end station.
|-
|

PASSLIM
|

7
|

Maximum number of consecutive PIU or PIU segments that NCP sends at one time to the end station represented by this PU definition.
|-
|

PUTYPE
|

2
|

Specifies PU type; PU type 2 and 2.1 are both specified as PUTYPE=2.
|}

===== Table: FEP SDLC Configuration Sample LU Parameter Listing and Definitions=====

{| border = 1
|-
!Parameter
!Sample Value
!Description and Implementation Notes
|-
|

LOCADDR
|

2
|

LU address of devices connected to the end station PU.
|}

== 3174 SDLC Configuration Worksheet ==
[[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: 3174-91R Screen 1 Configuration Details|Table: 3174-91R Screen 1 Configuration Details]] through [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: 3174-91R Screen 3 Configuration Details|Table: 3174-91R Screen 3 Configuration Details]] present a configuration taken from an SDLC-connected 3174-91R cluster controller. The configuration of this 3174-91R involved three specific configuration screens. [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: 3174-91R Screen 1 Configuration Details|Table: 3174-91R Screen 1 Configuration Details]] through [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#Table: 3174-91R Screen 3 Configuration Details|Table: 3174-91R Screen 3 Configuration Details]] list the configuration line numbers, entries used, and descriptions of the configuration lines for each screen. Where applicable, extended descriptions are included for configuration entries that are relevant to the requirements of the routed internetwork.

=====Table: 3174-91R Screen 1 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
!Sample Value
!Parameter Description and Implementation Notes
|-
|

98
|
|

Online test password
|-
|

99
|

TKNRNG
|

Description field
|-
|

100
|

91R
|

Model number
|-
|

101
|

2
|

Host attachment type:
* 2 = SDLC
* 5 = SNA (channel-attached)
* 7 = Token Ring network
|}

{{note|Configuration line items 104, 313, 317, and 340 in Configuration screen 2 (refer to [[Internetwork Design Guide -- SNA Host Configuration for SDLC Networks#3174-91R Screen 2 Configuration Details|3174-91R Screen 2 Configuration Details]]) are of particular interest when configuring 3174 devices for a router-based SDLC environment. These lines specify the required SDLC address and relevant SDLC options for the cluster controller.}}

===== Table: 3174-91R Screen 2 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
! Sample Value
! Parameter Description and Implementation Notes
|-
|

104
|

C2
|

Specifies the cluster controller SDLC address. It is the same address that you configure on the router's serial line interface. It also represents the PU address of the controller. In multipoint environments, multiple SDLC addresses may be specified on a single serial interface.
|-
|

108
|

0045448
|

Serial number of the cluster controller
|-
|

110
|

0
|

MLT storage support
|-
|

116
|

0
|

Individual port assignment
|-
|

121
|

01
|

Keyboard language
|-
|

123
|

0
|

Country extended code page support
|-
|

125
|

00000000
|

Miscellaneous options (A)
|-
|

126
|

00000000
|

Miscellaneous options (B)
|-
|

127
|

00
|

RTM definition
|-
|

132
|

0000
|

Alternate base keyboard selection
|-
|

136
|

0000
|

Standard keyboard layout
|-
|

137
|

0000
|

Modified keyboard layout
|-
|

138
|

0
|

Standard keypad layout
|-
|

141
|

A
|

Magnetic character set
|-
|

150
|

0
|

Token Ring network gateway controller
|-
|

165
|

0
|

Compressed program symbols
|-
|

166
|

A
|

Attribute select keypad
|-
|

168
|

0
|

Additional extension; mode key definition
|-
|

173
|

0000
|

DFT options
|-
|

175
|

000000
|

DFT password
|-
|

179
|

000
|

Local format storage
|-
|

213
|

0
|

Between-bracket printer sharing
|-
|

215
|

45448
|

PU identification
|-
|

220
|

0
|

Alert function
|-
|

310
|

0
|

Connect dataset to line operation
|-
|

313
|

0
|

NRZ = 0; NRZI = 1
|-
|

317
|

0
|

Telecommunications facility:
* 0 = Nonswitched
* 1 = Switched (dial-up)
|-
|

318
|

0
|

Full/half speed transmission; 0 = full speed, 1 = half speed. Controls speed of modem; can be used in areas where line conditions are poor
|-
|

340
|

0
|

RTS control options:
* 0 = Controlled RTS (for LSD/MSD operation)
* 1 = Permanent RTS (improves performance)
* 2 = BSC (not valid for SDLC operation)
|-
|

365
|

0
|

X.21 switched-host DTE connection
|-
|

370
|

0
|

Maximum inbound I-frame size:
* 0 = 265 bytes
* 1 = 521 bytes (recommended for better performance)
|}

===== Table: 3174-91R Screen 3 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
!Sample Value
!Parameter Description and Implementation Notes
|-
|

500
|

0
|

Central Site Change Management (CSCM) unique
|-
|

501
|

xxxxxxxx
|

Network identifier
|-
|

503
|

xxxxxxxx
|

LU name (for CSCM)
|}

[[Category: Internetwork Design]]

Internetwork Design Guide -- SNA Host Configuration for SRB Networks

2012-10-16T21:32:21Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="sna, srb, internetworking"></meta>

When designing source-route bridging (SRB) internetworks featuring routers and IBM Systems Network Architecture (SNA) entities, you must carefully consider the configuration of SNA nodes as well as routing nodes. This article provides examples that focus on three specific SNA devices:
* Front-end processors (FEPs)
* Virtual Telecommunications Access Method (VTAM)-switched major nodes
* 3174 cluster controllers

[[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Figure: Typical SNA host environment|Figure: Typical SNA host environment]] illustrates a typical environment. [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: BUILD Definition Parameters|Table: BUILD Definition Parameters]] through [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: FEP Logical Unit (LU) Definition Parameter|Table: FEP Logical Unit (LU) Definition Parameter]] present the definition parameters for the devices shown in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Figure: Typical SNA host environment|Figure: Typical SNA host environment]].

{{note|This material provides host-related configuration information pertinent to design material provided in [[Internetwork Design Guide -- Designing SRB Internetworks#Designing SRB Internetworks|Designing SRB Internetworks]].}}

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
===== Figure: Typical SNA host environment=====

[[image:nd20c01.jpg]]

== FEP Configuration ==
The parameters listed in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: BUILD Definition Parameters|Table: BUILD Definition Parameters]] through [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: FEP Logical Unit (LU) Definition Parameter|Table: FEP Logical Unit (LU) Definition Parameter]] illustrate input to the Network Control Program (NCP) system generation process that runs in the host processor using the Network Definition Facility (NDF). The NDF is part of the ACF/NCP/System Support Program utility. The output produced by the generation process is a load module that runs in an FEP. Its typical size can be slightly under one MB to more than three MB. The ACF/NCP/System Support Program utility is also used for loading and dumping an FEP.

The following tables outline relevant parameters for generating Token Ring resources.

===== Table: BUILD Definition Parameters=====

{| border = 1
|-
!'''Parameter'''

!'''Example, Parameter Value, or Range'''

! '''Parameter Description and Implementation Notes'''
|-
|

LOCALTO
|

1.5
|

Local ring acknowledgment timer (seconds).
|-
|

REMOTTO
|

2.5
|

Remote ring acknowledgment timer (seconds).
|-
|

MAXSESS
|

5000
|

Maximum amount of sessions for all attached resources.
|-
|

MXRLINE
|

None
|

Maximum number of NTRI physical connections (Version 5.2.1 and earlier only).
|-
|

MXVLINE
|

None
|

Maximum number of NTRI logical connections (Version 5.2.1 and earlier only).
|-
|

T2TIMER
|

(localt2, remott2, N3)
|

(Version 5.R4 and later only.) Parameters specify a receiver acknowledgement/timer(T2) for local and remote Token Rings whether from peripheral or subarea nodes. Acceptable values: localt2 range is 0 to 2.0 seconds; remott2 range is 0 to 2.0 seconds; N3 range is 1 to 127 (default is 2). The values for localt2 and remott2 should be 10.0 percent of the value of the adjacent stations's T1 timer. N3 specifies the maximum number of I-frames received without sending an acknowledgment for subarea connections.
|}

The LUDRPOOL definition shown in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: LUDRPOOL Definition Parameters|Table: LUDRPOOL Definition Parameters]] specifies the number of peripheral resources required for the correct amount of control block storage to be reserved for new connections.

===== Table: LUDRPOOL Definition Parameters=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

NUMTYP2
|

None
|

Maximum is 16,000.
|-
|

NUMILU
|

None
|

Required for LU Type 2.1 devices (independent LUs).
|}

The GROUP definition shown in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: GROUP Definition Parameters|Table: GROUP Definition Parameters]] specifies group definition parameters.

===== Table: GROUP Definition Parameters=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

AUTOGEN
|

Number
|

Specifies the number of LINE/PU pairs for this group.
|-
|

COMPOWN
|

Y
|

Twin FEP backup capable resource.
|-
|

COMPSWP
|

Y
|

TIC portswap capable (hot backup).
|-
|

COMPTAD
|

Y
|

TIC capable of IPL loading FEP.
|-
|

DIAL
|

YES or NO
|

Applies to ECLTYPE parameter specifications.

YES required for (LOGICAL,PERIPHERAL); NO required for all other combinations indicated in ECLTYPE specification.
|-
|

ECLTYPE
|

(PHYSICAL,ANY)

(PHYSICAL, PERIPHERAL)

(PHYSICAL, SUBAREA)

(LOGICAL, PERIPHERAL)

(LOGICAL, SUBAREA)
|

Allows PU 4 and PU 2 devices to attach.

Allows PU 2 devices only.

Allows PU 4 devices only.

Defines devices attaching as PU 2.

Defines devices attaching as PU 4.
|-
|

LNCTL
|

SDLC
|

Required for NCP processing compatibility.
|-
|

PHYPORT
|

None
|

Required for ECLTYPE LOGICAL only; links this to a ECLTYPE PHYSICAL.
|-
|

TIMER
|

error, ras, stap, or lstap
|

Entry points for NTRI timer routines.
|}

The LINE definition shown in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: LINE Definition Parameters|Table: LINE Definition Parameters]] specifies line definition parameters.

===== Table: LINE Definition Parameters=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

ADAPTER
|

TIC1

TIC2
|

4-MB Token Ring interface

4- or 16-MB Token Ring interface
|-
|

ADDRESS
|

1088 to1095
|

Range of valid addresses for TICs; only one specified per LINE definition
|-
|

BEACTO
|

52
|

Time in seconds the ring can beacon before TIC considers it down; maximum is 600
|-
|

LOCADD
|

4000''abbbbbbb''
|

Locally administered TIC address, where ''a'' is any value from 0 to 7; and ''b'' is any integer value from 0 to 9
|-
|

LOCALTO
|

1.5
|

V5R4; same as in BUILD, but only for PU 4 (LOGICAL, SUBAREA) devices; allows granularity for individual TICs for SUBAREA connections
|-
|

REMOTTO
|

2.5
|

V5R4 parameter; same as LOCALTO; see BUILD parameters in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table 1
|-
|

T2TIMER
|

''localt2'', ''remott2'', ''N3''
|

V5.4 parameter; see BUILD parameters in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table 1[[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: |Table: ]]; can be defined in LINE definition only if a subarea node was defined in GROUP definition
|-
|

MAXTSL
|

2044 to 16732
|

Specifies maximum data in bytes that NTRI can transmit; TIC1 maximum is 2044; TIC2 maximum at TRSPEED16 is 16732
|-
|

PORTADD
|

Number
|

For association of physical to logical ECLTYPEs; matches physical or logical ECLTYPE specification
|-
|

RETRIES
|

m, t, n, ml
|

Where ''m'' = number of retries for remote ring sessions, ''t'' = pause between retry sequence, ''n'' = number of retry sequences, and ''ml'' = number of retries in a sequence for local ring sessions
|-
|

TRSPEED
|

4 or 16
|

TIC speed
|}

[[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: FEP Physical Unit (PU) Definition Parameters|Table: FEP Physical Unit (PU) Definition Parameters]] specifies physical unit (PU) definition parameters.

===== Table: FEP Physical Unit (PU) Definition Parameters=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

ADDR
|

''aa''4000''bccccccc''
|

Destination service access point (DSAP) and MAC address for the PU of the Token Ring device in the FEP, where ''aa'' = the DSAP and is a nonzero hexadecimal multiple of 4; ''>b'' = 0 to 7;
|-
|
|
|

''c'' = 0 to 9; enter 4000 as shown; only specified if ECLTYPE defined in GROUP definition is one of the following: (LOG,SUB), (PHY,SUB), (PHY,ANY)
|-
|

PUTYPE
|

1, 2, or 4
|

Depends on ECLTYPE:

For NTRI LOGICAL resources, only PUTYPE=2 is valid; for NTRI PHYSICAL resources, only PUTYPE=1 is valid

For NTRI PHYSICAL/SUBAREA LINES and PHYSICAL PERIPHERAL LINES, only PUTYPE=1 is valid. For NTRI LOGICAL PERIPHERAL LINES, only PUTYPE=2 is valid
|-
|

XID
|

YES or NO
|

Defines the capability of a PU to receive and respond to an XID while in normal disconnected mode; for NTRI LOGICAL LINES, only YES is valid; for NTRI PHYSICAL LINES, only NO is valid
|}

[[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: FEP Logical Unit (LU) Definition Parameter|Table: FEP Logical Unit (LU) Definition Parameter]] specifies logical unit (LU) definition parameters.

===== Table: FEP Logical Unit (LU) Definition Parameter=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

LOCADDR
|

0
|

Specify this response only
|}

== VTAM-Switched Major Node Definitions ==

Devices that are attached to Token Ring and communicate with an IBM host application must be defined via the VTAM access method associated with the host. These devices are seen as dial-in resources from the host side and are defined in a configuration component named Switched Major Node. Some common definitions used in network configurations are outlined in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: VBUILD Definition Parameter|Table: VBUILD Definition Parameter]] through [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: VTAM LU Definition Parameter|Table: VTAM LU Definition Parameter]].

===== Table: VBUILD Definition Parameter=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

TYPE
|

SWNET
|

Specifies a type of resource for VTAM; SWNET indicates switched major node type
|}

===== Table: VTAM PU Definition Parameters=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

IDBLK
|

017
|

Typical values:

017 = 3X74

05D = PC-base VTAM PU

0E2 = Cisco SDLLC (registered with IBM)
|-
|

IDNUM
|

''xxxxx''
|

Unique number identifying a device
|-
|

MAXOUT
|

1 to 7
|

Number of I-frames sent before acknowledgment is required
|-
|

MAXDATA
|

265
|

Indicates maximum number of bytes a PU 2 device can receive; ignored for PU 2.1, as this value is negotiable

Default for 3174 is 521
|-
|

PUTYPE
|

2
|

Only valid value
|-
|

XID
|

YES or NO
|

YES should be used for PU 2.1 devices

NO should be specified for any other device
|}

===== Table: VTAM LU Definition Parameter=====

{| border = 1
|-
! Parameter
!Example, Parameter Value, or Range
! Parameter Description and Implementation Notes
|-
|

LOCADDR
|

2 through FF
|

Logical unit (LU) addresses attached to a PU
|}

== 3174 Cluster Controller Configuration Example ==
The following configuration was taken from 3174-13R cluster controller serial number 45362 connected to a Token Ring. These entries were used with a specific 3174 running on a 4-Mbps Token Ring. The configuration of this 3174-13R involved three specific configuration screens. [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: 3174-13R Screen 1 Configuration Details|Table: 3174-13R Screen 1 Configuration Details]] through [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: 3174-13R Screen 3 Configuration Details|Table: 3174-13R Screen 3 Configuration Details]] list the configuration line numbers, entries used, and descriptions of the configuration line. When applicable, extended descriptions are included for configuration entries that are relevant to the requirements of the routed internetwork.

{{note|Of particular interest when configuring 3174 devices for a router-based SRB environment are configuration line items 106, 107, and 384 in configuration screen 2 (refer to [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Table: VTAM LU Definition Parameter|Table: VTAM LU Definition Parameter]]). These specify the required addresses and relevant Token Ring type for the cluster controller.}}

===== Table: 3174-13R Screen 1 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
! Sample Value
! Parameter Description and Implementation Notes
|-
|

98
|
|

Online test password
|-
|

99
|

TKNRNG
|

Description field
|-
|

100
|

13R
|

Model number
|-
|

101
|

7
|

Host attachment type
|}

===== Table: 3174-13R Screen 2 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
! Sample Value
! Parameter Description and Implementation Notes
|-
|

106
|

4000 2222 4444 04
|

The first 12 hexadecimal digits form the source MAC address of the cluster controller (4000 2222 4444); the last two digits are the source SAP (SSAP) for LLC2 (0x04 = SNA).
|-
|

107
|

4000 0037 4501 04
|

The first 12 hexadecimal digits form the destination MAC address of the FEP (4000 0037 4501); the last two digits are the DSAP for LLC2 (0x04 for SNA).
|-
|

108
|

0045362
|

Serial number of the cluster controller
|-
|

110
|

0
|

MLT storage support
|-
|

116
|

0
|

Individual port assignment
|-
|

121
|

01
|

Keyboard language
|-
|

123
|

0
|

Country extended code page support
|-
|

125
|

00000000
|

Miscellaneous options (A)
|-
|

126
|

00000000
|

Miscellaneous options (B)
|-
|

127
|

0 0
|

RTM definition
|-
|

132
|

0000
|

Alternate base keyboard selection
|-
|

136
|

0000
|

Standard keyboard layout
|-
|

137
|

0000
|

Modified keyboard layout
|-
|

138
|

0
|

Standard keypad layout
|-
|

141
|

A
|

Magnetic character set
|-
|

165
|

0
|

Compressed program symbols
|-
|

166
|

A
|

Attribute select keypad
|-
|

168
|

0
|

Additional extension; mode key definition
|-
|

173
|

0000
|

DFT options
|-
|

175
|

000000
|

DFT password
|-
|

179
|

000
|

Local format storage
|-
|

213
|

0
|

Between bracket printer sharing
|-
|

215
|

45362
|

PU identification
|-
|

222
|

0
|

Support for command retry
|-
|

382
|

0521
|

Maximum ring I-frame size; range of values is 265 to 2057.
|-
|

383
|

2
|

Maximum number of I-frames 3174 will transmit before awaiting an acknowledgment (transmit window size).
|-
|

384
|

0
|

Ring speed of the Token Ring network:

0 = 4 Mbps

1 = 16 Mbps normal token release

2 = 16 Mbps early token release
|}

===== Table: 3174-13R Screen 3 Configuration Details=====

{| border = 1
|-
!Configuration Line Number
! Sample Value
! Parameter Description and Implementation Notes
|-
|

500
|

0
|

CSCM unique
|-
|

501
|

TOSFNID
|

Network identifier
|-
|

503
|

TOSFCTLR
|

LU name
|}

SNA end stations implement Logical Link Control type 2 (LLC2) when attached to a local-area network (LAN). LLC2 implements the following:
* Timers
* Sequencing
* Error recovery
* Windowing
* Guaranteed delivery
* Guaranteed connection

[[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Figure: T1 timer and error recovery process for 3174|Figure: T1 timer and error recovery process for 3174]] illustrates how the T1 reply timer and error recovery operates for a 3174. Assume that the link between the two routers just failed. The following sequence characterizes the error recovery process illustrated in [[Internetwork Design Guide -- SNA Host Configuration for SRB Networks#Figure: T1 timer and error recovery process for 3174|Figure: T1 timer and error recovery process for 3174]]:
# The 3174 sends a data frame and starts its T1 timer.
# The T1 timer expires after 1.6 seconds.
# The 3174 goes into error recovery.
# The 3174 sends an LLC request (a receiver ready with the poll bit on), which requests the 3745 to immediately acknowledge this frame.
# The 3174 starts its T1 timer.
# The T1 timer expires after 1.6 seconds.

This operation is retried a total of seven times. The total elapsed time to disconnect the session is calculated as follows:

The first attempt plus seven retries multiplied by 1.6 seconds:

= 8 x 1.6 seconds

= 12.8 seconds

===== Figure: T1 timer and error recovery process for 3174=====

[[image:nd20c02.jpg]]

[[Category: Internetwork Design]]

Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks

2012-10-16T21:31:50Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="broadcast, switched lan, internetworking"></meta>

To communicate with all or part of the network, protocols use broadcast and multicast datagrams at Layer 2 of the Open Systems Interconnection (OSI) model. When a node needs to communicate with all of the network, it sends a datagram to MAC address 0xFFFFFFFF (a broadcast), which is an address to which the network interface card (NIC) of every host must respond. When a host needs to communicate with part of the network, it sends a datagram to address 0xFFFFFFFF with the leading bit of the vendor ID set to 1 (a multicast). Most NICs with that vendor ID respond to a multicast by processing the multicast to its group address.

Because switches work like bridges, they must flood all broadcast and multicast traffic. The accumulation of broadcast and multicast traffic from each device in the network is referred to as broadcast radiation.

Because the NIC must interrupt the CPU to process each broadcast or multicast, broadcast radiation affects the performance of hosts in the network. Most often, the host does not benefit from processing the broadcast or multicast-that is, the host is not the destination being sought, it doesn't care about the service that is being advertised, or it already knows about the service. High levels of broadcast radiation can noticeably degrade host performance.

The following sections describe how the desktop protocols-IP, Novell, and AppleTalk-use broadcast and multicast packets to locate hosts and advertise services, and how broadcast and multicast traffic affects the CPU performance of hosts on the network.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Using Broadcasts with IP Networks ==
There are three sources of broadcasts and multicasts in IP networks:
* Workstations-An IP workstation broadcasts an Address Resolution Protocol (ARP) request every time it needs to locate a new IP address on the network. For example, the command telnet mumble.com translates into an IP address through a Domain Name System (DNS) search, and then an ARP request is broadcast to find the actual station. Generally, IP workstations cache 10 to 100 addresses for about two hours. The ARP rate for a typical workstation might be about 50 addresses every two hours or 0.007 ARPs per second. Thus, 2000 IP end stations produce about 14 ARPs per second.
* Routers-An IP router is any router or workstation that runs RIP. Some administrators configure all workstations to run RIP as a redundancy and reachability policy. Every 30 seconds, RIP uses broadcasts to retransmit the entire RIP routing table to other RIP routers. If 2000 workstations were configured to run RIP and if 50 packets were required to retransmit the routing table, the workstations would generate 3333 broadcasts per second. Most network administrators configure a small number of routers, usually five to 10, to run RIP. For a routing table that requires 50 packets to hold it, 10 RIP routers would generate about 16 broadcasts per second.
* Multicast applications-IP multicast applications can adversely affect the performance of large, scaled, switched networks. Although multicasting is an efficient way to send a stream of multimedia (video data) to many users on a shared-media hub, it affects every user on a flat switched network. A particular packet video application can generate a seven-megabyte (MB) stream of multicast data that, in a switched network, would be sent to every segment, resulting in severe congestion.

[[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Figure: Effect of broadcast radiation on hosts in IP networks|Figure: Effect of broadcast radiation on hosts in IP networks]] shows the results of tests that Cisco conducted on the effect of broadcast radiation on a Sun SPARCstation 2 with a standard built-in Ethernet card. The SPARCstation was running SunOS version 4.1.3 without IP multicast enabled. If IP multicast had been enabled, for example, by running Solaris 2.x, multicast packets would have affected CPU performance.

===== Figure: Effect of broadcast radiation on hosts in IP networks=====

[[image:nd20e01.jpg]]

As indicated by the results shown in [[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Figure: Effect of broadcast radiation on hosts in IP networks|Figure: Effect of broadcast radiation on hosts in IP networks]], an IP workstation can be effectively shut down by broadcasts flooding the network. Although extreme, broadcast peaks of thousands of broadcasts per second have been observed during "broadcast storms." Testing in a controlled environment with a range of broadcasts and multicasts on the network shows measurable system degradation with as few as 100þ broadcasts or multicasts per second. [[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Table: Average Number of Broadcasts and Multicasts for IP Networks|Table: Average Number of Broadcasts and Multicasts for IP Networks]] shows the average and peak number of broadcasts and multicasts for IP networks ranging from 100 to 10,000 hosts per network.

===== Table: Average Number of Broadcasts and Multicasts for IP Networks=====

{| border = 1
|-
!'''Number of Hosts'''

!'''Average Percentage of CPU Loss per Host'''
|-
|

100
|

.14
|-
|

1000
|

.96
|-
|

10,000
|

9.15
|}

Although the numbers in [[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Table: Average Number of Broadcasts and Multicasts for IP Networks|Table: Average Number of Broadcasts and Multicasts for IP Networks]] might appear low, they represent an average, well-designed IP network that is not running RIP. When broadcast and multicast traffic peak due to "storm" behavior, peak CPU loss can be orders of magnitude greater than average. Broadcast "storms" can be caused by a device requesting information from a network that has grown too large. So many responses are sent to the original request that the device cannot process them, or the first request triggers similar requests from other devices that effectively block normal traffic flow on the network.
== Using Broadcasts with Novell Networks ==
Many PC-based LANs use Novell's Network Operating System (NOS) and NetWare servers. Novell technology poses the following unique scaling problems:
* NetWare servers use broadcast packets to identify themselves and to advertise their services and routes to other networks.
* NetWare clients use broadcasts to find NetWare servers.
* Version 4.0 of Novell's SNMP-based network management applications, such as NetExplorer, periodically broadcast packets to discover changes in the network.

An idle network with a single server with one shared volume and no print services generates one broadcast packet every four seconds. A large LAN with high-end servers might have up to 150 users per PC server. If the LAN has 900 users with a reasonably even distribution, it would have six or seven servers. In an idle state with multiple shared volumes and printers, this might average out to four broadcasts per second, uniformly distributed. In a busy network with route and service requests made frequently, the rate would peak at 15 to 20 broadcasts per second.

[[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#ure: Effect of broadcast radiation on hosts in Novell networks|ure: Effect of broadcast radiation on hosts in Novell networks]] shows the results of tests that Cisco conducted on the effect of broadcast radiation on the performance of an 80386 CPU running at 25 MHz. Performance was measured with the Norton Utilities System Information utility. Background traffic was generated with a Network General Sniffer and consisted of a broadcast destination packet and a multicast destination packet, with data of all zeroes. CPU performance was measurably affected by as few as 30 broadcast or multicast packets per second. Multicast packets had a slightly worse effect than broadcast packets.

===== Figure: Effect of broadcast radiation on hosts in Novell networks=====

[[image:nd20e02.jpg]]

[[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Table: Average Number of Broadcasts and Multicasts for Novell Networks|Table: Average Number of Broadcasts and Multicasts for Novell Networks]] shows the average and peak number of broadcasts and multicasts for Novell networks ranging from 100 to 10,000 hosts per network.

===== Table: Average Number of Broadcasts and Multicasts for Novell Networks=====

{| border = 1
|-
!Number of Hosts
!Average Percentage of CPU Loss per Host
|-
|

100
|

.12
|-
|

1000
|

.22
|-
|

10,000
|

3.15
|}

The results listed in [[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Table: Average Number of Broadcasts and Multicasts for Novell Networks|Table: Average Number of Broadcasts and Multicasts for Novell Networks]] represent multihour, average operation. Peak traffic load and CPU loss per workstation can be orders of magnitude greater than with average traffic loads. A common scenario is that at 9 a.m. on Monday, everyone starts their computers. Normally, in circumstances with an average level of utilization or demand, the network can handle a reasonable number of stations. However, in circumstances in which everyone requires service at once (a demand peak), the available network capacity can support a much lower number of stations. In determining network capacity requirements, peak demand levels and duration can be more important than average serviceability requirements.
== Using Broadcasts with AppleTalk Networks ==
AppleTalk uses multicasting extensively to advertise services, request services, and resolve addresses. On startup, an AppleTalk host transmits a series of at least 20 packets aimed at resolving its network address (a Layer 3 AppleTalk node number) and obtaining local "zone" information. Except for the first packet, which is addressed to itself, these functions are resolved through AppleTalk multicasts.

In terms of overall network traffic, the AppleTalk Chooser is particularly broadcast intensive. The Chooser is the software interface that allows the user to select shared network services. It uses AppleTalk multicasts to find file servers, printers, and other services. When the user opens the Chooser and selects a type of service (for example, a printer), the Chooser transmits 45 multicasts at a rate of one packet per second. If left open, the Chooser sends a five-packet burst with a progressively longer delay. If left open for several minutes, the Chooser reaches its maximum delay and transmits a five-packet burst every 270 seconds. By itself, this does not pose a problem, but in a large network, these packets add to the total amount of broadcast radiation that each host must interpret and then discard.

Other AppleTalk protocols, such as the Name Binding Protocol, which is used to bind a client to a server, and the Router Discovery Protocol, a RIP implementation that is transmitted by all routers and listened to by each station, are broadcast intensive. The system in it called AutoRemounter (part of the Macintosh operating system) is also broadcast intensive.

{{note|The AppleTalk stack is more efficient than the Novell stack because the AppleTalk stack discards non-AppleTalk broadcasts earlier than the Novell stack discards non-Novell broadcasts.}}

[[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Figure: Effect of broadcast radiation on hosts in AppleTalk networks|Figure: Effect of broadcast radiation on hosts in AppleTalk networks]] shows the results of tests that Cisco conducted on the effect of broadcast radiation on the performance of a Power Macintosh 8100 and a Macintosh IIci. Both CPUs were measurably affected by as few as 15 broadcast or multicast frames per second.

===== Figure: Effect of broadcast radiation on hosts in AppleTalk networks=====

[[image:nd20e03.jpg]]

[[Internetwork Design Guide -- Broadcasts in Switched LAN Internetworks#Table: Average Number of Broadcasts and Multicasts for AppleTalk Networks|Table: Average Number of Broadcasts and Multicasts for AppleTalk Networks]] shows the average and peak number of broadcasts and multicasts for AppleTalk networks ranging from 100 to 10,000 hosts per network.

===== Table: Average Number of Broadcasts and Multicasts for AppleTalk Networks=====

{| border = 1
|-
!Number of Hosts
!Average Percentage of CPU Loss per Host
!Peak Percentage of CPU Loss per Host
|-
|

100
|

.28
|

6.00
|-
|

1,000
|

2.10
|

58.00
|-
|

10,000
|

16.94
|

100.00
|}

Slow LocalTalk-to-Ethernet connection devices are a major problem in large-scale AppleTalk networks. These devices fail in large AppleTalk networks because they have limited ARP caches and can process only a few broadcasts per second. Major broadcast storms arise when these devices lose their capability to receive Routing Table Maintenance Protocol (RTMP) updates. After this occurs, these devices send ARP requests for all known devices, thereby accelerating the network degradation because they cause their neighbor devices to fail and send their own ARP requests.
== Using Broadcasts with Multiprotocol Networks ==
The following can be said about the interaction of AppleTalk, IPX, and IP:
* AppleTalk stacks ignore any other Layer 3 protocol.
* AppleTalk and IP broadcast and multicast packets affect the operation of IP and IPX stacks. AppleTalk and IP packets enter the stack and then are discarded, which consumes CPU resources.

These findings show that AppleTalk has a cumulative effect on IPX and IP networks.

[[Category: Internetwork Design]]

Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks

2012-10-16T21:31:16Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="isdn, internetworking"></meta>
As telephone companies make Integrated Services Digital Network (ISDN) services available, ISDN is becoming an increasingly popular way of connecting remote sites. This case study covers the following ISDN scenarios:
* [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Configuring DDR over ISDN|Configuring DDR over ISDN]] - This telecommuting scenario describes the configuration of home sites that use ISDN to connect to a central company network and shows you how to use calling line identification numbers to prevent unauthorized access to the central network.
* [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Configuring Snapshot Routing over ISDN|Configuring Snapshot Routing over ISDN]] - Snapshot routing provides cost-effective access to a central company network from branch or home offices. Snapshot routing is used to upgrade the telecommuting network and control routing updates in Novell IPX networks.
* [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Configuring AppleTalk over ISDN|Configuring AppleTalk over ISDN]] - This scenario shows you how to control AppleTalk packets that might otherwise trigger unnecessary ISDN connections.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Configuring DDR over ISDN ==
In the United States, many companies today regard telecommuting as a way to solve space problems, conform to the Clean Air Act, and make employees more productive. In Europe, companies are looking for solutions that allow central offices to connect to remote sites. In the past, analog modems provided the necessary connectivity over serial lines, but they are not fast enough for LAN-to-LAN connections or for remote use of graphical programs, such as computer-aided design (CAD) tools. ISDN provides the needed additional bandwidth without requiring a leased line.

An ISDN Basic Rate Interface (BRI) provides two 64-kilobits-per-second (Kbps) B channels for voice or data and one 16-Kbps D channel for signaling. Voice and data information is carried over the B channels digitally. In the United States, an ISDN Primary Rate Interface (PRI) provides 23 64-Kbps B channels for voice and data over a T1 connection, and one 64-Kbps D channel for signaling. In Europe, a PRI provides 30 B channels for voice and data and one D channel for signaling over an E1 connection.

[[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: ISDN network example|Figure: ISDN network example]] shows the network that will be discussed in this case study. The ISDN network uses multiple central office ISDN switches.

===== Figure: ISDN network example=====

[[image:nd202101.jpg]]

In this case study, the remote sites (homes) use Cisco 2503 routers, which provide one BRI, an Ethernet interface, and two high-speed serial interfaces. At the central company site, a Cisco 7000 series router equipped with a channelized T1 card answers the calls. The channelized T1 card provides a PRI.

Currently in many parts of the United States, telephone companies have not deployed Signaling System 7, which means that calls between certain central offices must be placed at 56 Kbps. This restriction does not apply to all parts of the United States or to other countries, but it does apply to some of the sample ISDN networks described in this article.
=== Native ISDN Interfaces ===
If you are using an external ISDN terminal adapter, also known as an ISDN modem, you can use the configuration examples provided in [[Internetwork Design Guide -- Dial-on-Demand Routing#Dial-on-Demand Routing|Dial-on-Demand Routing]]. Although an ISDN modem provides ISDN connectivity and allows you to use existing serial interfaces, it is not always the optimal solution because of the investment in an external unit and in additional cabling. Also, using V.25bis does not give the router full access to certain information that is available in an ISDN network, such as the speed of the call or the number of the calling party.

The native ISDN interface on the Cisco 2503 router allows the router to be directly connected to an ISDN NT1 device. In many countries, the NT1 is provided by the telephone company. In the United States, however, the NT1 is customer-owned equipment. By directly connecting to the ISDN network, the router has more direct control over ISDN parameters and has access to ISDN information.
=== Configuring an ISDN Interface ===
Configuring a native ISDN interface is similar to configuring a serial interface using DDR routing as described in [[Internetwork Design Guide -- Dial-on-Demand Routing#Dial-on-Demand Routing|Dial-on-Demand Routing]]. There are two major differences:
* The '''dialer in-band''' interface configuration command is not required with ISDN. PRI and BRI interfaces are assumed by the router to be a DDR interface.
* The individual B channels cannot be configured separately. The B channels of a BRI appear to be a dialer rotary group with two members. In the United States, the B channels of a PRI appear to be a dialer rotary group with 23 members, and in Europe, the B channels of a PRI appear to be a dialer rotary group with 30 members. Because the PRI or BRI is a dialer rotary group, all configuration commands associated with a PRI or BRI apply to all B channels.

The following sections describe the configurations of the central site and the home site routers. In this case study, both the central site and the home sites can place calls. The central site uses a Cisco 7000 router that connects to a NorTel DMS-100 central office ISDN switch. One remote site router (nick-isdn) connects to the same central office switch that the central site router uses. Connections from the other remote site router (dave-isdn) pass through two central office switches to reach the central site router.
==== Central Site ====
Two remote site users, Dave and Nick, dial from their homes into the central site router that is configured as follows. Part of the configuration of the central site router is specific to the DMS-100 switch, whereas other commands apply to any type of ISDN central office switch.

<pre>hostname central-isdn
!
username dave-isdn password 7 130318111D
username nick-isdn password 7 08274D02A02
isdn switch-type primary-dms100
!
interface ethernet 0
ip address 11.108.40.53 255.255.255.0
no mop enabled
!
controller t1 1/0
framing esf
linecode b8zs
pri-group timeslots 2-6
!
interface serial 1/0:23
ip address 11.108.90.53 255.255.255.0
encapsulation ppp
dialer idle-timeout 300
dialer map ip 11.108.90.1 name dave-isdn speed 56 914085553680
dialer map ip 11.108.90.7 name nick-isdn 8376
dialer-group 1
ppp authentication chap
!
router igrp 10
network 11.108.0.0
redistribute static
!
! route to nick-isdn
ip route 11.108.137.0 255.255.255.0 11.108.90.7
! route to dave-isdn
ip route 11.108.147.0 255.255.255.0 11.108.90.1
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!NTP
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 123
!SNMP
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 161
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
dialer-list 1 list 101 </pre>

The configuration begins by establishing the host name of the router. The '''username''' global configuration commands establish the names of the routers that are allowed to dial up this router. The names correspond to the host names of Dave's router and Nick's router. The''' isdn switch-type '''command global configuration command specifies that the central site router connects to a NorTel DMS-100 switch. The host name, usernames, and ISDN switch type vary from router to router.
===== Controller Configuration =====
The '''controller''' global configuration command uses '''T1''' to specify a T1 controller interface. The "1" indicates that the controller card is located in backplane slot number 1. The "0" indicates port 0.

The '''framing''' controller configuration command selects the frame type for the T1 data line. In this case, the '''framing '''command uses the '''esf''' keyword to indicate the extended super frame (ESF) frame type. The service provider determines which framing type, either sf, esf, or crc4, is required for your T1/E1 circuit.

The '''linecode''' controller configuration command defines the line-code type for the T1 data line. In this case, the '''linecode''' command uses the '''b8zs''' keyword to indicate that the line-code type is bipolar 8 zero substitution (B8ZS). The service provider determines which line-code type, either alternate mark inversion (AMI) or B8ZS, is required for your T1/E1 circuit.

The '''pri-group''' controller configuration command specifies an ISDN PRI on a channelized T1 card in a Cisco 7000 series router. The '''timeslots''' keyword establishes the B channels. In this example, only five B channels (channels 2 through 6) are in use on this controller.
===== Interface Configuration =====
The '''ip address''' interface configuration command establishes the IP address of the interface, and the '''encapsulation ppp''' command establishes the Point-to-Point protocol (PPP) as the encapsulation method. PPP supports Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) as authentication mechanisms for identifying the caller and providing a level of security. The '''dialer idle-timeout''' interface configuration command sets the idle timeout to five minutes.

The''' dialer map''' interface configuration commands establish the remote sites that the router can call. Because Dave's router connects to a central office switch that does not use Signaling System 7, the '''dialer map''' command for calling Dave's router uses the''' speed''' keyword, which is valid for native ISDN interfaces only. The native ISDN interface on the Cisco 2503 operates at either 64 or 56 Kbps. If the calling party and the called party use the same ISDN switch, they can communicate at 64 Kbps. Otherwise, they must communicate at 56 Kbps.

Because Nick's ISDN line connects to the same central office as the line that the central site router uses, the telephone number in the '''dialer map''' command for connecting to Nick's router does not have to include the three-digit prefix. Note that because the central site router uses lines that are part of a Centrex, the outgoing telephone numbers start with 9 if they are not four-digit numbers.

The '''dialer-group''' interface configuration command associates the BRI with dialer access group 1. The '''ppp authentication chap''' interface configuration command enables CHAP authentication.
===== Routing Configuration =====
In the routing section of the configuration, the '''router igrp''' global configuration command enables the Interior Gateway Routing Protocol (IGRP) and sets the autonomous system number to 10. The '''network''' router configuration command assigns the network number. The '''redistribute''' router configuration command sends the static route information (defined with the '''ip route''' global configuration commands) to other routers in the same IGRP area. Without this command, other routers connected to the central site would not have routes to the remote routers.

DDR tends to use static routes extensively because routing updates are not received when the dial-up connection is not active. The first two '''ip route '''commands create the static routes that define the subnets that Dave and Nick use.

{{note|The IGRP commands are the same on all central site routers, except that the static routes correspond to the home sites calling into each central site router.}}

===== Access List Configuration =====
DDR uses access lists to determine whether a packet is interesting or uninteresting. Interesting packets cause a call to be placed if a call is not active or cause a call that has already been placed to be maintained as active. The first extended '''access-list''' global configuration command states that IGRP updates are uninteresting. The second extended '''access-list''' command states that Network Time Protocol (NTP) packets are uninteresting. The third extended '''access-list''' command specifies that Simple Network Management Protocol (SNMP) packets are uninteresting, and the final extended '''access-list '''command states that all other IP packets are interesting. The '''dialer-list list '''global configuration command assigns the set of access lists to dialer access group 1.
==== Home Site ====
The configurations of the home site routers are similar, but Nick's configuration is simpler because his router connects to the same central office switch as the central site router.
===== Nick =====
The configuration for the router at Nick's home is as follows:

<pre>hostname nick-isdn
!
username central-isdn password 7 050D130C2A5
isdn switch-type basic-dms100
!
interface ethernet 0
ip address 11.108.137.1 255.255.255.0
no mop enabled
!
interface bri 0
ip address 11.108.90.7 255.255.255.0
encapsulation ppp
no ip route-cache
isdn spid1 415555837601 5558376
isdn spid2 415555837802 5558378
dialer idle-timeout 300
dialer map ip 11.108.90.53 name central-isdn 8362
dialer map ip 11.108.90.53 name central-isdn 8370
dialer-group 1
ppp authentication chap
!
ip route 11.108.0.0 255.255.0.0 11.108.90.53
!
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 177
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
dialer-list 1 list 101 </pre>

As with the central site router, the '''isdn switch-type''' global configuration command specifies that the switch is an NT DMS-100 switch. Because Nick's router connects to the DMS-100, SPIDs are required for the BRI. PPP and CHAP are configured, along with a '''username''' command for the central site router. The configuration for Nick's router differs from that of the central site with regard to the '''dialer map''' commands and the routing section. Two '''dialer map''' commands point to the same next-hop address. If the attempt to call the first number fails, the second number will be used to connect to the next-hop address.

The''' isdn spid1''' and '''isdn spid2''' interface configuration commands represent service profile identifiers (SPIDs). SPIDs are used when a BRI connects to a NorTel DMS-100 switch or a National ISDN-1 switch. SPIDs are assigned by the service provider to associate a SPID number with a telephone number. Other switch types do not require SPIDs. Your service provider can tell you if SPIDs are required for your switch. In this example, SPID 1 identifies 415 as the area code, 555 as the exchange, 8376 as the station ID, and 01 as the terminal identifier. The SPID format required by your service provider may differ from the examples shown in this case study.
===== Dave =====
The configuration for Dave's router is similar to the configuration for Nick's router, except that Dave's router is not in the same Centrex as the central company site. The configuration for Dave's router is as follows:

<pre>hostname dave-isdn
!
username central-isdn password 7 08274341
isdn switch-type basic-5ess
!
interface ethernet 0
ip address 11.108.147.1 255.255.255.0
no mop enabled
!
interface bri 0
ip address 11.108.90.1 255.255.255.0
encapsulation ppp
no ip route-cache
bandwidth 56
dialer map ip 11.108.90.53 name central-isdn speed 56 14155558370
dialer-group 1
ppp authentication chap
!
ip route 11.108.0.0 255.255.0.0 11.108.90.53
!
dialer-list 1 list 101 </pre>

Dave's configuration is different from Nick's configuration because Dave's router connects to an AT&T 5ESS central office ISDN switch that does not run Signaling System 7. The '''isdn switch-type''' global configuration command specifies a basic rate AT&T switch, which does not require Dave's router configuration to use the '''isdn spid1''' and '''isdn spid2''' interface configuration commands that the DMS-100 switch requires. The '''bandwidth''' interface configuration command tells routing protocols that the line operates at 56 Kbps. The '''dialer map''' interface configuration command uses the '''speed''' keyword so that when Dave's router dials up the central site router, it sets the line speed to 56 Kbps. This setting is necessary when the connection traverses a switch that does not run Signaling System 7.
=== Configuring Calling Line Identification Numbers ===
Because Nick is in the same Centrex as the central company routers, the central router can use the Calling Line Identification (CLID) number received from the ISDN switch to identify Nick. With CLID, the configuration for Nick does not require CHAP or PAP; however, Nick needs to modify his configuration to include CLID. Nick's new configuration and a sample of the central site changed configuration are shown in the following sections.

{{note|CLID is not available in all parts of the United States and other countries. Some countries do not require Centrex for CLID.}}

==== Central Site ====
Here is the central site PRI interface configuration modified for CLID:

<pre>controller t1 1/0
framing esf
linecode b8zs
pri-group timeslots 2-6
!
interface serial 1/0:23
ip address 11.108.90.53 255.255.255.0
dialer idle-timeout 300
dialer map ip 11.108.90.7 name 5558376 8376
dialer-group 1 </pre>

The '''name''' keyword in the '''dialer map''' interface configuration command specifies the actual string that calling line identification returns. This string differs from the number called: the number called is a four-digit Centrex number, and the number returned is the full seven digits.
==== Home Site ====
As with the central site, the major difference in Nick's configuration is the use of the '''name''' keyword with the '''dialer map''' command that specifies the actual number being returned as the calling line number.

<pre>interface bri 0
ip address 11.108.90.7 255.255.255.0
no ip route-cache
isdn spid1 415555837601 5558376
isdn spid2 415555837802 5558378
dialer idle-timeout 300
dialer map ip 11.108.90.53 name 5558362 8362
dialer map ip 11.108.90.53 name 5558370 8370
dialer-group 1 </pre>

{{note|If the '''debug isdn-q931 '''EXEC command is enabled, the decode for an incoming call setup can be seen and the CLID number will be shown.}}

=== Configuring Callback ===
Because Dave is located several miles from the central office, calls to the central office router are metered and billed to Dave's telephone number. The callback feature (introduced in Cisco IOS 11.0) allows Dave's router to place a call to the central site router requesting that the central site router call Dave's router. Then the central site router disconnects the call and places a return call to Dave's router.With callback configured, Dave's telephone bill is reduced because actual data transfers occur when the central office router calls back. The following commands configure callback on Dave's router:

interface bri 0
ppp callback request
dialer hold-queue 100 timeout 20

The '''ppp callback''' interface configuration command with the '''request''' keyword specifies that when the interface places a call, it is to request callback. The '''dialer hold-queue''' interface configuration command specifies that up to 100 packets can be held in a queue until the central site router returns the call. If the central site router does not return the call within 20 seconds plus the length of the enable timeout configured on the central site router, the packets are dropped. The following commands configure callback on the central office router:

map-class dialer class1
dialer callback-server username
interface serial 1/0:23
dialer map ip 11.108.90.1 name dave-isdn speed 56 class class1 914085553680
ppp callback accept
dialer callback-secure
dialer enable-timeout 1
dialer hold-queue

The '''map-class''' global configuration command establishes a quality of service (QoS) parameter that is to be associated with a static map. The '''dialer''' keyword specifies that the map is a dialer map. The '''class1''' parameter is a user-defined value that creates a map class to which subsequent encapsulation specific commands apply.

The '''dialer map''' interface configuration command has been modified to include the '''class''' keyword and the name of the class, as specified in the '''map-class''' command. The''' name''' keyword is required so that, when Dave's router dials in, the interface can locate this dialer map statement and obtain the dial string for calling back Dave's router.

The '''ppp callback''' interface configuration command with the '''accept''' keyword allows the interface to accept and honor callback requests that come into the interface. (Callback depends on PPP authentication, using PAP or CHAP.)

The '''dialer callback-server''' map class configuration command allows the interface to return calls when callback is successfully negotiated. The '''username''' keyword specifies that the interface is to locate the dial string for making the return call by looking up the authenticated host name in a '''dialer map''' command.

The '''dialer callback-secure''' interface configuration command specifies that the router is to disconnect the initial call, and call back only if it has a '''dialer map''' command with a defined class for the remote router. If the '''dialer callback-secure''' command is not present, the central router will not drop the connection if it does not have a '''dialer map''' command with a defined class. The '''dialer enable-timeout''' interface configuration command specifies that the interface is to wait one second after disconnecting the initial call before making the return call.
== Configuring Snapshot Routing over ISDN ==
Snapshot routing is an easy way to reduce connection time in ISDN networks by suppressing the transfer of routing updates for a configurable period of time. Snapshot routing is best suited for networks whose data-transfer connections typically last longer than five minutes and that are running the following distance-vector protocols:
* Routing Information Protocol (RIP) and Integrated Gateway Routing Protocol (IGRP) for IP
* Routing Table Maintenance Protocol (RTMP) for AppleTalk
* Routing Information Protocol (RIP) and Service Advertisement Protocol (SAP) for Novell Internet Packet Exchange (IPX)
* Routing Table Protocol (RTP) for Banyan VINES

The goal of snapshot routing is to allow routing protocols to exchange updates as they normally would. Because Enhanced IGRP and link-state routing protocols, such as Novell Link Services Protocol (NLSP), Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS) depend on the frequent sending of hello messages to neighboring routers in order to discover and maintain routes, they are incompatible with snapshot routing.

{{note|This case study applies snapshot routing to an ISDN network, but other similar media, such as dedicated leased lines, can benefit from the reduction of periodic updates that snapshot routing provides.}}

Before snapshot routing became available in Cisco Internetwork Operating System (IOS) Software Release 10.2, ISDN interfaces were configured using static routes. Static routes, such as the routes defined by the '''ip route''' commands in the [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Central Site|Central Site]] section earlier in this article, prevent bandwidth from being consumed by routing updates, but they are difficult to maintain as the network grows.

Snapshot routing supports dynamic routes by allowing routing updates to occur during an active period and reduces connection cost by suppressing routing updates during a quiet period, which can be up to 65 days long. During the quiet period, the routing tables on the routers at both ends of a link are frozen. [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: Active periods and frozen periods over time|Figure: Active periods and frozen periods over time]] shows the relationship of active and quiet periods over time.

===== Figure: Active periods and frozen periods over time=====

[[image:nd202102.jpg]]

During the active period, the routers at each end of the connection exchange the routing updates that are normal for their configured routing protocols. They continue to exchange routing updates until the active period ends. When the active period ends, each router freezes its routing tables, stops sending routing updates, and enters the quiet period. Each router remains in the quiet period until a configurable timer expires, at which time one of the routers initiates a connection to send and receive routing updates.

To ensure that routing tables are updated, the active period must be long enough for several routing updates to come through the link. An active period that is too short might allow only one routing update to cross the link. If that update is lost due to noise on the line, the router on the other end would age out a valid route or would not learn about a new valid route. To make sure that updates occur, the active period must be at least five minutes long (that is, three times longer than the routing protocols' update interval). Because the routing protocols update their routing tables during the active period as they normally would, there is no need to adjust any routing protocol timers.

If the line is not available when the router transitions from the quiet period to the active period, it enters a retry period. During the retry period, the router continually attempts to connect until it enters an active period, as shown in [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: The router continually attempts to connect during the retry period|Figure: The router continually attempts to connect during the retry period]].

===== Figure: The router continually attempts to connect during the retry period=====

[[image:nd202103.jpg]]

[[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Table: Snapshot Routing Periods|Table: Snapshot Routing Periods]] shows the minimum and maximum lengths of each period.

===== Table: Snapshot Routing Periods=====

{| border = 1
|-
!'''Period'''

!'''Configurable'''

!'''Minimum Length'''

!'''Maximum Length'''
|-
|

Active
|

Yes
|

5 minutes
|

100 minutes
|-
|

Quiet
|

Yes
|

5 minutes
|

65 days
|-
|

Retry
|

No
|

8 minutes
|

8 minutes
|}

By default, snapshot routing allows routing updates to be exchanged over connections that are established to transfer user data. This means that, if necessary, snapshot routing forces the connection to last as long as the active period. If you do not want the routers to exchange updates during connections that are established to transfer user data, use the '''suppress-statechange-updates''' keyword.
=== Upgrading the Telecommuting Network ===
Snapshot routing is well-suited to the hub-and-spoke topology of the telecommuting network described in the "[[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Configuring DDR over ISDN|Configuring DDR over ISDN]]" section at the beginning of this article. Snapshot routing is designed for a client-server relationship. The client routers, such as the home sites, determine the frequency at which the routers exchange updates by setting the length of the quiet period, and the server router accepts incoming snapshot connections from several client routers.

{{note|Snapshot routing is not recommended for meshed topologies. In meshed topologies, configuring static routes is more efficient than configuring snapshot routing.}}

==== Central Site Modified for Snapshot Routing ====
The following is the configuration of the central site router after modification for snapshot routing:

<pre>hostname central-isdn
!
username dave-isdn password 7 130318111D
username nick-isdn password 7 08274D02A02
isdn switch-type primary-dms100
!
interface ethernet 0
ip address 11.108.40.53 255.255.255.0
no mop enabled
!
controller t1 1/0
framing esf
linecode b8zs
pri-group timeslots 2-6
ip address 11.108.90.53 255.255.255.0
encapsulation ppp
dialer idle-timeout 300
dialer map ip 11.108.90.1 name dave-isdn speed 56 914085553680
dialer map ip 11.108.90.7 name nick-isdn 8376
dialer-group 1
isdn spid1 415555836201 5558362
isdn spid2 415555837002 5558370
snapshot server 5
ppp authentication chap
!
router igrp 10
network 11.108.0.0
redistribute static
!
! route to nick-isdn
ip route 11.108.137.0 255.255.255.0 11.108.90.7
! route to dave-isdn
ip route 11.108.147.0 255.255.255.0 11.108.90.1
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!NTP
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 123
!SNMP
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 161
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
dialer-list 1 list 101 </pre>

The '''ip route''' global configuration commands that configured static routes for the home sites have been removed from the configuration. The '''snapshot server''' interface configuration command enables snapshot routing. The "5" sets the length of the active period to five minutes.

{{note|Snapshot routing must be configured on rotary interfaces, which are established by the '''dialer rotary-group''' interface configuration command. ISDN interfaces are rotary interfaces by definition, so you do not need to use the '''dialer rotary-group''' command in ISDN configurations.}}

==== Home Site Modified for Snapshot Routing ====
The following is the configuration of Dave's home site router after modification for snapshot routing:

<pre>hostname dave-isdn
!
username central-isdn password 7 08274341
isdn switch-type basic-5ess
!
interface ethernet 0
ip address 11.108.147.1 255.255.255.0
no mop enabled
!
interface bri 0
ip address 11.108.90.1 255.255.255.0
encapsulation ppp
no ip route-cache
bandwidth 56
dialer map snapshot 1 name central-isdn 14155558370
dialer map ip 11.108.90.53 name central-isdn speed 56 14155558370
dialer-group 1
snapshot client 5 43200 suppress-statechange-updates dialer
ppp authentication chap
!
dialer-list 1 list 101 </pre>

The '''ip route '''commands that configured static routes for the home sites have been removed from the configuration. The '''dialer map snapshot''' interface configuration command establishes a map (whose sequence number is 1) that the router uses to connect to the central site router for the exchange of routing updates. The '''name''' keyword specifies the name of the remote router that is associated with the dial string. Because the '''ppp authentication''' interface configuration command enables CHAP authentication, when this router dials the central router, it receives the host name of the central router and compares it with the name specified by the '''name''' keyword.

The '''snapshot client''' interface configuration command sets the length of the active period to five minutes (a value that must match the value set in the snapshot server's configuration) and sets the length of the quiet period to 43,200 seconds (12 hours). The '''suppress-statechange-updates''' keyword prevents the routers from exchanging updates during connections that are established to transfer user data. The '''dialer''' keyword allows the client router to dial up the server router in the absence of regular traffic and is required when you use the '''suppress-statechange-update''' keyword.

=== Snapshot and Novell IPX Networks ===
This section describes a Novell IPX network for which snapshot routing has been configured. Client routers at branch offices use DDR to connect to a central router over ISDN. At the central office, NetWare servers use the Novell IPX protocol to provide services to NetWare clients on each branch office network. Some client-to-server connections are required during a limited period of the day. [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: Topology of the Novell IPX network|Figure: Topology of the Novell IPX network]] illustrates the network.

===== Figure: Topology of the Novell IPX network=====

[[image:nd202104.jpg]]

In this topology, the client routers are responsible for updating their routing tables by connecting to the server router when the quiet period expires. The client routers also retrieve update information if a reload occurs.

{{note|Snapshot routing works with Novell 3.x and 4.x networks. However, Novell 4.x includes a time synchronization protocol that causes Novell 4.x time servers to send an update every 10 minutes. To prevent the time server from generating update packets that would cause unwanted connections, you should load a NetWare Loadable Module (NLM) named TIMESYNC.NLM that allows you to increase the update interval for these packets to several days. A similar problem is caused by Novell's efforts to synchronize NDS replicas. NetWare 4.1 includes two NLMs, DSFILTER.NLM and PINGFILT.NLM, that work together to control NDS synchronization updates. You should use these two modules to make sure that NDS synchronization traffic is sent to specified servers only at the specified times.}}

==== Server Router Configuration ====
The following is the complete configuration for the server router:

<pre>hostname RouterA
!
username RouterB password 7 120DOA031D
username RouterC password 7 111D161118
username RouterD password 7 43E7528384
isdn switch-type vn3
!
ipx routing
interface Ethernet 0
ip address 192.104.155.99 255.255.255.0
ipx network 300
!
interface bri 0
ip address 1.0.0.1 255.0.0.0
encapsulation ppp
ipx network 10
no ipx route-cache
ipx update-time 20
ipx watchdog-spoof
dialer idle-timeout 60
dialer wait-for-carrier-time 12
dialer map ipx 10.0000.0000.0002 name RouterB broadcast 041389082
dialer map ipx 10.0000.0000.0003 name RouterC broadcast 041389081
dialer map ipx 10.0000.0000.0004 name RouterD broadcast 041389083
!
dialer-group 1
snapshot server 10
ppp authentication chap
!
access-list 901 deny 0 FFFFFFF 0 FFFFFFFF 457
access-list 901 deny 1 10.0000.0000.0001 0 10.ffff.ffff.ffff 453
access-list 901 deny 4 10.0000.0000.0001 0 l0.ffff.ffff.ffff 452
access-list 901 deny 4 FFFFFFFF 0 FFFFFFFF 456
access-list 901 permit -1
!
dialer-list 1 list 901 </pre>

The configuration begins with the host name used for CHAP authentication. The usernames correspond to the host names of Router B, Router C, and Router D. The '''isdn switch-type''' global configuration command specifies that the router connects to a French VN3 ISDN BRI switch.
===== Interface Configuration =====
The '''dialer idle-timeout''' interface configuration command specifies 60 seconds as the amount of idle time that must elapse before the router disconnects the line. The '''dialer wait-for-carrier-time '''interface configuration command sets the wait-for-carrier time to 60 seconds.

The first '''dialer map''' interface configuration command sets the next-hop address of Router B to 10.0000.0000.0002. When Router B dials up the server router (Router A), the server router uses the next hop address to transmit packets to Router B. The '''broadcast''' keyword sets 041389082 as the address to which IPX broadcasts are to be forwarded. The second and third '''dialer map''' commands set similar values for Router C and Router D.

The '''snapshot server''' interface configuration command sets the length of the active period to 10 minutes. The''' ppp authentication''' interface configuration command sets CHAP as the authentication protocol.
===== Access List Configuration =====
Access lists are used to determine whether an outgoing packet is interesting or uninteresting. Packets that are not interesting are dropped, and packets that are interesting cause a call to be placed if a call is not active or cause a call that has already been placed to be maintained as active. The access lists defined by this configuration are extended Novell IPX access lists. The first '''access-list''' global configuration command defines any packets intended for the Novell serialization socket as uninteresting. The second '''access-list''' command defines RIP packets as uninteresting. The third '''access-list''' command defines SAP packets as uninteresting. The fourth '''access-list''' command defines Novell diagnostic packets generated by the Autodiscovery feature as uninteresting, and the final '''access-list '''command states that all other packets are interesting. The '''dialer-list global configuration''' command assigns access list 901 to dialer access group 1, which is associated with BRI 0 by the '''dialer-group''' interface configuration command.
==== Client Router Configuration ====
The configurations for the client routers are the same except for the commands that configure the router's host name, the username that it uses when it dials up Router A, and the router's network numbers. The following is the configuration for Router B:

<pre>hostname RouterB
!
username RouterA password 7 105A060D0A
ipx routing
isdn switch-type vn3
isdn tei first-call
!
interface ethernet 0
ip address 192.104.155.100 255.255.255.0
ipx network 301
!
interface bri 0
no ip address
encapsulation ppp
ipx network 10
no ipx route-cache
ipx update-time 20
ipx watchdog-spoof
dialer idle-timeout 60
dialer wait-for-carrier-time 12
dialer map snapshot 1 name RouterA 46148412
dialer map ipx 10.0000.0000.0001 name RouterA broadcast 46148412
dialer-group 1
snapshot client 10 86400 dialer
ppp authentication chap
!
access-list 901 deny 0 FFFFFFFF 0 FFFFFFFF 457
access-list 901 deny 1 10.0000.0000.0002 0 10.ffff.ffff.ffff 453
access-list 901 deny 4 10.0000.0000.0002 0 10.ffff.ffff.ffff 452
access-list 901 deny 4 FFFFFFFF 0 FFFFFFFF 456
access-list 901 permit 0
!
dialer-list 1 list 901 </pre>

The configuration begins with the host name used for CHAP authentication. The usernames correspond to the host names of Router B, Router C, and Router D. The''' isdn switch-type''' global configuration command specifies that the router connects to a French VN3 ISDN BRI switch.

The '''isdn tei '''global configuration command uses the '''first-call''' keyword to specify that ISDN terminal endpoint identifier (TEI) negotiation is to occur when Router A places or receives its first ISDN call. (The default is for TEI negotiation to occur when the router is powered on.)
===== Interface Configuration =====
The '''dialer wait-for-carrier''' interface configuration command specifies 12 seconds as the number of seconds that the interface will wait for the carrier to come up when it places a call.

The '''snapshot client '''interface configuration command sets the length of the active period to 10 minutes (a value that must match the value set in the snapshot server's configuration) and sets the length of the quiet period to 86,400 seconds (24 hours). Because the''' suppress-statechange-updates''' keyword is not used, the routers can exchange updates during connections that are established to transfer user data. The '''dialer '''keyword allows the client router to dial up the server router in the absence of regular traffic.

== Configuring AppleTalk over ISDN ==
To run AppleTalk over an ISDN network effectively, you need to prevent Name Binding Protocol (NBP) packets and RTMP updates from triggering unnecessary connections over ISDN connections.

[[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: An AppleTalk network over ISDN|Figure: An AppleTalk network over ISDN]] shows a sample AppleTalk network that uses ISDN to connect two networks located in different cities. Users on the district office network occasionally need access to servers located on the main office network and vice versa. In this scenario, both routers dial up each other when user data from one part of the network needs to reach the other part of the network.

===== Figure: An AppleTalk network over ISDN=====

[[image:nd202105.jpg]]

Users of hosts connected to the main office network do not need to access the Training zone, so when configuring Router A, one goal is to prevent NBP packets generated by the Training zone from triggering an ISDN connection with the main office network. Another configuration goal for both routers is to prevent NBP packets generated by the printers on each network from triggering an ISDN connection.

To control the forwarding of NBP packets, use AppleTalk-style access lists. AppleTalk-style access lists allow you to control the flow of NBP packets based on the type of the entity that originated the packet, the name of the entity that originated the packet, and the zone of the entity that originated the packet.

{{note|The capability to control the forwarding of NBP packets was introduced in Cisco IOS Software Release 11.0.}}

Both routers also need to control RTMP packets. To control RTMP packets, configure static AppleTalk cable ranges and node numbers and use the '''no appletalk send rtmps''' command on the ISDN BRI or PRI interface that connects two AppleTalk networks.
=== Router A Configuration ===
As shown in [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: An AppleTalk network over ISDN|Figure: An AppleTalk network over ISDN]], Router A is located in the district office. The district office network consists of two zones: Sales and Training. On Router A, an AppleTalk-style access list is assigned to BRI 0 to prevent the forwarding of NBP packets that come from printers and NBP packets that come from the Training zone. If the router were to allow the forwarding of these packets, they would trigger an unnecessary ISDN connection to the main office network.

<pre>hostname RouterA
!
username RouterB password 7 125D063D2E
appletalk routing
appletalk static cable-range 20-20 to 15.43 zone Administration
appletalk static cable-range 25-25 to 15.43 zone Marketing
isdn switch-type basic-ni1
!
interface ethernet 0
appletalk cable-range 5-5 5.128
appletalk zone Sales
!
interface ethernet 1
appletalk cable-range 10-10 10.26
appletalk zone Service
!
interface bri 0
appletalk static cable-range 15-15 15.42
appletalk zone PhoneZone
no appletalk send-rtmps
encapsulation ppp
ppp authentication chap
dialer idle-timeout 240
bandwidth 56
dialer map appletalk 15.43 name RouterA speed 56 912065553240
dialer-group 1
isdn spid1 602555463101 5554631
!
access-list 601 deny nbp 1 type LaserWriter
access-list 601 deny nbp 2 zone Training
access-list 601 permit nbp 3 zone Sales
access-list 601 deny other-nbps
access-list 601 permit other-access
!
dialer-list 1 list 601 </pre>

The''' hostname''' global configuration command establishes the host name of Router A. The '''username''' global configuration command establishes the name of the router that is allowed to dial up Router A. The name corresponds to the host name of Router B. The '''password''' keyword indicates that the '''username''' command specifies a password. The "7" indicates that the password is encrypted using a Cisco-defined encryption algorithm. The '''appletalk routing '''global configuration command enables AppleTalk routing.

The '''appletalk static cable-range '''global configuration commands create static AppleTalk routes to the zones in the main office network. Static AppleTalk routes are required because the '''no appletalk send-rtmps''' interface configuration command prevents the exchange of RTMP updates between the two networks. Without static routes, zones for the main office would not appear when users open the Chooser on hosts connected to the district office network. The '''isdn switch-type''' global configuration command specifies that Router A connects to a National ISDN-1 switch.
===== Interface Configuration =====
The '''appletalk cable-range''' interface configuration commands for each Ethernet interface establish the network number for the cable segment to which the interface connects and the node number of the interface. For each interface, the '''appletalk zone''' interface configuration command establishes the zone name for the network that is connected to the interface. None of the interface configurations specifies an AppleTalk routing protocol, so the interfaces use the default routing protocol, RTMP.

The '''no appletalk send-rtmps''' interface configuration command prevents Router A from sending RTMP updates out on interface BRI 0. To compensate for the lack of RTMP exchange, you must configure static AppleTalk routes (using the '''appletalk static cable-range''' global configuration command).

The '''encapsulation ppp''' interface configuration command specifies PPP encapsulation, and the '''ppp authentication chap''' command enables CHAP authentication. The '''dialer idle-timeout''' interface configuration command sets the idle timeout to 240 seconds (four minutes). The '''bandwidth '''interface configuration command tells routing protocols that the line operates at 56 Kbps.

The '''dialer map''' interface configuration command establishes the remote site that Router A is to call. In this case, the '''dialer map''' command establishes 15.43 as the next hop address. The '''name''' keyword specifies the name of the remote router that is associated with the dial string. The '''speed''' keyword specifies that Router A is to set the line's rate to 56 Kbps, which is required when the connection traverses a switch that does not support Signaling System 7. The '''dialer-group''' interface configuration command associates the interface BRI 0 with dialer access group 1.

The '''isdn spid1''' interface configuration commands represent service profile identifiers (SPIDs) and are required by National ISDN-1 switches. Service providers assign SPIDs to associate a SPID number with a telephone number. Your service provider can tell you if SPIDs are required for your switch. In this example, SPID 1 identifies 602 as the area code, 555 as the exchange, 4631 as the station ID, and 01 as the terminal identifier.
===== Access List Configuration =====
The first '''access-list nbp''' global configuration command defines access list 601 and prevents the forwarding of NBP packets generated by any LaserWriter printer on the district office network. The second '''access-list nbp''' command prevents the forwarding of NBP packets generated by the Training zone. The third '''access-list nbp''' command allows the forwarding of NBP packets generated by the Sales zone.

The''' access-list other-nbps''' global configuration command prevents the forwarding of all other NBP packets that have not been explicitly permitted or denied by previous '''access-list nbp''' global configuration commands.

The '''access-list other-access''' global configuration command permits all other access checks that would otherwise be denied because they are not explicitly permitted by an '''access-list''' command. The '''dialer-list''' global configuration command assigns the access list 601 to dialer access group 1, which is associated with BRI 0.
=== Router B Configuration ===
As shown in [[Internetwork Design Guide -- Using ISDN Effectively in Multiprotocol Networks#Figure: An AppleTalk network over ISDN|Figure: An AppleTalk network over ISDN]], Router B is located in the main office. The main office network consists of two zones: Marketing and Administration. With the exception of the OpenReqs server in the Administration zone, users of hosts connected to the district office network do not need to access servers located in the Administration zone. Like the district office network, each zone in the main office network has its own printer, so there is no need for Router B to forward NBP packets that the printers originate. The access list for Router B prevents NBP packets that come from printers and NBP packets that come from all servers in the Administration zone (except OpenReqs) from triggering an ISDN connection to the district office network.

<pre>hostname RouterB
!
username RouterA password 7 343E821D4A
appletalk routing
appletalk static cable-range 5-5 to 15.42 zone Sales
appletalk static cable-range 10-10 to 15.42 zone Training
isdn switch-type basic-5ess
!
interface ethernet 0
appletalk cable-range 20-20 20.5
appletalk zone Administration
!
interface ethernet 1
appletalk cable-range 25-25 25.36
appletalk zone Marketing
!
interface bri 0
appletalk static cable-range 15-15 15.43
appletalk zone PhoneZone
no appletalk send-rtmps
encapsulation ppp
ppp authentication chap
dialer idle-timeout 240
bandwidth 56
dialer map appletalk 15.42 name RouterB speed 56 917075553287
dialer-group 1
!
access-list 601 deny nbp 1 type LaserWriter
access-list 601 permit nbp 2 object OpenReqs
access-list 601 permit nbp 3 zone Marketing
access-list 601 deny other-nbps
access-list 601 permit other-access
dialer-list 1 list 601 </pre>

The configuration for Router B is similar to the configuration for Router A, with the follwing differences:
* The''' isdn switch-type''' global configuration command specifies that Router B connects to an AT&T 5ESS central office ISDN switch. This type of switch does not use SPID numbers, so the '''isdn spid1''' command is not used.
* The first '''access-list nbp''' global configuration command defines access list 601 and prevents the forwarding of NBP packets generated by the LaserWriter printers connected to the main office network. The second '''access-list nbp''' command allows the forwarding of packets generated by the server OpenReqs. The third '''access-list nbp''' command allows the forwarding of packets generated by the Marketing zone.
== Summary ==
When you configure ISDN, controlling packets that trigger unnecessary connections is a major concern. In the past, one way of controlling routing update packets was to configure static routes. Snapshot routing and NBP-packet filtering provide new ways to control routing updates. Snapshot routing allows you to configure the network so that routed protocols update their routing tables dynamically without triggering frequent and costly ISDN connections. Snapshot routing is ideally suited for relatively stable networks in which a single router is a central point through which routing updates flow.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks

2012-10-16T21:30:26Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="multicast, internetworking"></meta>
Over the past few years, the concept of end-users being able to send and receive audio and video (known collectively as multimedia) at the desktop has gained considerable attention and acceptance. With high-performance 486, Pentium, and PowerPC CPUs, more than 80 percent of the personal computers sold during 1995 were multimedia capable. Today, it is not uncommon for end-users to run video editing and image processing applications from the desktop.

The proliferation of more and more multimedia-enabled desktop computers has spawned a new class of multimedia applications that operate in networked environments. These network multimedia applications leverage existing network infrastructure to deliver video and audio applications to end users. Most notable are videoconferencing and video server applications. With these applications, video and audio streams are transferred over the network between peers or between clients and servers. There are three types of multimedia applications:
* Unicast-Unicast applications send one copy of each packet to each host that wants to receive the packet. This type of application is easy to implement, but it requires extra bandwidth because the network has to carry the same packet multiple times-even on shared links. Because unicast applications make a copy of each packet, the number of receivers is limited to the number of copies of each packet that can be made by the CPU that runs the unicast application.
* Broadcast-Broadcast applications send each packet to a broadcast address. This type of application is easier to implement than unicast applications, but it can have serious effects on the network. Allowing the broadcast to propagate throughout the network is a significant burden on both the network (in terms of traffic volume) and the hosts connected to the network (in terms of the CPU time that each host that does not want to receive the transmission must spend processing and discarding unwanted broadcast packets). You can configure routers to stop broadcasts at the LAN boundary (a technique that is frequently used to prevent broadcast storms), but this technique limits the receivers according to their physical location.
* Multicast-Multicast applications send each packet to a multicast group address. Hosts that want to receive the packets indicate that they want to be members of the multicast group. This type of application expects that networks with hosts that have joined a multicast group will receive multicast packets. Multicast applications and underlying multicast protocols control multimedia traffic and shield hosts from having to process unnecessary broadcast traffic.

This case study examines multicast protocols that have been developed for the Internet Protocol (IP) and for AppleTalk, as well as Cisco Internetwork Operating System (Cisco IOS) features that can help your network deliver video and audio smoothly.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}
== Implementing Multicast Applications in IP Networks ==
Currently, support for IP multicasting comes from three protocols:
* Internet Group Management Protocol (IGMP)
* Protocol-Independent Multicast (PIM)
* Distance Vector Multicast Routing Protocol (DVMRP)

Network multimedia applications for IP use IGMP to join multicast groups. PIM and DVMRP use IGMP to determine the location of hosts that have joined a multicast group.

This section covers the following topics:
* [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Addressing|Addressing]]
* [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Internet Group Management Protocol|Internet Group Management Protocol]]
* [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Protocol-Independent Multicast|Protocol-Independent Multicast]]

=== Addressing ===
IP multicasting applications use Class D addresses to address packets. The high-order four bits of a Class D address are set to 1110, and the remaining 28 bits are set to a specific multicast group ID. Class D addresses are typically written as dotted-decimal numbers and are in the range of 224.0.0.0 through 239.255.255.255.

Some multicast group addresses are assigned as well-known addresses by the Internet Assigned Numbers Authority (IANA). These multicast group addresses are called permanent host groups and are similar in concept to the well-known TCP and UDP port numbers. [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Table: Multicast Addresses for Permanent Host Groups|Table: Multicast Addresses for Permanent Host Groups]] lists the multicast address of three permanent host groups.

===== Table: Multicast Addresses for Permanent Host Groups=====

{| border = 1
|-
|

''' Permanent Host Group'''
|

''' Multicast Address'''
|-
|

Network Time Protocol (NTP)
|

224.0.1.1
|-
|

RIP-2
|

224.0.0.9
|-
|

Silicon Graphics' Dogfight application
|

224.0.1.2
|}

=== Internet Group Management Protocol ===
The Internet Group Management Protocol (IGMP) uses IP datagrams to allow IP multicast applications to join a multicast group. Membership in a multicast group is dynamic-that is, it changes over time as hosts join and leave the group.

Multicast routers that run IGMP use IGMP host-query messages to keep track of the hosts that belong to multicast groups. These messages are sent to the all-systems group address 224.0.0.1. The hosts then send IGMP report messages listing the multicast groups they would like to join. When the router receives a packet addressed to a multicast group, it forwards the packet to those interfaces that have hosts that belong to that group. If you want to prevent hosts on a particular interface from participating in a multicast group, you can configure a filter on that interface by using the '''ip igmp access-group''' interface configuration command.

Routers on which GMP is enabled periodically send IGMP host-query messages to refresh their knowledge of memberships present on their interfaces. If, after some number of queries, the router determines that no local hosts are members of a particular multicast group on a particular interface, the router stops forwarding packets for that group and sends a prune message upstream toward the source of the packet.

You can configure the router to be a member of a multicast group. This is useful for determining multicast reachability in a network. If a router is configured as a group member it can, for example, respond to an ICMP echo request packet addressed to a group for which it is a member. To configure the router as a member of a multicast group, use the '''ip igmp join-group''' interface configuration command.
=== Protocol-Independent Multicast ===
Protocol-Independent Multicast (PIM) is an IP multicast protocol that works with all existing unicast routing protocols. PIM has two modes that allow it to work effectively with two different types of multicast traffic distribution patterns: dense mode and sparse mode.

Dense mode PIM is designed for the following conditions:
* Senders and receivers are in close proximity to one another.
* There are few senders and many receivers.
* The volume of multicast traffic is high.

Sparse-mode PIM is designed for the following conditions:
* There are few receivers in a group.
* Senders and receivers are separated by WAN links.
==== Dense Mode ====
Dense-mode PIM uses a technique known as reverse path forwarding. When a router receives a packet, it sends the packet out all interfaces except the interface on which the packet was received. Reverse path forwarding allows a data stream to reach all LANs, possibly multiple times. If the router has interfaces for which no hosts are members of the multicast group for which the packet is intended or for which no downstream multicast router on that LAN has joined the group, the router sends a prune message up the distribution tree to inform the sender that it need not send subsequent packets for this multicast group. [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM dense-mode operation|Figure: PIM dense-mode operation]] shows how PIM works in dense mode.

===== Figure: PIM dense-mode operation=====

[[image:nd202401.jpg]]

In [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM dense-mode operation|Figure: PIM dense-mode operation]], Router A receives multicast traffic from Host A on Ethernet interface 0, duplicates each packet, and sends the packets out on Ethernet interface 1 and Ethernet interface 2 to Routers B and C. Routers B and C duplicate the packets and send them out to Routers D, E, and F. Router D has a host that is a member of Group 1, so Router D does not send a prune message. Router E also has a host that is a member of Group 1, but because it receives the packets on two interfaces, Router E sends a prune message to Router C. (The decision about which router should be pruned is reached through a negotiation process conducted by Router B and Router C. If the connection between Router E and Router B had been a point-to-point link, the prune message would have been sent to Router B automatically, thereby eliminating the need for Routers B and C to negotiate an agreement.)

Router F does not have any hosts that are members of Group 1, so it sends a prune message to Router C. Router C sends a prune message to Router A. After the prune messages are received, Router A sends multicast traffic for Group 1 to Router B only.

When you configure PIM in dense mode, you should enable IP multicast routing on every router over which multicast traffic will flow. The following commands configure dense mode PIM on Router B:

ip multicast-routing
interface ethernet 1
ip pim dense-mode
!
interface ethernet 2
ip pim dense-mode

The''' ip multicast-routing''' global configuration command enables IP multicast routing. You should include this command on every router that you want to participate in PIM. If some routers cannot be configured for IP multicast routing (for example, if they do not run a version of the Cisco IOS software release that supports PIM), you need to configure a tunnel so that multicast packets bypass these routers.

The '''ip pim''' interface configuration command enables PIM on the specified interface, and the '''dense-mode''' keyword enables dense mode. When you configure PIM in dense mode, you should apply the '''ip pim''' command with the '''dense-mode''' keyword to every interface that you want to forward multicast traffic.

{{note|Enabling PIM automatically enables IGMP. }}

In dense mode, the PIM-configured interface with the highest IP address on a LAN (subnet) is responsible for sending IGMP host-query messages to all hosts on the LAN. By default, the router that is responsible for sending PIM router-query messages sends them every 30 seconds. If you want to modify this interval, use the '''ip pim query-interval''' interface configuration command.

By default, a PIM-configured interface forwards all multicast packets. If you want to control the forwarding of packets, use the '''ip multicast-threshold ttl''' interface configuration command. The''' ip multicast-threshold ttl''' command changes the value of time-to-live (TTL) threshold, which the router compares with the TTL field in the IP header. Only those multicast packets that have a TTL greater than the TTL threshold are forwarded. You might, for example, want to set the TTL threshold to a very high value (such as 200) to prevent multicast packets from exiting an area.
==== Sparse Mode ====
Sparse-mode PIM is designed for environments in which many multipoint data streams go to a relatively small number of the LAN segments. For this type of environment, dense mode PIM would use bandwidth inefficiently.

Sparse-mode PIM assumes that no hosts want to receive multicast traffic unless they specifically request it. In sparse-mode PIM, a router is designated as a rendezvous point. The rendezvous point collects information about multicast senders and makes that information available to potential receivers. When a sender wants to send data, it first sends the data to the rendezvous point. When a receiver wants to receive data, it registers with the rendezvous point. When the data stream begins to flow from sender to rendezvous point to receiver, the routers in the path automatically optimize the path to remove any unnecessary hops. [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM sparse-mode operation|Figure: PIM sparse-mode operation]] shows how PIM works in sparse mode.

===== Figure: PIM sparse-mode operation=====

[[image:nd202402.jpg]]

In [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM sparse-mode operation|Figure: PIM sparse-mode operation]], Routers A and D are leaf routers. Leaf routers are routers that are directly connected either to a receiver or sender of multicast messages. The sparse-mode configuration of a leaf router designates one or more routers as rendezvous points. In this example, Router B is designated as the rendezvous point.

The leaf router that is directly connected to a sender (in this case, Router A) sends PIM register messages on behalf of the sender to the rendezvous point. The leaf router that is directly connected to a receiver (in this case, Router B) sends PIM join and prune messages to the rendezvous point to inform it about group membership. The following commands configure Router A for sparse mode:

<pre>ip multicast-routing
ip pim rp-address 10.8.0.20 1
!
interface ethernet 0
ip pim sparse-mode
!
interface ethernet 1
ip pim sparse-mode
!
access-list 1 permit 224.0.1.2 </pre>

The following commands configure Router D for sparse mode:

<pre>ip multicast-routing
ip pim rp-address 10.8.0.20 1
!
interface ethernet 0
ip pim sparse-mode
!
interface ethernet 1
ip pim sparse-mode
!
access-list 1 permit 224.0.1.2 </pre>

The '''ip multicast-routing''' global configuration command enables IP multicast routing. When you configure PIM, IP multicast routing must be enabled on every router over which multicast traffic will flow. If some routers cannot be configured for IP multicast routing (for example, if they do not run a version of the Cisco IOS Software that supports PIM), you need to configure a tunnel so that multicast packets bypass these routers.

The '''ip pim rp-address''' global configuration command specifies the IP address of an interface on the router that is to be the rendezvous point and specifies that access list 1 is to be used to define the multicast groups for which the rendezvous point is to be used. The''' ip pim rp-address''' command must be configured on every sparse-mode router.

The''' ip pim''' interface configuration command enables PIM on the interface, and the '''sparse-mode''' keyword enables sparse mode. When you configure PIM in sparse mode, you should apply the '''ip pim''' command with the '''sparse-mode''' keyword to every interface that you want to forward multicast traffic. The '''access-list''' global configuration command defines a standard IP access list that permits traffic using the multicast address 224.0.1.2 (the Silicon Graphics Dogfight application).

In sparse mode, the PIM-configured interface with the highest IP address on a LAN (subnet) is responsible for sending IGMP host-query messages to all hosts on the LAN and for sending PIM register and join messages toward the rendezvous point.

{{note|To configure a router as a rendezvous point, add the''' ip multicast-routing''' command and the '''ip pim''' command with the''' sparse-mode''' keyword to its configuration. The router recognizes its own IP address as the address of the rendezvous point and automatically assumes the functions of a rendezvous-point function.}}

==== Interoperability with Distance Vector Multicast Routing Protocol ====
The Distance Vector Multicast Routing Protocol (DVMRP) is another multicast protocol that has been developed for IP. DVMRP is similar to dense-mode PIM in that it uses reverse path forwarding. When a router receives a packet, it sends the packet out all interfaces except the interface that leads back to the source of the packet. If the router has interfaces for which no hosts are members of the multicast group for which the packet is intended, the router sends a prune message up the distribution tree to inform the sender that it need not send subsequent packets for this multicast group.

Although the Cisco IOS software does not support DVMRP, it does support interoperability with DVMRP-configured routers. PIM-configured routers dynamically discover DVMRP-configured routers on attached networks. When a DVMRP neighbor is discovered, PIM-configured routers periodically transmit DVMRP report messages advertising the unicast sources that are reachable in the PIM domain. By default, directly connected subnets and networks are advertised. The PIM- configured router forwards multicast packets that it receives from DVMRP routers into the PIM domain and, in turn, forwards multicast packets from the PIM domain to DVMRP routers.

{{note|When PIM-configured routers are directly connected to DVMRP routers or interoperate with DVMRP routers over a tunnel, the DVMRP routers should run mrouted Version 3.8. (The mrouted protocol is a public domain implementation of DVMRP.)}}

===== Interoperability Between Directly Connected Routers =====
[[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM and DVMRP interoperability|Figure: PIM and DVMRP interoperability]] illustrates a topology in which a PIM-configured router is directly connected to a DVMRP-configured router.

===== Figure: PIM and DVMRP interoperability=====

[[image:nd202403.jpg]]

The following commands configure the PIM router for interoperability with the DVMRP router:

<pre>ip multicast-routing
!
interface ethernet 0
ip address 172.16.14.63 255.255.0.0
ip pim dense-mode
ip dvmrp metric 1 list 1
ip dvmrp metric 0 list 2
!
access-list 1 permit 192.168.35.0 0.0.0.255
access-list 1 permit 192.168.36.0 0.0.0.255
access-list 1 permit 192.168.37.0 0.0.0.255
access-list 1 deny 0.0.0.0 255.255.255.255
access-list 2 permit 0.0.0.0 255.255.255.255 </pre>

The''' ip dvmrp metric''' interface configuration commands configure the metric that is to be associated with a set of destinations for DVMRP reports. The first '''ip dvmrp metric''' command causes the routes specified by access list 1 to be advertised to the DVMRP router (in this case, networks 192.168.35.0, 192.168.36.0, and 192.168.37.0). The second '''ip dvmrp metric''' command indicates that the routes specified by access list 2 are not to be advertised (in this case, all other routes). If you do not specify the routes that are to be advertised, only those subnets and networks that are directly connected to the PIM router will be advertised.
===== Interoperability over a Tunnel =====
DVMRP tunnels are used when one or more routers on a path do not support multicast routing. The router then sends and receives multicast packets over the tunnel. This allows a PIM domain to connect to a DVMRP router.

When a PIM-configured router interoperates with DVMRP over a tunnel, it advertises source routes in DVMRP report messages. In addition, the router caches any DVMRP report messages that it receives. The router uses the cached report messages as part of its reverse path forwarding calculation. This allows the router to forward multicast packets that it receives over the tunnel. [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: PIM and DVRMP interoperability over a tunnel interface|Figure: PIM and DVRMP interoperability over a tunnel interface]] illustrates interoperability with DVMRP over a tunnel interface.

===== Figure: PIM and DVRMP interoperability over a tunnel interface=====

[[image:nd202404.jpg]]

The following commands configure the PIM router:

<pre>ip multicast-routing
!
interface tunnel 0
ip address 192.168.47.1 255.255.255.0
ip pim dense-mode
tunnel source ethernet 1
tunnel destination 192.168.92.133
tunnel mode dvmrp
!
interface ethernet 1
ip address 192.168.23.23 255.255.255.0 secondary
ip address 192.168.243.2 255.255.255.0
ip pim dense-mode
ip dvmrp accept-filter 1
!
access-list 1 permit 192.168.48.0 0.0.0.255
access-list 1 permit 192.168.49.0 0.0.0.255
access-list 1 permit 192.168.50.0 0.0.0.255
access-list 1 deny 0.0.0.0 255.255.255.255 </pre>

The '''interface tunnel''' global configuration command creates a tunnel (that is, a virtual interface). The '''tunnel source''' interface configuration command specifies the interface that participates in the tunnel. The '''tunnel destination''' interface configuration command specifies the IP address of the mrouted multicast router at the other end of the tunnel.

The''' tunnel mode''' interface configuration command uses the '''dvmrp''' keyword to configure the tunnel as a DVMRP tunnel. The '''ip address''' interface configuration command assigns an address to the tunnel to enable the sending of IP packets over the tunnel and to cause the router to perform DVMRP summarization. Alternatively, the '''ip unnumbered''' interface configuration command can be used. Either method allows IP multicast packets to flow over the tunnel. If the tunnel has a different network number than the subnet, subnets will not be advertised over the tunnel. In this case, only the network number is advertised over the tunnel.

By specifying the '''dense-mode''' keyword, the '''ip pim''' interface configuration command configures dense-mode PIM on the interface. The '''ip dvmrp accept-filter''' interface configuration command configures an acceptance filter for incoming DVMRP reports. Routes that match the specified access list (in this case, access list 1) are stored in the DVMRP routing table (in this case, 192.168.48.0, 192.168.49.0, and 192.168.50.0). If a Cisco router is a neighbor to router running mrouted Version 3.6, the Cisco router can be configured to advertise network 0.0.0.0 to the DVMRP neighbor by using the '''ip dvmrp default-information''' command and specifying the '''originate''' keyword.
== Using AppleTalk Multicasting ==
For AppleTalk, the Simple Multicast Routing Protocol (SMRP) supports the routing of multicast packets to multicast groups, with packet replication occurring only on those interfaces that have hosts that belong to the multicast group.

Network multimedia applications, such as QuickTime Conferencing (QTC), allow two or more hosts to participate in a QuickTime Conferencing session. End-users join the multicast group for the multicast transmissions they want to receive. SMRP conserves bandwidth by routing AppleTalk packets to all members of a multipoint group without producing duplicate packets on a particular network segment. [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: SMRP in an AppleTalk network|Figure: SMRP in an AppleTalk network]] shows how SMRP works in an AppleTalk network.

===== Figure: SMRP in an AppleTalk network=====

[[image:nd202405.jpg]]

Router A receives a multicast packet from Host A and sends it to Router B. Two interfaces on Router B have hosts that have registered to receive this multicast transmission, so Router B duplicates the packet and sends one packet out on Ethernet interface 1 and the other packet out on Ethernet interface 2. Only one interface on Router C has hosts that have registered to receive this multicast transmission, so Router C sends the packet out on Ethernet interface 1. The following commands configure SMRP on Router A:

<pre>smrp routing
!
interface ethernet 0
smrp protocol appletalk
!
interface ethernet 1
smrp protocol appletalk </pre>

The following commands configure SMRP on Router B:

<pre>smrp routing
!
interface ethernet 0
smrp protocol appletalk
!
interface ethernet 1
smrp protocol appletalk
interface ethernet 2
smrp protocol appletalk </pre>

The following commands configure SMRP on Router C:

<pre>smrp routing
!
interface ethernet 0
smrp protocol appletalk
!
interface ethernet 1
smrp protocol appletalk
!
interface ethernet 2
smrp protocol appletalk </pre>

The''' smrp routing''' global configuration command enables SMRP routing. The '''smrp protocol '''interface configuration command enables SMRP on the interface, and the '''appletalk''' keyword specifies AppleTalk as the OSI Layer 3 protocol for SMRP.
== Multicasting over WAN Connections ==
For the most part, users cannot detect the irregular arrival of data packets, but they can easily detect the irregular arrival of multimedia data, especially when that data includes an audio portion. Irregularly delivered video data is characterized by visible jitter and audible distortion. Smoothing jitter and distortion is especially desirable when multimedia data shares a low-bandwidth link with data traffic, as shown in [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: Multicast over WAN connections|Figure: Multicast over WAN connections]].

===== Figure: Multicast over WAN connections=====

[[image:nd202406.jpg]]

The Cisco IOS software provides three queuing algorithms that you can use to ensure that multicast traffic arrives at its destination without jitter and distortion: weighted fair queuing, priority queuing, and custom queuing. The queuing algorithm that is best for any particular network depends on the traffic flow characteristics of that network. You might want to try all three algorithms to determine the algorithm that provides the smoothest delivery for your particular network connection.
=== Weighted Fair Queuing ===
Weighted fair queuing (introduced in Cisco IOS Software Release 11.0) is enabled by default for all interfaces that have a bandwidth less than or equal to 2048 megabits per second (Mbps) and that do not use Link Access Procedure, Balanced (LAPB), X.25, PPP, or Synchronous Data Link Control (SDLC) encapsulations. (Weighted fair queuing cannot be enabled on interfaces that use these encapsulations.) Weighted fair queuing is a traffic priority management algorithm that identifies conversations (traffic streams) and breaks them up to ensure that capacity is shared fairly. The algorithm examines fields in the packet header to identify unique conversations. For example, for AppleTalk, the algorithm uses the source network, node, and socket number; the destination network, node, and socket number; and the type. For IP, the algorithm uses the protocol, source and destination IP address; source and destination port number; and the TOS (type of service) field.

The weighted fair queuing algorithm sorts conversations into two categories: those that have high bandwidth requirements with respect to the capacity of the interface (such as FTP traffic) and those that have low bandwidth requirements (such as interactive sessions). For streams that have low-bandwidth requirements, the algorithm provides access with little or no queuing, and it shares the remaining bandwidth among other conversations. In effect, weighted fair queuing gives low-bandwidth traffic priority over high-bandwidth traffic, and high-bandwidth traffic shares the transmission service proportionally.

When weighted fair queuing is enabled on an interface, new messages for high-bandwidth conversations are discarded when the congestive-messages threshold is reached (the default congestive-messages threshold is 64 messages). To change the congestive-messages threshold, enter the following command, in which '''number''' is a value between 1 and 512:

fair-queue number

=== Priority Queuing ===
Priority queuing allows you to establish queuing priorities based on protocol type. When you enable priority queuing on an interface, weighted fair queuing is disabled for that interface automatically. The following commands configure priority queuing to ensure a certain quality of service level for Intel ProShare videoconferencing on Router A in [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure: Multicast over WAN connections.|Figure: Multicast over WAN connections.]]:

<pre>interface serial 0
ip address 10.8.0.21 255.0.0.0
priority-group 1
!
access-list 101 permit ip any any
!
priority-list 1 protocol IP high UDP 5715
priority-list 1 protocol IP medium TCP 25
priority-list 1 protocol IP normal TCP 20 </pre>

The '''priority-group''' interface configuration command assigns priority list 1 to serial interface 0. The '''priority-list protocol''' global configuration commands establish a priority list that is associated with priority group 1. The priority list gives high priority to UDP packets destined for port number 5715 (the port number used by Intel ProShare), medium priority to TCP packets destined for port number 25 (SMTP mail), and normal priority to TCP packets destined for port number 20 (FTP data).
=== Custom Queuing ===
Another way to assure the timely delivery of multicast packets is to use custom queuing. With custom queuing, you can define up to 16 queues, assigning normal data to queues 1 through 15 and assigning system messages, such as keepalive messages, to queue 16. The router services each queue sequentially, transmitting a configurable percentage of traffic on each queue before transmitting packets from the next queue.

Custom queuing guarantees that mission-critical data is always assigned a certain percentage of the bandwidth, and it also assures predictable throughput for other traffic. For that reason, custom queuing is recommended for networks that need to provide a guaranteed level of service for all traffic.

When you enable custom queuing on an interface, weighted fair queuing is disabled for that interface automatically. The following commands configure custom queuing for Router A in [[Internetwork Design Guide -- Multicasting in IP and AppleTalk Networks#Figure 6:

<pre>interface serial 0
ip address 10.8.0.21 255.0.0.0
custom-queue-list 1
!
access-list 101 permit ip any any
!
queue-list 1 queue 1 byte-count 57900
queue-list 1 queue 2 byte-count 19300
queue-list 1 queue 3 byte-count 19300
!
queue-list 1 protocol IP 1 UDP 5715
queue-list 1 protocol IP 2 TCP 20
queue-list 1 protocol IP 3 TCP 25 </pre>

The '''custom-queue-list''' interface configuration command assigns custom queue list 1 to serial interface 0. The '''queue-list queue byte-count''' global configuration commands specify the size in bytes for three custom queues (in this case, 57,900, 19,300, and 19,300). Together, these '''queue-list queue byte-count''' commands have the effect of assigning 60 percent of the interface's bandwidth to packets in queue 1, 20 percent of the interface's bandwidth to queue 2, and 20 percent of the interface's bandwidth to queue 3.

The first '''queue-list protocol''' global configuration command assigns UDP packets destined for port 5715 to queue 1. The second '''queue-list protocol''' command assigns TCP packets destined for port 20 (SMTP mail) to queue 2, and the third '''queue-list protocol''' command assigns TCP packets destined for port 25 (FTP data) to queue 3.
== Summary ==
The current popularity of network multimedia applications, such as videoconferencing, is driving the development of protocols that channel the flow of multicast packets to the networks and hosts that want to receive them. As multicasting protocols are deployed, unicast and broadcast applications will be upgraded to take advantage of multicast support, and new multicast applications will be developed.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- STUN for Front-End Processors

2012-10-16T21:29:55Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="stun, front end processor, internetworking"></meta>
Serial tunneling (STUN) enables the integration of traditional systems network architecture (SNA) networks with multiprotocol networks. STUN also lowers operating costs by reducing the need for redundant remote wide-area links. This case study explores three implementations of STUN between Cisco routers and front-end processors (FEPs):
* [[Internetwork Design Guide -- STUN for Front-End Processors#Basic STUN|Basic STUN]]-Presents a STUN implementation that is simple and quick to configure because it does not require the specification of addresses. This implementation is recommended for networks that do not require synchronous data link control (SDLC) address checking or local acknowledgment.
* [[Internetwork Design Guide -- STUN for Front-End Processors#SDLC STUN|SDLC STUN]]-Presents a STUN implementation that includes the configuration of addresses. This implementation is recommended for networks that require SDLC address checking.
* [[Internetwork Design Guide -- STUN for Front-End Processors#SDLC-Transmission Group STUN|SDLC-Transmission Group STUN]]-Presents a STUN implementation that supports enhanced FEP-to-FEP communications features, such as transmission groups, as well as advanced router features. This implementation is recommended for networks that require local acknowledgment.

{{note|This case study introduces basic SNA concepts, but does not discuss them in detail. }}

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

== Understanding FEP Configuration ==
In a traditional SNA environment, serial lines connect FEPs in a master-slave topology, as shown in [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Map of a traditional SNA network|Figure: Map of a traditional SNA network]]. The primary FEP is connected to the IBM host, which is typically an IBM 3090 mainframe. Synchronous modems connect the FEPs.

===== Figure: Map of a traditional SNA network=====

[[image:nd202001.jpg]]

The software running on the FEP is called the Network Control Program (NCP). This section describes NCP configuration parameters and optional NCP features that network administrators must consider when they introduce routers into an FEP environment.
=== Serial Connections ===
Typically, a serial port on a line interface card in the FEP connects the FEP to a synchronous modem. Depending on the type of line interface card, the serial port may be EIA/TIA-232 or V.35. The modem acts as data communications equipment (DCE) and provides clocking and synchronization. The FEP acts as data terminal equipment (DTE). The NCP statement that configures the FEP for DTE is CLOCKNG=EXT.
=== Primary and Secondary Roles ===
The FEPs dynamically determine their primary and secondary roles. Typically, the FEP with the higher subarea address becomes the primary FEP. In some versions of NCP, the role parameter is configurable. Typically, the local FEP (the closest to the mainframe) is the primary FEP, whereas the remote FEP is the secondary FEP.
=== NRZ and NRZI Encoding ===
The NRZI parameter specifies whether the FEP should operate in nonreturn-to-zero inverted (NRZI) mode or in nonreturn-to-zero (NRZ) mode. Both techniques encode binary data on a synchronous serial line. The specification depends on the way the modem operates. Old modems and satellite links that are not sensitive to a pattern of repeated binary ones and zeros (that is, 101010...) operate in NRZI mode. Modems that are sensitive to repeated patterns operate in NRZ mode.

The NCP statement that configures the FEP for NRZI is NRZI=YES, which is the default and is correct for most IBM modems. The NCP statement that configures the FEP for NRZ is NRZI=NO, which is correct for most non-IBM modems.

{{note|All devices on the same SDLC link must use the same encoding scheme. }}

=== MODULO and MAXOUT Parameters ===
The MODULO parameter specifies the number of information frames (I-frames) that NCP can send to the remote device before receiving an acknowledgment. The statement MODULO=8 allows NCP to send seven unacknowledged I-frames, whereas the statement MODULO=128 and the statement MAXOUT=127 allows NCP to send 127 unacknowledged I-frames. (Note that when the MODULO parameter is set to 128, the NCP MAXOUT parameter specifies the number of I-frames that can be sent before receiving an acknowledgment. MAXOUT can range from 8 [the default] to 127.)

Typically, network administrators configure NCP to allow a high number of outstanding I-frames (that is, MODULO=128 and MAXOUT=127) for slow links or for satellite links. Allowing a high number of outstanding I-frames uses the link more efficiently by reducing the number of acknowledgments and by preventing session timeouts. When the MODULO parameter is 128, make sure the TCP output queue on the router is greater than 128.

The SDLC STUN implementation supports setting the MODULO parameter to 8 as well as 128. Note, however, that setting the MODULO parameter to any legal value other than 8 causes the router to use additional buffers to store unacknowledged I-frames.

When local acknowledgment is configured to reduce supervisory frame traffic and to prevent session timeouts, 8 is the only supported value of the MODULO parameter. When the MODULO value is 8, the router does not use additional buffers unnecessarily.
=== ADDRESS Parameter ===
The ADDRESS parameter has the following format: ADDRESS=(line-number, mode).

If mode is FULL, the FEP can send and receive data at the same time. When mode is HALF, the FEP is limited to sending data and then receiving data. The default value of mode is FULL. The value of mode affects the operation of the DUPLEX parameter. For more information, see the "[[Internetwork Design Guide -- STUN for Front-End Processors#DUPLEX Parameter|DUPLEX Parameter]]" section later. The value of line-number specifies the channel adapter position or the relative line number of all the telecommunication links defined for this NCP.

When implementing SDLC STUN or SDLC-Transmission Group STUN, the network administrator must specify SDLC addresses in the configuration of the router. The addresses specified in the router configuration are based on the order in which the ADDRESS parameter appears in the NCP configuration. Consider the following NCP configuration:

<pre>*********************************************************************

* LOCAL NCP LINKS -- PRIMARY FEP *

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

LINK04 GROUP LNCTL=SDLC, GROUP LEVEL X
NPACOLL=YES, <== 3745 Dallas X
DUPLEX=FULL, X
NEWSYNC=NO, X
NRZI=NO, X
SDLCST=(CPRI4,CSEC4), X
RETRIES=(10,5,10), PU LEVEL X
IRETRY=YES, X
MAXOUT=7, X
PASSLIM=254, X
SERVLIM=254, X
ISTATUS=ACTIVE, VTAM-ONLY LEVEL X
OWNER=CMC
*
*--------------------------------------------------------------------
*
X1010442 LINE ADDRESS=(005,FULL) <== 3745 Chicago (01)
S1010442 PU PUTYPE=4
*
X1030442 LINE ADDRESS=(132,FULL) <== 3745 Raleigh (02)
S1030442 PU PUTYPE=4
*
X1010446 LINE ADDRESS=(068,FULL),MODULO=128,ISTATUS=ACTIVE, <== 3745 Houston (03) X
SPEED=56000,SDLCST=(S04PRI,S04SEC)
S1010446 PU PUTYPE=4,MAXOUT=63
*
X1020412 LINE ADDRESS=(100,FULL),MODULO=128,ISTATUS=ACTIVE, <== 3745 Lafayette (04) X
SPEED=56000,SDLCST=(S04PRI,S04SEC)
S1020412 PU PUTYPE=4,MAXOUT=63
*
X1010412 LINE ADDRESS=(112,FULL),SPEED=56000,ISTATUS=ACTIVE <== 3745 Atlanta (05) X
S1010412 PU PUTYPE=4
*
X1010462 LINE ADDRESS=(080,FULL), <== 3745 San Francisco (06) X
NRZI=NO, X
NEWSYNC=NO, X
DUPLEX=FULL, X
ISTATUS=ACTIVE, X
SERVLIM=254, X
SDLCST=(S04PRI,S04SEC), X
MODULO=128, X
SPEED=56000
S1010462 PU PUTYPE=4, X
MAXOUT=63
*
********************************************************************** </pre>

Given this configuration, the router configuration uses address 01 for Chicago, address 02 for Raleigh, address 03 for Houston, address 04 for Lafayette, address 05 for Atlanta, and address 06 for San Francisco.

=== DUPLEX Parameter ===
The DUPLEX parameter specifies whether the communication line and the modem operate in full- or half-duplex mode, and controls the Request To Send (RTS) signal. If the ADDRESS parameter specifies that the mode is FULL, the value of the DUPLEX parameter has no effect, and RTS is always high (that is, permanent RTS). If the ADDRESS parameter specifies that the mode is HALF, the following applies:
* The statement DUPLEX=FULL causes RTS to be permanently high regardless of whether the FEP is sending or receiving data.
* The statement DUPLEX=HALF causes RTS to be high only when the FEP is sending data.
=== Enhanced NCP Features ===
This section describes the following enhanced NCP features that are supported by Cisco routers: transmission groups, echo addressing, and remote NCP loading. Note, however, that the basic STUN and SDLC STUN implementations do not support transmission groups.
===== Transmission Groups =====
A transmission group is one or more parallel SDLC links that connect FEPs. Transmission groups increase the reliability of the logical link connection between FEPs and provide additional bandwidth. When one link fails or congests, NCP uses one of the other links in the group to send data (see [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Map of a network that uses transmission groups|Figure: Map of a network that uses transmission groups]]).

===== Figure: Map of a network that uses transmission groups=====

[[image:nd202002.jpg]]

NCP uses virtual routes to provide more than one route between two FEPs. This multiple active routing mechanism increases the probability that an SDLC route is available when a session needs to be established.

{{note|SDLC-TG STUN is the only implementation that supports transmission groups.}}

===== Echo Addressing =====
Later versions of NCP use echo addressing. With echo addressing, the secondary FEP sets the high-order bit of the SDLC address when sending a response to the primary FEP. For example, the primary FEP sends frames with address 0x01, and the secondary FEP sends frames with address 0x81. This addressing scheme limits the range of SDLC addresses from 0x01 to 0x7F. Although echo addressing is a violation of the SDLC standard, it is supported because it occurs only between FEPs.

{{note|Echo addressing is implicitly supported by the basic STUN implementation because that implementation does not perform any address checking. The '''echo''' keyword of the '''sdlc address '''interface configuration command configures support for echo addressing in the SDLC STUN and SDLC-TG STUN implementations.}}

===== Remote NCP Loading =====
When a local FEP is loading a remote FEP with a new NCP configuration, the local FEP uses a nonstandard form of SDLC to complete the remote NCP load. This violation of the SDLC standard is supported because it occurs only between FEPs.

{{note|The basic STUN implementation implicitly supports remote NCP loading. When used with the '''stun protocol-group''' command, the '''sdlc-tg''' keyword automatically includes support for remote NCP loading in the SDLC-TG STUN implementation.}}

== Understanding FEP-to-FEP Communications with Routers ==
[[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Map showing the addition of routers|Figure: Map showing the addition of routers]] illustrates the topology of an FEP-based network that includes routers. In this multiprotocol topology, the routers already handle traffic between Token Rings and the IBM host. When used to handle traffic between the FEPs, the routers replace the modems and lines that formerly connected the FEPs.

===== Figure: Map showing the addition of routers=====

[[image:nd202003.jpg]]

An EIA/TIA-232 (formerly RS-232) cable or a V.35 cable connects each router to its FEP, and a serial T1 line connects each router to the wide-area network (WAN). The FEPs continue to act as DTE devices, and, by providing clocking and synchronization, the serial interfaces on the routers act as DCE devices.
=== Advanced Router Features ===
When configured for STUN, Cisco routers can take advantage of the following advanced router features: priority queuing, custom queuing, and local acknowledgment.

{{note|When priority queuing or custom queuing is enabled, the router takes longer to switch packets because the processor card has to classify each packet.}}

===== Priority Queuing =====
Priority queuing allows the network administrator to set priorities on the traffic that passes through the network. Packets are classified according to various criteria, including protocol and subprotocol type, and then queued on one of four output queues: high, medium, normal, or low.

A FEP-to-FEP STUN implementation can use priority queuing to prioritize SNA traffic over other protocols that share the same link. The following commands distribute transmission control protocol (TCP) traffic among the four queues and assign STUN traffic encapsulated in TCP to the high queue:

<pre> priority-list 1 ip high tcp 1994
priority-list 1 ip medium tcp 1990
priority-list 1 ip normal tcp 1991
priority-list 1 ip low tcp 1992
priority-list 1 stun high
!
interface serial 0
encapsulation stun
stun group 1
sdlc address 01
stun route address 01 tcp 1.1.1.2 local-ack
priority-group 1 </pre>

{{note|Configure the '''priority-group''' interface configuration command on the STUN input interface.}}

===== Custom Queuing =====
Custom queuing, available in Software Release 9.21 and subsequent software releases, is a queuing strategy that imparts a measure of fairness not provided by priority queuing. The network administrator can control on each interface the minimum percentage of bandwidth allocated to a particular kind of traffic.

When custom queuing is enabled on an interface, the router maintains for that interface eleven output queues (numbered 0 to 10). The router reserves queue number 0 for its own use. The router cycles sequentially through queue numbers 1 to 10, delivering packets in the current queue before moving to the next queue.

Each output queue has an associated configurable byte count that specifies how many bytes of data the router should deliver from the current queue before it moves to the next queue. When the router processes a particular queue, it sends packets until the number of bytes sent exceeds the queue byte count or until the queue is empty.

Custom queuing can be used instead of, but not in addition to, the '''priority-group''' interface configuration command in a single interface. The following configuration commands place STUN traffic on queue 1 with a byte-count limit of 4000 bytes and a maximum of 40 queues:

<pre>stun peer-name 1.1.1.1
stun protocol-group 1 sdlc-tg
!
interface serial 0
encapsulation stun
stun route address 01 tcp 1.1.1.2 local-ack
!
interface serial 1
encapsulation hdlc
custom-queue-list 1
!
queue-list 1 protocol stun 1
queue-list 1 protocol novell 2
queue-list 1 default 3
queue-list 1 queue 1 byte-count 4000
queue-list 1 queue 1 limit 40 </pre>

{{note|Configure the '''custom-queue-list''' interface configuration command on the output interface that connects to the WAN.}}

===== Local Acknowledgment =====
Local acknowledgment is a router feature that prohibits supervisory frames from traversing the WAN, as shown in [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Local acknowledgment limits the range of supervisory frames|Figure: Local acknowledgment limits the range of supervisory frames]].

===== Figure: Local acknowledgment limits the range of supervisory frames=====

[[image:nd202004.jpg]]

Cisco recommends the use of local acknowledgment when one or both of the following conditions exist:
* WAN link use is high-When local acknowledgment is configured, supervisory frames, such as Receiver Ready (RR), Receiver Not Ready (RNR), and Reject (REJ), do not traverse the WAN link. Instead, supervisory frames are locally acknowledged by the router, which reduces the amount of traffic on the WAN link.
* Network delay causes NCP timers to expire-Link congestion, busy local-area networks, or high end-station use can cause excessive network delays, which can result in delayed acknowledgment of I-frames. When configured for local acknowledgment, the router acknowledges I-frames locally, which helps to prevent NCP timers from timing out and closing existing sessions.
=== Basic STUN ===
Basic STUN is easy to configure because it does not require the router configuration to match line addresses that may be configured on the FEPs. The mainframe sends data to the primary FEP, which passes the data to its router. The router for the primary FEP passes the data over an arbitrary medium (serial, fiber distributed data interface [FDDI], Token Ring, or Ethernet) to the router for the secondary FEP, and the router for the secondary FEP sends the data to the secondary FEP. Data from the secondary FEP flows to the mainframe by the reverse path. Network administrators use basic STUN for three purposes:
* To accommodate existing addressing schemes-Some NCP configurations use nonstandard addresses. For example, some configurations use address 0x00 or 0xFF for broadcasts and address 0xC1 for communication. By configuring the router for basic STUN, the network administrator does not have to configure the router to match existing addressing schemes.
* To test connectivity-When network administrators plan to implement SDLC STUN or SDLC-TG STUN, they often implement basic STUN first to verify physical connections.
* To improve performance-Because basic STUN requires minimal processing, it passes frames faster than SDLC STUN and SDLC-TG STUN.

The basic STUN implementation has the following limitations:
* Lack of support for transmission groups, as well as lack of support for advanced router features. For information about advanced router features, see the "[[Internetwork Design Guide -- STUN for Front-End Processors#SDLC-Transmission Group STUN|SDLC-Transmission Group STUN]]" section later in this article.
* Limited output from the router debugging commands.
* Lack of support for multidrop environments. (However, multidrop support is usually a requirement for cluster controller environments rather than FEP environments.)
==== Basic STUN Configuration: Example 1 ====
In [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Topology for basic STUN: example 1|Figure: Topology for basic STUN: example 1]], the routers pass data over an IP WAN. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The serial interfaces on the routers are configured for DCE.

===== Figure: Topology for basic STUN: example 1=====

[[image:nd202005.jpg]]

The following commands configure basic STUN (example 1) for Router A:

<pre>stun peer-name 1.1.1.1
stun protocol-group 1 basic
!
interface serial 0
no ip address
encapsulation stun
stun group 1
stun route all tcp 1.1.2.1
clockrate 19200
!
interface tokenring 0
ip address 1.1.4.1 255.255.255.0
!
interface serial 1
ip address 1.1.3.1 255.255.255.0
!
interface loopback 0
ip address 1.1.1.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

The following commands configure basic STUN (example 1) for Router B:

<pre>stun peer-name 1.1.2.1
stun protocol-group 1 basic
!
interface serial 0
no ip address
encapsulation stun
stun group 1
stun route all tcp 1.1.1.1
clockrate 19200

interface tokenring 0
ip address 1.1.5.1 255.255.255.0
!
interface serial 1
ip address 1.1.3.2 255.255.255.0
!
interface loopback 0
ip address 1.1.2.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>
==== Basic STUN Configuration: Example 2 ====
In [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: Topology for basic STUN: example 2|Figure: Topology for basic STUN: example 2]], the routers transmit data over a Frame Relay WAN. The FEPs are configured for DTE, full-duplex mode, and NRZI encoding. The serial interfaces on the routers are configured for DCE.

===== Figure: Topology for basic STUN: example 2=====

[[image:nd202006.jpg]]

The following commands configure basic STUN (example 2) for Router A:

<pre>stun peer-name 1.1.1.1
stun protocol-group 1 basic
!
interface serial 0
no ip address
encapsulation stun
stun group 1
stun route all tcp 1.1.2.1
nrzi-encoding
clockrate 56000
!
interface tokenring 0
ip address 1.1.4.1 255.255.255.0
!
interface serial 1
ip address 1.1.3.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 1.1.3.2 40 broadcast
!
interface loopback 0
ip address 1.1.1.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

The following commands configure basic STUN (example 2) for Router B:

<pre>stun peer-name 1.1.2.1
stun protocol-group 1 basic
!
interface serial 0
no ip address
encapsulation stun
stun group 1
stun route all tcp 1.1.1.1
nrzi-encoding
clockrate 56000
!
interface tokenring 0
ip address 1.1.5.1 255.255.255.0
interface serial 1
ip address 1.1.3.2 255.255.255.0
encapsulation frame-relay
frame-relay map ip 1.1.3.1 40 broadcast
!
interface loopback 0
ip address 1.1.2.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

{{note|NRZ encoding is the default for all Cisco routers. NRZI encoding is software configurable for Cisco 250x, Cisco 3x04, Cisco 4000 4T, and Cisco 7000 routers. NRZI encoding is hardware configurable for Cisco 4000 2T and AGS+ routers. Full-duplex mode is the default for all router serial cards. Half-duplex mode is software configurable for the Cisco 4000 4T and Cisco 250x routers and is hardware configurable on the EIA/TIA-232/H applique for the AGS+.}}

=== SDLC STUN ===
SDLC STUN is the most commonly used tunneling configuration in Cisco multiprotocol networks. It is frequently implemented for gateways and cluster controllers. SDLC STUN uses the standard SDLC protocol. In most cases, IBM FEPs and compatible FEPs comply with that standard. If an FEP uses a nonstandard form of SDLC, the router must be configured for basic STUN.

The SDLC STUN implementation requires coordination of SDLC addresses between the router and the NCP configuration. To configure the router for SDLC STUN, the network administrator must know the relative position of the ADDRESS parameters in the NCP configuration. For details, see the earlier "[[Internetwork Design Guide -- STUN for Front-End Processors#ADDRESS Parameter|ADDRESS Parameter]]" section. Network administrators use SDLC STUN for two purposes:
* To support specific addressing schemes-SDLC STUN allows the network administrator to configure specific line addresses. SDLC STUN is required in certain environments, such as multidrop, that depend on specific addresses.
* To support network tuning and monitoring-Occasionally, the network administrator needs to tune and monitor the SNA SDLC and multiprotocol network.

SDLC STUN is limited by its lack of support for transmission groups.
==== Configuring SDLC STUN ====
In [[Internetwork Design Guide -- STUN for Front-End Processors#Figure: SDLC STUN topology|Figure: SDLC STUN topology]], the routers transmit data over a serial line. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The router serial interfaces are configured as DCE devices.

===== Figure: SDLC STUN topology=====

[[image:nd202007.jpg]]

The following commands configure SDLC STUN for Router A:

<pre>stun peer-name 1.1.1.1
stun protocol-group 1 sdlc
!
interface serial 0
no ip address
encapsulation stun
sdlc address 04
stun route address 04 interface s1
stun route address ff interface s1
clockrate 19200
!
interface tokenring 0
ip address 1.1.4.1 255.255.255.0
!
interface serial 1
ip address 1.1.3.1 255.255.255.0
!
interface loopback 0
ip address 1.1.1.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

The following commands configure SDLC STUN for Router B:

<pre>stun peer-name 1.1.2.1
stun protocol-group 1 sdlc
!
interface serial 0
no ip address
encapsulation stun
sdlc address 04
stun route address 04 interface s1
stun route address ff interface s1
clockrate 19200
!
interface tokenring 0
ip address 1.1.5.1 255.255.255.0
!
interface serial 1
ip address 1.1.3.2 255.255.255.0
!
interface loopback 0
ip address 1.1.2.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

=== SDLC-Transmission Group STUN ===
SDLC-Transmission Group (TG) STUN is a complex implementation that supports enhanced NCP features.When configuring STUN-TG, many network administrators also configure the routers to take advantage of the advanced features described in the "[[Internetwork Design Guide -- STUN for Front-End Processors#Advanced Router Features|Advanced Router Features]]" section earlier in this article. Because these features increase memory and processor use, they should be used only when necessary to support the existing network or to relieve congestion. SDLC-TG STUN forces local acknowledgment. If you do not want to configure local acknowledgment, use the basic STUN or the SDLC STUN implementation.

The SDLC-TG implementation requires coordination of SDLC addresses between the router and the NCP configuration. To configure the router for SDLC-TG, the network administrator must know the relative position of the ADDRESS parameters in the NCP configuration. For details, see the "[[Internetwork Design Guide -- STUN for Front-End Processors#ADDRESS Parameter|ADDRESS Parameter]]" section earlier in this article.
==== Configuring SDLC-TG STUN ====
[[Internetwork Design Guide -- STUN for Front-End Processors#Figure: The SDLC-TG STUN topology|Figure: The SDLC-TG STUN topology]] illustrates a network that implements SDLC-TG STUN. The routers transmit data over an IP WAN. The FEPs are configured for DTE, full-duplex mode, and NRZ encoding. The serial interfaces on the routers are configured as DCE devices.

===== Figure: The SDLC-TG STUN topology=====

[[image:nd202008.jpg]]

To the primary FEP, Router A looks like a secondary FEP. To the secondary FEP, Router B looks like a primary FEP. The following commands configure SDLC-TG STUN for Router A:

<pre>stun peer-name 1.1.1.1
stun remote-peer-keepalive
stun protocol-group 1 sdlc-tg
!
interface tokenring 0
ip address 1.1.4.1 255.255.255.0
!
interface serial 1
mtu 4400
hold-queue 150 in
no ip address
encapsulation stun
stun group 1
stun sdlc-role secondary
sdlc n1 35200
sdlc address 01 echo
stun route address 1 tcp 1.1.2.1 local-ack tcp-queue-max 120
clockrate 56000

interface serial 2
mtu 4400
hold-queue 150 in
no ip address
encapsulation stun
stun group 1
stun sdlc-role secondary
sdlc n1 35200
sdlc address 02 echo
stun route address 2 tcp 1.1.2.1 local-ack tcp-queue-max 120
clockrate 56000
!
interface serial 3
ip address 1.1.3.1
interface loopback 0
ip address 1.1.1.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

The following commands configure SDLC-TG STUN for Router B:

<pre>stun peer-name 1.1.2.1
stun remote-peer-keepalive
stun protocol-group 1 sdlc-tg
!
interface tokenring 0
ip address 1.1.5.1 255.255.255.0
!
interface serial 1
mtu 4400
hold-queue 150 in
no ip address
encapsulation stun
stun group 1
stun sdlc-role primary
sdlc line-speed 56000
sdlc n1 35200
sdlc address 01 echo
stun route address 1 tcp 1.1.1.1 local-ack tcp-queue-max 120
clockrate 56000
!
interface serial 2
mtu 4400
hold-queue 150 in
no ip address
encapsulation stun
stun group 1
stun sdlc-role primary
sdlc line-speed 56000
sdlc n1 35200
sdlc address 02 echo
stun route address 2 tcp 1.1.1.1 local-ack tcp-queue-max 120
clockrate 56000
!
interface serial 3
ip address 1.1.3.2
!
interface loopback 0
ip address 1.1.2.1 255.255.255.0
!
router igrp 1
network 1.0.0.0 </pre>

The '''stun peer-name '''global configuration command identifies this router as a peer to its peer group.

The '''stun remote-peer-keepalive '''global configuration command causes Router A and Router B to exchange keepalive messages on each idle line. (An idle line is a line over which no I-frames are flowing.) Keepalive messages allow a router to detect when its peer router is not longer available. A peer router might become unavailable if it goes down or if the line goes down. The routers do not send keepalive traffic to the FEPs.

Routers send keepalive messages over an idle line at a default interval of 30 seconds and waits three times that interval for a response. If the router does not receive a response, it closes the STUN session.

The '''stun protocol-group''' global configuration command establishes a protocol group that is part of an SNA transmission group. The''' sdlc-tg''' keyword can be used only when the '''stun route address tcp''' interface configuration command is used to configure local acknowledgment and TCP encapsulation. The SDLC broadcast address 0xFF is routed automatically for interfaces on which the '''sdlc-tg''' keyword is configured. The '''stun protocol-group''' global configuration command also alerts the router that it should support transmission group features, such as the following:
* Echo addressing
* Transmission group rerouting if a single link in a multilink transmission group goes down
* Remote NCP load
* Broadcast addressing

The '''mtu''' interface configuration command specifies a maximum transmission unit (MTU) of 4400 bytes, which is the highest recommended value, for the interface. The value of the NCP MAXDATA parameter should be no more than the MTU on the router interface. The recommended value of MAXDATA is 4096 bytes.

{{note|Depending on the version of NCP, the MAXDATA parameter may or may not take into account the number of bytes in the frame header (which, for example, includes the source and destination address of the frame), so the MTU on the router interface should be at least 100 bytes larger than the value of MAXDATA in the NCP configuration.}}

The '''hold-queue''' interface configuration command increases the size of the input hold queue from 75 packets (the default) to 150 packets. The specified value should be greater than the depth of the TCP output queue (as specified by the '''tcp-queue-max''' keyword of the '''stun route address tcp''' interface configuration command). Increasing the size of the input hold queue allows flow control to activate when the TCP output queue reaches a threshold of 90 percent, which occurs before the input interface throttling mechanism can activate.

The '''stun sdlc-role primary '''interface configuration command is used when the router is connected to a secondary FEP. The '''stun sdlc-role secondary''' interface configuration command is used when the router is connected to a primary FEP.

On the primary router, the '''sdlc line-speed''' interface configuration command adjusts the SDLC poll timer based on the line speed. The line speed argument should be equal to the speed of the line connected to the interface, regardless of whether the interface is configured as a DCE or a DTE.

The '''sdlc n1''' interface configuration command specifies the maximum size (in bits) of an incoming frame on the SDLC link and is required when the MTU is not 1500 bytes (the default). The '''sdlc n1''' command must be eight times larger than the value specified by the''' stun''' command.

The '''sdlc address''' interface configuration command specifies an SDLC address. The specified address must be the same as the relative line number at which the ADDRESS parameter is specified in the NCP configuration of the FEP to which the router is connected. (For more information, see the "[[Internetwork Design Guide -- STUN for Front-End Processors#ADDRESS Parameter|ADDRESS Parameter]]" section earlier in this article.) The''' echo''' keyword causes the router to treat nonecho (for example, 0x01) and echo (for example, 0x81) SDLC addresses as the same address. The '''sdlc address''' interface configuration command is valid only for interfaces on which the '''stun protocol-group''' command with the''' sdlc-tg''' keyword is configured. Only one '''sdlc address''' interface configuration command with '''echo''' keyword is required per interface.

The '''stun route address tcp''' interface configuration command specifies TCP encapsulation. The value of address specifies the SDLC address, which must be specified with the echo bit turned off. The '''local-ack '''keyword causes the router to perform local acknowledgment and is required when the '''sdlc-tg''' keyword appears with the '''stun protocol-group''' command. The '''tcp-queue-max''' keyword sets the maximum size of the TCP output queue for a serial line. The default is 100 packets. The recommended minimum is 70, and the recommended maximum is 500. The '''clockrate''' interface configuration command specifies the clocking speed when the serial interface is in DCE mode.
== Summary ==
This case study presents three types of STUN implementations in SNA environments: basic STUN, SDLC STUN, and SDLC-TG STUN. Although basic STUN is the easiest to configure because it does not require the configuration of line addresses on the router, it does not support local acknowledgment. Compared to basic STUN, the SDLC STUN implementation is the most flexible because it supports, but does not require, local acknowledgment. However, the use of SDLC STUN is limited because it does not support transmission groups. SDLC-TG STUN is not as flexible as SDLC STUN because it enforces local acknowledgment. At the same time, SDLC-TG STUN is the only STUN implementation that supports transmission groups.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks

2012-10-16T21:29:17Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="sap, ipx, internetworking"></meta>
One of the limiting factors in the operation of large Novell Internetwork Packet Exchange (IPX) internetworks is the amount of bandwidth consumed by the large, periodic Service Advertisement Protocol (SAP) updates. Novell servers periodically send clients information about the services they provide by broadcasting this information onto their connected local-area network (LAN) or wide-area network (WAN) interfaces. Routers are required to propagate SAP updates through an IPX network so that all clients can see the service messages. It is possible to reduce SAP traffic on Novell IPX networks by the following means:
* Filtering SAP updates through access lists. SAP updates can be filtered by prohibiting routers from advertising services from specified Novell servers.
* Configuring Cisco routers on Novell IPX networks to run Enhanced IGRP. Although filters provide a means of eliminating the advertisements of specified services, Enhanced IGRP provides incremental SAP updates for a finer granularity of control. Complete SAP updates are sent periodically on each interface only until an IPX Enhanced IGRP neighbor is found. Thereafter, SAP updates are sent only when there are changes to the SAP table. In this way, bandwidth is conserved, and the advertisement of services is reduced without being eliminated.
* Incremental SAP updates are automatic on serial interfaces and can be configured on LAN media. Enhanced IGRP also provides partial routing updates and fast convergence for IPX networks. Administrators may choose to run only the partial SAP updates or to run both the reliable SAP protocol and the partial routing update portion of Enhanced IGRP.
* Configuring Cisco routers on Novell IPX networks to send incremental SAP updates. With Software Release 10.0, the incremental SAP updates just described can be configured for Cisco routers on Novell IPX networks, without the requirement of running the routing update feature of Enhanced IGRP (only the partial SAP updates are enabled). This feature is supported on all interface types. Again, SAP updates are sent only when changes occur on a network. Only the changes to SAP tables are sent as updates.

To illustrate how to reduce SAP traffic, this case study is organized into two parts:
* [[Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks#Configuring Access Lists to Filter SAP Updates|Configuring Access Lists to Filter SAP Updates]]
* [[Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks#Configuring Incremental SAP Updates|Configuring Incremental SAP Updates]]

{{note|For a detailed case study on configuring Novell IPX Enhanced IGRP, see the [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Novell IPX Network|Novell IPX Network]] section in [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Integrating Enhanced IGRP into Existing Networks|Integrating Enhanced IGRP into Existing Networks]].}}

The internet work for this case study is illustrated in [[Internetwork Design Guide -- Reducing SAP Traffic in Novell IPX Networks#Figure: Large-scale Novell IPX internetwork|Figure: Large-scale Novell IPX internetwork]]. The following portions of a large-scale Novell IPX network spanning across a Frame Relay WAN are examined:
* Router A connects from the Frame Relay internetwork to the central site with three Novell servers.
* Router B connects from the Frame Relay internetwork to a remote site with one Novell client and one Novell server.
* Router C connects from the Frame Relay internetwork to a remote site with two Novell clients.

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

===== Figure: Large-scale Novell IPX internetwork=====

[[image:nd201801.jpg]]

== Configuring Access Lists to Filter SAP Updates ==
Access lists can control which routers send or receive SAP updates and which routers do not send or receive SAP updates. SAP access lists can be defined to filter SAP updates based on the source network address of a SAP entry, the type of SAP entry (file server, print server, and so forth), and the name of the SAP server. A SAP access list is made up of entries in the following format:

access-list n [deny|permit] network[.node] [service-type[server-name]]

where n is between 1000-1099. A network number of -1 indicates any network, and a service type of 0 indicates any service. For example, the following access list accepts print server SAP entries from server PRINTER_1, all file servers, and any other SAP entries from network 123 except those from a server called UNTRUSTED; all other SAP entries are to be ignored:

access-list 1000 permit -1 47 PRINTER_1
access-list 1000 permit -1 4
access-list 1000 deny 123 0 UNTRUSTED
access-list 1000 permit 123

When checking the entries in a SAP update, each statement in the access list is processed in order, and if there is no match for a SAP entry, it is not accepted. Thus, to block server UNTRUSTED, the '''deny''' statement must be placed before the '''permit''' for all other devices on network 123.

Two techniques can be used with filtering. Either the SAP entries that are required can be permitted and the rest denied, or the unwanted SAP entries can be denied and the rest permitted. In general, the first method is preferred because it avoids new and unexpected services being propagated throughout the network.

The most common form of SAP filtering is to limit which services are available across a WAN. For example, it does not, in general, make sense for clients in one location to be able to access print servers in another location because printing is a local operation. In this case study, only file servers are permitted to be visible across the WAN.
=== Central Site ===
Router A connects to the central site. The following access lists configured on Router A permit everything except print servers from being announced out the serial interface:

<pre>access-list 1000 deny -1 47
access-list 1000 permit -1
!
interface serial 0
ipx network 10
ipx output-sap-filter 1000 </pre>

To permit only IPX file servers and to deny all other IPX servers, use the following configuration:

<pre>access-list 1000 permit -1 4
!
interface serial 0
ipx network 10
ipx out-sap-filter 1000 </pre>
=== Remote Sites ===
This section provides information on the configuration of the routers at the remote sites:
* Router B connected to an IPX server and client
* Router C connected to two IPX clients
==== IPX Server and Client ====
For Router B, the following access lists permit everything except print servers from being announced out the serial interface.

<pre>access-list 1000 deny -1 47
access-list 1000 permit -1
!
interface serial 1
ipx network 10
ipx output-sap-filter 1000 </pre>

To permit only IPX file servers and to deny all other IPX servers, use the following configuration:

<pre>access-list 1000 permit -1 4
!
interface serial 1
ipx network 10
ipx out-sap-filter 1000 </pre>
==== IPX Clients ====
Router C does not require an access list configuration because the remote site does not have any servers. Only Novell servers generate SAP updates.
== Configuring Incremental SAP Updates ==
Incremental SAP updates allow any-to-any connectivity with reduced network SAP overhead. Instead of eliminating the receipt of SAP updates entirely, all necessary IPX services can be broadcast to remote sites only as changes to the SAP tables occur.
=== Central Site ===
To configure Enhanced IGRP encapsulated SAP updates to be sent only on a incremental basis, use the following configuration. Although the defined Enhanced IGRP autonomous system number is 999, Enhanced IGRP routing (and routing updates) are not performed because of the '''rsup-only''' keyword used with the '''ipx sap-incremental''' command. The '''rsup-only''' keyword indicates a reliable SAP update.

<pre>interface ethernet 0
ipx network 20
!
interface serial 0
ipx network 10
ipx sap-incremental eigrp 999 rsup-only
!
ipx router eigrp 999
network 10 </pre>

To configure both incremental SAP and Enhanced IGRP routing, simply configure Enhanced IGRP with the following commands:

<pre>interface ethernet 0
ipx network 20
!
interface serial 0
ipx network 10
!
ipx router eigrp 999
network 10 </pre>
=== Remote Sites ===
This section provides information on the configuration of the routers at the remote sites:
* Router B connected to an IPX server and client
* Router C connected to two IPX clients
==== IPX Server and Client ====
To configure Enhanced IGRP encapsulated SAP updates to be sent only on a incremental basis, use the following configuration for Router B. Although the defined Enhanced IGRP autonomous system number is 999, Enhanced IGRP routing is not performed because of the '''rsup-only''' keyword used with the '''ipx sap-incremental '''command.

<pre>interface ethernet 1
ipx network 30
!
interface serial 1
ipx network 10
ipx sap-incremental eigrp 999 rsup-only
!
ipx router eigrp 999
network 10</pre>

To configure both incremental SAP and Enhanced IGRP routing, simply configure Enhanced IGRP with the following commands:

<pre>interface ethernet 1
ipx network 30
!
interface serial 1
ipx network 10
!
ipx router eigrp 999
network 10 </pre>
==== IPX Clients ====
To configure Enhanced IGRP encapsulated SAP updates to be sent only on a incremental basis, use the following configuration for Router C:

<pre>interface ethernet 2
ipx network 40
!
interface serial 2
ipx network 10
ipx sap-incremental eigrp 999 rsup-only
!
ipx router eigrp 999
network 10 </pre>

Even though there are no servers, these configuration commands are required to support the incremental SAP updates being advertised from the central site and other remote sites to Router C.
== Summary ==
This case study illustrates two methods of reducing SAP traffic on Novell IPX networks: the use of access lists to eliminate the advertisements of specified services, and the use of the incremental SAP feature to exchange SAP changes as they occur. This technique eliminates periodic SAP updates.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks

2012-10-16T21:28:47Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="eirgp, internetworking"></meta>
The Enhanced Interior Gateway Routing Protocol (IGRP) combines the ease of use of traditional routing protocols with the fast rerouting capabilities of link-state protocols, providing advanced capabilities for fast convergence and partial updates. When a network topology change occurs, the Diffusing Algorithm (DUAL) used with Enhanced IGRP provides convergence in less than five seconds in most cases. This is equivalent to the convergence achieved by link-state protocols such as Open Shortest Path First (OSPF), Novell Link Services Protocol (NLSP), and Intermediate System-to-Intermediate System (IS-IS). In addition, Enhanced IGRP sends routing update information only when changes occur, and only the changed information is sent to affected routers.

Enhanced IGRP supports three network level protocols: IP, AppleTalk, and Novell Internetwork Packet Exchange (IPX). Each of these has protocol-specific, value-added functionality. IP Enhanced IGRP supports variable-length subnet masks (VLSMs). IPX Novell Enhanced IGRP supports incremental Service Advertisement Protocol (SAP) updates, removes the Routing Information Protocol (RIP) limitation of 15 hop counts, and provides optimal path use. A router running AppleTalk Enhanced IGRP supports partial, bounded routing updates and provides load sharing and optimal path use.

The case study provided here discusses the benefits and considerations involved in integrating Enhanced IGRP into the following types of internetworks:
* IP-The existing IP network is running IGRP
* Novell IPX-The existing IPX network is running RIP and SAP
* AppleTalk-The existing AppleTalk network is running the Routing Table Maintenance Protocol (RTMP)

When integrating Enhanced IGRP into existing networks, plan a phased implementation. Add Enhanced IGRP at the periphery of the network by configuring Enhanced IGRP on a boundary router on the backbone off the core network. Then integrate Enhanced IGRP into the core network.

{{note|For a discussion of Enhanced IGRP network design considerations and details on DUAL convergence, see the Internetwork Design Guide. }}

{{Caution|If you are using candidate default route in IP Enhanced IGRP and have installed multiple releases of Cisco router software within your internetwork that include any versions prior to September 1994, contact your Cisco technical support representative for version compatibility and software upgrade information. Refer to your software release notes for details. If you plan to implement Enhanced IGRP over a Frame Relay network, you should ensure that your network is hierarchical in design and adheres to sound design principles.}}

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

== IP Network ==
This case study illustrates the integration of Enhanced IGRP into an IGRP internetwork in two phases: configuring an IGRP network and adding Enhanced IGRP to the network. The key considerations for integrating Enhanced IGRP into an IP network running IGRP are as follows:
* Route selection
* Metric handling
* Redistribution from IGRP to Enhanced IGRP and vice versa
* Route summarization
=== Configuring an IGRP Network ===
IGRP is a dynamic distance vector routing protocol designed by Cisco Systems in the mid-1980s for routing in an autonomous system (AS) containing large, arbitrarily complex networks with diverse media.

An autonomous system is a collection of interconnected routers under common management control, or with similar routing policies and requirements. Typically, an autonomous system consists of routers connecting multiple IP network numbers. Routes originating from one autonomous system that need to be advertised into other autonomous systems must be redistributed.

In [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Configuring an IGRP network|Figure: Configuring an IGRP network]], Routers A, B, C, and D are configured to run IGRP in autonomous system 68.

===== Figure: Configuring an IGRP network=====

[[image:nd201701.jpg]]

The configuration commands to enable IGRP routing for Routers A, B, C, and D are as follows:

router igrp 68
network 192.150.42.0

=== Adding Enhanced IGRP to IGRP Networks ===
This section provides two examples of adding Enhanced IGRP to IGRP networks:
* [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Adding Enhanced IGRP to a Single IGRP Network|Adding Enhanced IGRP to a Single IGRP Network]]
* [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Adding Enhanced IGRP to Multiple IGRP Networks|Adding Enhanced IGRP to Multiple IGRP Networks]]
==== Adding Enhanced IGRP to a Single IGRP Network ====
In [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Adding Enhanced IGRP to a single IGRP network|Figure: Adding Enhanced IGRP to a single IGRP network]], Router E acts as the boundary router, running both IGRP and Enhanced IGRP, and redistributing information between IGRP autonomous system 68 into the Enhanced IGRP autonomous system 68.

===== Figure: Adding Enhanced IGRP to a single IGRP network=====

[[image:nd201702.jpg]]

Router E, the boundary router, is configured to run both IGRP and Enhanced IGRP as follows:

<pre>router igrp 68
network 192.150.42.0
router eigrp 68
network 192.150.42.0 </pre>

{{note|Redistribution is automatic because the autonomous system number for IGRP and Enhanced IGRP are the same.}}

Router F runs Enhanced IGRP only:

router eigrp 68
network 192.150.42.0

A '''show ip route''' command on Router E shows networks that are directly connected (C), routes learned from IGRP (I), and routes learned from Enhanced IGRP (D):

<pre>192.150.42.0 is subnetted (mask is 255.255.255.248), 7 subnets
C 192.150.42.120 is directly connected, Ethernet4
I 192.150.42.48 [100/2860] via 192.150.42.123, 0:00:08, Ethernet4
I 192.150.42.40 [100/2850] via 192.150.42.121, 0:00:08, Ethernet4
I 192.150.42.32 [100/2850] via 192.150.42.121, 0:00:08, Ethernet4
I 192.150.42.24 [100/2760] via 192.150.42.123, 0:00:08, Ethernet4
D 192.150.42.16 [90/30720] via 192.150.42.10, 0:00:38, Fddi0
C 192.150.42.8 is directly connected, Fddi0 </pre>

A '''show ip route''' command on Router F shows that all routes are learned via enhanced IGRP (D) or are directly connected (C):

<pre>192.150.42.0 is subnetted (mask is 255.255.255.248), 7 subnets
D 192.150.42.120 [90/729600] via 192.150.42.9, 0:01:16, Fddi0
D EX 192.150.42.48 [170/757760] via 192.150.42.9, 0:01:16, Fddi0
D EX 192.150.42.40 [170/755200] via 192.150.42.9, 0:01:16, Fddi0
D EX 192.150.42.32 [170/755200] via 192.150.42.9, 0:01:16, Fddi0
D EX 192.150.42.24 [170/732160] via 192.150.42.9, 0:01:16, Fddi0
C 192.150.42.16 is directly connected, Ethernet0
C 192.150.42.8 is directly connected, Fddi0 </pre>

Subnetwork 120 is seen as an internal route. All other routes are external (EX) because they were learned via IGRP in Router E and redistributed into Enhanced IGRP.

A '''show ip eigrp topology''' command on Router F shows that the state of each of the networks is passive (P) and that each network has one successor and lists the feasible distance (FD) of each successor via a neighbor to the destination. The computed/advertised metric is listed. Then the interface through which the neighbor network is available is provided.

<pre>IP-EIGRP Topology Table for process 68
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 192.150.42.120 255.255.255.248, 1 successors, FD is 2172416
via 192.150.42.9 (2172416/2169856), Fddi0
P 192.150.42.8 255.255.255.248, 1 successors, FD is 28160
via Connected, Fddi0
P 192.150.42.48 255.255.255.248, 1 successors, FD is 2560515840
via 192.150.42.9 (2560515840/2560513280), Fddi0
P 192.150.42.16 255.255.255.248, 1 successors, FD is 281600
via Connected, Ethernet0
P 192.150.42.40 255.255.255.248, 1 successors, FD is 2560026880
via 192.150.42.9 (2560026880/2560001280), Fddi0
P 192.150.42.32 255.255.255.248, 1 successors, FD is 2560026880
via 192.150.42.9 (2560026880/2560001280), Fddi0 </pre>

==== Adding Enhanced IGRP to Multiple IGRP Networks ====
In [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Adding Enhanced IGRP to multiple IGRP networks|Figure: Adding Enhanced IGRP to multiple IGRP networks]], Routers A, B, and C are connected to each other through several different networks. Routers A, B, and C are configured to run IGRP only within IGRP autonomous system (AS) 68. Router A redistributes static routes for subnetworks of network 9.0.0.0 (not shown). Assume that the IGRP AS continues at network 10.0.0.0.

===== Figure: Adding Enhanced IGRP to multiple IGRP networks=====

[[image:nd201703.jpg]]

The configuration for Router A is as follows:

<pre>router igrp 68
network 10.0.0.0
network 11.0.0.0
default-metric 1000 100 1 1 1500
redistribute static
ip route 9.1.0.0 255.255.0.0 e0
ip route 9.2.0.0 255.255.0.0 e1 </pre>

The configuration for Router B is as follows:

router igrp 68
network 11.0.0.0

The configuration for Router C is as follows:
router igrp 68
network 11.0.0.0
network 12.0.0.0

This example takes you through the steps to add Enhanced IGRP to the internetwork one router at a time:

'''Step 1 '''Configure Enhanced IGRP for Router C as follows:

router eigrp 68
network 11.0.0.0
network 12.0.0.0

Because they are directly connected networks, Router C automatically summarizes networks 11.0.0.0 and 12.0.0.0 in its routing updates. Router C learns about networks 9.0.0.0 and 10.0.0.0 through IGRP. Networks 9.0.0.0 and 10.0.0.0 are already IGRP- summarized by Router A before they reach Router C.

 '''Step 2 '''Configure Router A to run Enhanced IGRP as follows:

<pre>router eigrp 68
network 10.0.0.0
network 11.0.0.0
default-metric 1000 100 1 1 1500
redistribute static </pre>

Router A now automatically summarizes networks 10.0.0.0 and 11.0.0.0 in its Enhanced IGRP routing updates. It also continues to summarize these networks in its IGRP routing updates. However, automatic summarization of network 9.0.0.0 through Enhanced IGRP is not performed.

Router C now learns Enhanced IGRP routes for specific subnetworks of network 9.0.0.0 from Router A. At the same time, Router C continues to receive a summary route for network 9.0.0.0 though IGRP from Router A. The summary route for network 10.0.0.0, which Router C had previously learned through IGRP from Router A, is replaced with an Enhanced IGRP route in Router C's routing table.

 '''Step 3 '''Configure Router A to ensure that Router C does not unnecessarily learn about specific subnetworks of network 9.0.0.0. The following commands enable summarization of network 9.0.0.0 at Router A:

interface serial 1
ip summary-address eigrp 68 9.0.0.0 255.0.0.0

With this configuration on Router A, Router C's IGRP summary route for network 9.0.0.0 is replaced with an Enhanced IGRP summary route, and the more specific subnetworks of network 9.0.0.0 are no longer known by Router C.

 '''Step 4 '''Enable Enhanced IGRP on Router B as follows:

router eigrp 68
network 11.0.0.0

 '''Step 5 '''Ensure that Router B does not unnecessarily learn about specific subnetworks of network 9.0.0.0. Therefore, configure summarization of network 9.0.0.0 at Router A as follows:

interface serial 0
ip summary-address eigrp 68 9.0.0.0 255.0.0.0

With this configuration on Router A, Router B learns a summary route for network 12.0.0.0 through Enhanced IGRP from Router C. Router B learns summary routes for networks 9.0.0.0 and 10.0.0.0 through Enhanced IGRP from Router A.

 '''Step 6 '''Now that both of the next hop routers (Routers B and C) are running Enhanced IGRP, it is no longer necessary for these routers to run IGRP. Disable IGRP on Routers B and C with the following command:

no router igrp 68

Router A continues to run both IGRP and Enhanced IGRP and redistribute static routes.

If there were more routers on the network, you could continue deployment of Enhanced IGRP throughout network 10.0.0.0 one router at a time.
==== Route Selection ====
Enhanced IGRP uses three kinds of routes: internal, external, and summary. Internal routes are routes that are learned from Enhanced IGRP. External routes are routes that are learned from another protocol and then redistributed into Enhanced IGRP. Summary routes are routes that Enhanced IGRP may dynamically create due to auto summarization, or due to an explicit summary route configuration. Route selection is based on administrative distance. The default administrative distance for Enhanced IGRP is 90 (internal), 170 (external), or 5 (summary). For IGRP, the default administrative distance is 100 because internal Enhanced IGRP routes take precedence over IGRP routes, and IGRP routes are preferred to external Enhanced IGRP routes.
==== Metric Handling ====
The metric calculation and default metric value for IGRP and Enhanced IGRP are the same. By default, the composite metric is the sum of the segment delays and the lowest segment bandwidth (scaled and inverted) for a given route. Although you can adjust the default value with the '''metric weights''' command, the defaults were carefully selected to provide excellent operation in most networks.
==== Redistribution ====
Enhanced IGRP can be added to an IGRP network in two ways: using the same IGRP AS number or using a new AS number. If Enhanced IGRP uses the same AS number as IGRP, redistribution of IGRP into Enhanced IGRP and redistribution of Enhanced IGRP into IGRP occurs. If Enhanced IGRP uses a different AS number, the network administrator needs to configure redistribution manually with the '''redistribute''' command. For redistributing information from Enhanced IGRP into other dynamic routing protocols besides IGRP and vice versa, the designer must use the '''redistribute '''and '''default-metric''' commands. IGRP routes redistributed into Enhanced IGRP are marked as external.
==== Route Summarization ====
With IGRP, routing information advertised out an interface is often automatically summarized at major network number boundaries. Specifically, this automatic summarization occurs for those routes whose major network number differs from the major network number of the interface to which the advertisement is being sent. The remaining routes, which are part of the major network number of the interface, are advertised without summarization. For the following example, refer to [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Route summarization|Figure: Route summarization]].

===== Figure: Route summarization=====

[[image:nd201704.jpg]]

In this example, Router A is directly connected to two different major networks and configured as follows:

<pre>interface ethernet 0
ip address 128.105.1.1 255.255.255.0
interface fddi 1
ip address 128.105.2.1 255.255.255.0
interface ethernet 2
ip address 128.106.1.1 255.255.255.0
router igrp 5
network 128.105.0.0
network 128.106.0.0 </pre>

When advertising routing information out Ethernet interface 0, IGRP will summarize network 128.106.0.0 and will not summarize network 128.105.0.0. Therefore, IGRP will advertise routes for 128.106.0.0 with a network mask of 255.255.0.0 and routes for 128.105.2.1 with a network mask of 255.255.255.0.

Because it provides automatic route summarization, Enhanced IGRP will advertise the same routing information in the previous IGRP example. However, in the Enhanced IGRP example that follows, the previous configuration is modified so that it allows redistribution of routing information that is not summarized:

<pre>ip route 128.107.1.0 255.255.255.0 128.106.1.2
router eigrp 5
redistribute static
network 128.105.0.0
network 128.106.0.0
router igrp 5
redistribute static </pre>

At this point, there is a third subnetted major network in the IP routing table. When advertising out Ethernet interface 0, IGRP will summarize the route for 128.107.1.0 as 128.107.0.0 with a network mask of 255.255.0.0. However, Enhanced IGRP will not summarize network 128.107.0.0. It will advertise 128.107.1.0 with network mask 255.255.255.0. Enhanced IGRP's automatic summarization only applies to networks that are directly connected, not redistributed. For Enhanced IGRP, you can explicitly cause network 128.107.0.0 to be summarized out all three interfaces as shown in the following example:

<pre>interface ethernet 0
ip summary-address eigrp 5 128.107.0.0 255.255.0.0
interface fddi 1
ip summary-address eigrp 5 128.107.0.0 255.255.0.0
interface ethernet 2
ip summary-address eigrp 5 128.107.0.0 255.255.0.0 </pre>
=== Redistribution between Enhanced IGRP and RIP ===
[[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Redistributing RIP routes into Enhanced IGRP|Figure: Redistributing RIP routes into Enhanced IGRP]] shows a router that connects two networks; one network uses RIP and the other network uses Enhanced IGRP. The goal for the router is to advertise RIP routes in the Enhanced IGRP network and to advertise Enhanced IGRP routes in the RIP network, while preventing the occurrence of route feedback. (That is, the router must be configured so that Enhanced IGRP does not send routes learned from RIP back into the RIP network and so that RIP does not send routes learned from Enhanced IGRP back into the Enhanced IGRP network.)

===== Figure: Redistributing RIP routes into Enhanced IGRP=====

[[image:nd201705.jpg]]

The RIP portion of the configuration for Router A is as follows:

<pre>router rip
network 171.108.0.0
redistribute eigrp 90
default-metric 2
passive-interface serial 0 </pre>

The '''router rip''' global configuration command starts a RIP process.

The '''network''' router configuration command specifies that the RIP process is to send RIP updates out on the interfaces that are directly connected to network number 171.108.0.0. In this case, the RIP process will send updates out on Ethernet interface 0 and not on serial interface 0 because of the '''passive-interface''' command applied to serial interface 0.

The '''redistribute eigrp''' router configuration command specifies that routing information derived from Enhanced IGRP be advertised in RIP routing updates.

The '''default-metric''' router configuration command causes RIP to use the same metric value (in this case, a hop count of 2) for all routes obtained from Enhanced IGRP. A default metric helps solve the problem of redistributing routes that have incompatible metrics. Whenever metrics do not convert, using a default metric provides a reasonable substitute and enables the redistribution to proceed.

The '''passive-interface''' router configuration command disables the sending of routing updates on serial interface 0. In this case, the '''passive-interface''' command is used with RIP, which means the router does not send out any updates on a passive interface, but the router still processes updates that it receives on that interface.The result is that the router still learns of networks that are behind a passive interface. (The same is true when the '''passive-interface''' command is used with IGRP.)

The Enhanced IGRP portion of the configuration for Router A is as follows:

<pre>router eigrp 90
network 171.108.0.0
redistribute rip
default-metric 1544 100 255 1 1500
distribute-list 1 in
passive interface ethernet 0
access-list 1 permit ip 171.108.1.0 255.255.255.0
access-list 1 permit ip 171.108.2.0 255.255.255.0
access-list 1 permit ip 171.108.3.0 255.255.255.0
access-list 1 permit ip 171.108.4.0 255.255.255.0
access-list 1 permit ip 171.108.5.0 255.255.255.0
access-list 1 permit ip 171.108.6.0 255.255.255.0
access-list 1 permit ip 171.108.7.0 255.255.255.0
access-list 1 permit ip 171.108.8.0 255.255.255.0
access-list 1 permit ip 171.108.9.0 255.255.255.0
access-list 1 permit ip 171.108.10.0 255.255.255.0
access-list 1 deny ip </pre>

The''' router eigrp''' global configuration command starts an Enhanced IGRP process and assigns to it autonomous system number 90.

The '''network''' router configuration command specifies that the Enhanced IGRP process is to send Enhanced IGRP updates to the interfaces that are directly connected to network number 171.108.0.0. In this case, the Enhanced IGRP process will send updates out on serial interface 0 and not on Ethernet interface 0 because of the '''passive-interface''' command applied to Ethernet interface 0.

The '''redistribute eigrp''' configuration command specifies that routing information derived from RIP be advertised in Enhanced IGRP routing updates.

The '''default-metric''' router configuration command assigns an Enhanced IGRP metric to all RIP-derived routes. The first value (1544) specifies a minimum bandwidth of 1544 kilobits per second. The second value (100) specifies a route delay in tens of microseconds. The third value (255) specifies the connection is guaranteed to be 100 percent reliable. The fourth value (1) specifies the effective bandwidth of the route. The fifth value (1500) specifies in bytes the maximum transmission unit (MTU) of the route.

The '''distribute-list in''' router configuration command causes the router to use access list 1 to filter networks learned from RIP and allows only those networks that match the list to be redistributed into Enhanced IGRP. This prevents route feedback loops from occurring.

When used with Enhanced IGRP, the '''passive-interface''' router configuration command has a different effect than it has when used with RIP or IGRP. When the '''passive-interface''' command is used with Enhanced IGRP, the router does not send out any updates-including hello messages-on the interface. Because hello messages are not sent, the router cannot discover any neighbors on that interface, which means that the router does not learn about networks that are behind a passive interface.

Access list 1 permits subnetworks 1 through 10 and denies all other networks. Although ten statements have been used, this particular access list could be written with four '''access-list''' commands if the address space had been divided efficiently. This example illustrates the need to think carefully about how to divide an address space. For example, if the RIP AS had been subnets 0 through 7, a single access list statement would have covered all of the subnetworks. The implication is that, when using a protocol that can summarize, summarization can be achieved much more efficiently when the IP address space is divided optimally. For information about dividing an IP address space optimally, see [[Internetwork Design Guide -- Subnetting an IP Address Space#Subnetting an IP Address Space|Subnetting an IP Address Space]].
== Novell IPX Network ==
This case study illustrates the integration of Enhanced IGRP into a Novell IPX internetwork in two phases: configuring an IPX network and adding Enhanced IGRP to the IPX network. The key considerations for integrating Enhanced IGRP into an IPX network running RIP and SAP are as follows:
* Route selection
* Redistribution metric handling
* Redistribution from IPX RIP to Enhanced IGRP and vice versa
* Reducing SAP traffic
=== Configuring a Novell IPX Network ===
Cisco's implementation of Novell's IPX protocol provides all the functions of a Novell router. In this case study, routers are configured to run Novell IPX. (See [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Configuring a Novell IPX network|Figure: Configuring a Novell IPX network]].)

===== Figure: Configuring a Novell IPX network=====

[[image:nd201706.jpg]]

The configuration commands to enable IPX routing for Router A are as follows:

<pre>ipx routing
interface ethernet 0
ipx network 2ad
interface ethernet 1
ipx network 3bc </pre>

{{note|In Software Release 9.21 and later, the command to enable Novell IPX routing is '''ipx''' rather than '''novell'''.}}

=== Adding Enhanced IGRP to a Novell IPX Network ===
Enhanced IGRP for a Novell IPX network has the same fast rerouting and partial update capabilities as Enhanced IGRP for IP. In addition, Enhanced IGRP has several capabilities that are designed to facilitate the building of large, robust Novell IPX networks.

The first capability is support for incremental SAP updates. Novell IPX RIP routers send out large RIP and SAP updates every 60 seconds. This can consume substantial amounts of bandwidth. Enhanced IGRP for IPX sends out SAP updates only when changes occur and sends only changed information.

The second capability that Enhanced IGRP adds to IPX networks is the ability to build large networks. IPX RIP networks have a diameter limit of 15 hops. Enhanced IGRP networks can have a diameter of 224 hops.

The third capability that Enhanced IGRP for Novell IPX provides is optimal path selection. The RIP metric for route determination is based on ticks with hop count used as a tie-breaker. If more than one route has the same value for the tick metric, the route with the least number of hops is preferred. Instead of ticks and hop count, IPX Enhanced IGRP uses a combination of these metrics: delay, bandwidth, reliability, and load. For an illustration of how IPX Enhanced IGRP provides optimal path selection, see [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Enhanced IGRP Novell IPX optimal path utilization|Figure: Enhanced IGRP Novell IPX optimal path utilization]].

===== Figure: Enhanced IGRP Novell IPX optimal path utilization=====

[[image:nd201707.jpg]]

Both Ethernet and FDDI interfaces have a tick value of 1. If configured for Novell RIP, Router A will choose the Ethernet connection via network 4 to reach network 5 because Router D is only one hop away from Router A. However, the fastest path to network 5 is two hops away, via the FDDI rings. With IPX Enhanced IGRP configured, Router A will automatically take the optimal path through Routers B and C to reach network 5.

To add Enhanced IGRP to a Novell RIP and SAP network, configure Enhanced IGRP on the Cisco router interfaces that connect to other Cisco routers also running Enhanced IGRP. Configure RIP and SAP on the interfaces that connect to Novell hosts and or Novell routers that do not support Enhanced IGRP.

In [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Adding Enhanced IGRP to a Novell IPX network|Figure: Adding Enhanced IGRP to a Novell IPX network]], Routers E, F, and G are running IPX Enhanced IGRP. Router E redistributes Enhanced IGRP route information via Network AA to Router D.

===== Figure: Adding Enhanced IGRP to a Novell IPX network=====

[[image:nd201708.jpg]]

The configuration for Router E is as follows:

<pre>ipx routing
interface ethernet 0
ipx network AA
interface serial 0
ipx network 20
interface serial 1
ipx network 30
ipx router eigrp 10
network 20
network 30
ipx router rip
no network 20 </pre>

With Enhanced IGRP configured, periodic SAP updates are replaced with Enhanced IGRP incremental updates when an Enhanced IGRP peer is found. Unless RIP is explicitly disabled for an IPX network number, as shown for network 20, both RIP and Enhanced IGRP will be active on the interface associated with that network number. Based on the above configuration, and assuming an Enhanced IGRP peer on each Enhanced IGRP configured interface, RIP updates are sent on networks AA and 30, while Enhanced IGRP routing updates are sent on networks 20 and 30. Incremental SAP updates are sent on network 20 and network 30, and periodic SAP updates are sent on network AA.

The configuration for Router F is as follows:

<pre>ipx routing
interface ethernet 0
ipx network 45
interface serial 0
ipx network 30
ipx router eigrp 10
network 30
network 45</pre>

Partial output for a '''show ipx route''' command on Router E indicates that network 45 was discovered using Enhanced IGRP (E), whereas network BB was discovered via a RIP (R) update:

<pre>R Net 3bc
R Net 2ad
C Net 20 (HDLC), is directly connected, 66 uses, Serial0
C Net 30 (HDLC), is directly connected, 73 uses, Serial1
E Net 45 [2195456/0] via 30.0000.0c00.c47e, age 0:01:23, 1 uses, Serial1
C Net AA (NOVELL-ETHER), is directly connected, 3 uses, Ethernet0
R Net BB [1/1] via AA.0000.0c03.8b25, 48 sec, 87 uses, Ethernet0 </pre>

Partial output for a '''show ipx route''' command on Router F indicates that networks 20, AA, and BB were discovered using Enhanced IGRP (E):

<pre>E Net 20 [2681856/0] via 30.0000.0c01.f0ed, age 0:02:57, 1 uses, Serial0
C Net 30 (HDLC), is directly connected, 47 uses, Serial0
C Net 45 (NOVELL-ETHER), is directly connected, 45 uses, Ethernet0
E Net AA [267008000/0] via 30.0000.0c01.f0ed, age 0:02:57, 1 uses, Serial0
E Net BB [268416000/2] via 30.0000.0c01.f0ed, age 0:02:57, 11 uses, Serial0 </pre>

A '''show ipx servers''' command on Router E shows that server information was learned via periodic (P) SAP updates:

<pre>Codes: S - Static, I - Incremental, P - Periodic, H - Holddown
5 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
P 4 Networkers 100.0000.0000.0001:0666 2/02 2 Et1
P 5 Chicago 100.0000.0000.0001:0234 2/02 2 Et1
P 7 Michigan 100.0000.0000.0001:0123 2/02 2 Et1
P 8 NetTest1 200.0000.0000.0001:0345 2/02 2 Et1
P 8 NetTest 200.0000.0000.0001:0456 2/02 2 Et1 </pre>

A '''show ipx servers''' command on Router F shows that server information was learned via incremental SAP (I) updates allowed with Enhanced IGRP:

<pre>Codes: S - Static, I - Incremental, P - Periodic, H - Holddown
5 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
I 4 Networkers 100.0000.0000.0001:0666 268416000/03 3 Se0
I 5 Chicago 100.0000.0000.0001:0234 268416000/03 3 Se0
I 7 Michigan 100.0000.0000.0001:0123 268416000/03 3 Se0
I 8 NetTest1 200.0000.0000.0001:0345 268416000/03 3 Se0
I 8 NetTest 200.0000.0000.0001:0456 268416000/03 3 Se0 </pre>

A '''show ipx eigrp topology''' command on Router E shows that the state of the networks is passive (P) and that each network provides one successor, and it lists the feasible distance (FD) of each successor via a neighbor to the destination. For example, for network 45, the neighbor is located at address 0000.0c00.c47e and the computed/advertised cost metric for that neighbor to the destination is 2195456/281600:

<pre>IPX EIGRP Topology Table for process 10
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 20, 1 successors, FD is 1
via Connected, Serial0
P 30, 1 successors, FD is 1
via Connected, Serial1
P 45, 1 successors, FD is 2195456
via 30.0000.0c00.c47e (2195456/281600), Serial1
P AA, 1 successors, FD is 266496000
via Redistributed (266496000/0),
P BB, 1 successors, FD is 267904000
via Redistributed (267904000/0), </pre>

The output for a''' show ipx eigrp topology''' command on Router F lists the following information:

<pre>IPX EIGRP Topology Table for process 10
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 20, 1 successors, FD is 2681856
via 30.0000.0c01.f0ed (2681856/2169856), Serial0
P 30, 1 successors, FD is 1
via Connected, Serial0
P 45, 1 successors, FD is 1
via Connected, Ethernet0
P AA, 1 successors, FD is 267008000
via 30.0000.0c01.f0ed (267008000/266496000), Serial0
P BB, 1 successors, FD is 268416000
via 30.0000.0c01.f0ed (268416000/267904000), Serial0 </pre>

==== Route Selection ====
IPX Enhanced IGRP routes are automatically preferred over RIP routes regardless of metrics unless a RIP route has a hop count less than the external hop count carried in the Enhanced IGRP update, for example, a server advertising its own internal network.
==== Redistribution and Metric Handling ====
Redistribution is automatic between RIP and Enhanced IGRP, and vice versa. Automatic redistribution can be turned off using the '''no redistribute''' command. Redistribution is not automatic between different Enhanced IGRP autonomous systems.

The metric handling for integrating RIP into Enhanced IGRP is bandwidth plus delay, left shifted by 8 bits. The metric handling for Enhanced IGRP to RIP is the external metric plus 1. An IPX Enhanced IGRP router that is redistributing RIP into Enhanced IGRP takes the RIP metric associated with each RIP route, increments it, and stores that metric in the Enhanced IGRP routing table as the external metric.

In [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: IPX metric handling example|Figure: IPX metric handling example]], a Novell IPX server with an internal network number of 100 advertises this network number using RIP on network 222. Router A hears this advertisement and installs it in its routing table as being 1 hop and 1 tick away. Router A then announces this network to Router B on network 501 using Enhanced IGRP.

===== Figure: IPX metric handling example=====

[[image:nd201709.jpg]]

The configuration for Router A is as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 222
!
interface serial 0
ipx network 501
!
ipx router eigrp 9000
network 222
network 501
!
!The following commands turn off IPX RIP on the serial interface:
!
ipx router rip
no network 501 </pre>

The configuration for Router B is as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 601
!
interface serial 0
ipx network 501
ipx router eigrp 9000
network 501
network 601
!
!The following command turns off IPX RIP on this router:
!
no ipx router rip </pre>

The configuration for Router C is as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 333
!
interface ethernet 1
ipx network 601
!
ipx router eigrp 9000
network 333
network 601
!
!The following commands turn off IPX RIP on ethernet 1:
!
ipx router rip
no network 601 </pre>

The configuration for Router D is as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 333
!
interface ethernet 1
ipx network AAA </pre>

The output from a '''show ipx route''' command on Router A is as follows:

<pre>R Net 100 [1/1] via 222.0260.8c4c.4f22, 59 sec, 1 uses, Ethernet0
C Net 222 (ARPA), is directly connected, 1252 uses, Ethernet0
E Net 333 [46277376/0] via 501.0000.0c05.84bc, age 0:04:07, 1 uses, Serial0
C Net 501 (HDLC), is directly connected, 3908 uses, Serial0
E Net 601 [46251776/0] via 501.0000.0c05.84bc, age 5:21:38, 1 uses, Serial0
E Net AAA [268441600/2] via 501.0000.0c05.84bc, age 0:16:23, 1 uses, Serial0 </pre>

The output from a '''show ipx route '''command on Router B is as follows:

<pre> E Net 100 [268416000/2] via 501.0000.0c05.84b4, age 0:07:30, 2 uses, Serial0
E Net 222 [267008000/0] via 501.0000.0c05.84b4, age 0:07:30, 1 uses, Serial0
E Net 333 [307200/0] via 601.0000.0c05.84d3, age 0:07:30, 1 uses, Ethernet0
C Net 501 (HDLC), is directly connected, 4934 uses, Serial0
C Net 601 (NOVELL-ETHER), is directly connected, 16304 uses, Ethernet0
E Net AAA [267929600/2] via 601.0000.0c05.84d3, age 0:14:40, 1 uses, Ethernet0 </pre>

The output from a '''show ipx route''' command on Router C is as follows:

<pre>E Net 100 [268441600/2] via 601.0000.0c05.84bf, age 0:07:33, 1 uses, Ethernet1
E Net 222 [267033600/0] via 601.0000.0c05.84bf, age 0:07:34, 1 uses, Ethernet1
C Net 333 (NOVELL-ETHER), is directly connected, 15121 uses, Ethernet0
E Net 501 [46251776/0] via 601.0000.0c05.84bf, age 0:07:32, 9 uses, Ethernet1
C Net 601 (NOVELL-ETHER), is directly connected, 1346 uses, Ethernet1
R Net AAA [1/1] via 333.0000.0c05.8b25, 35 sec, 1 uses, Ethernet0 </pre>

The output from a '''show ipx route''' command on Router D is as follows:

<pre>R Net 100 [8/2] via 333.0000.0c05.84d1, 18 sec, 1 uses, Ethernet0
R Net 222 [6/1] via 333.0000.0c05.84d1, 18 sec, 1 uses, Ethernet0
R Net 333 [1/1] via 333.0000.0c05.84d1, 18 sec, 1 uses, Ethernet0
R Net 501 [3/1] via 333.0000.0c05.84d1, 17 sec, 3 uses, Ethernet0
R Net 601 [1/1] via 333.0000.0c05.84d1, 18 sec, 1 uses, Ethernet0
C Net AAA (SNAP), is directly connected, 20 uses, Ethernet1 </pre>

The Enhanced IGRP metric is created using the RIP ticks for the delay vector. The hop count is incremented and stored as the external metric. The external delay is also stored. Router B computes the metric to network 100 given the information received from Router A and installs this in its routing table. In this case, the tick value for network 100 is 8.

The "2" after the slash in the routing entry for network 100 is the external metric. This number does not increase again while the route is in the Enhanced IGRP autonomous system. Router C computes the metric to network 100 through Router B and stores it in its routing table. Finally, Router C redistributes this information back into RIP with a hop count of 2 (the external metric) and a tick value derived from the original tick value of the RIP route (1) plus the Enhanced IGRP delay through the autonomous system converted to ticks.
==== Reducing SAP Traffic ====
Novell IPX RIP routers send out large RIP and SAP updates every 60 seconds regardless of whether a change has occurred. These updates can consume a substantial amount of bandwidth. You can reduce SAP update traffic by configuring Enhanced IGRP to do incremental SAP updates. When Enhanced IGRP is configured for incremental SAP updates, the updates consist only of information that has changed and the updates are sent out only when a change occurs, thus saving bandwidth.

When you configure Enhanced IGRP for incremental SAP updates, you can do the following:
* Retain RIP, in which case only the reliable transport of Enhanced IGRP is used for sending incremental SAP updates. (This is the preferred configuration over bandwidth-sensitive connections.)
* Turn off RIP, in which case Enhanced IGRP replaces RIP as the routing protocol.

[[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Example of incremental SAP updates|Figure: Example of incremental SAP updates]] shows a bandwidth-sensitive topology in which configuring incremental SAP updates is especially useful. The topology consists of a corporate network that uses a 56-Kbps Frame Relay connection to communicate with a remote branch office. The corporate network has several Novell servers, each of which advertises many services. Depending on the number of servers and the number of advertised services, a large portion of the available bandwidth could easily be consumed by SAP updates.

===== Figure: Example of incremental SAP updates=====

[[image:nd201710.jpg]]

Router A is configured as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 100
!
interface serial 0
encapsulation frame-relay
!
interface serial 0.1 point-to-point
ipx network 200
ipx sap-incremental eigrp 90 rsup-only
frame-relay interface-dlci 101
!
ipx router eigrp 90
network 200 </pre>

The''' ipx routing''' global configuration command enables IPX routing on the router.

The '''ipx network''' interface configuration command enables IPX routing on Ethernet interface 0 for network 100.

For serial interface 0, the '''encapsulation frame-relay''' interface configuration command establishes Frame Relay encapsulation using Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the DLCI and 2 bytes to identify the packet type.

The '''interface serial''' global configuration command establishes a point-to-point subinterface ('''0.1'''). Subinterfaces are logical interfaces associated with a physical interface. Using subinterfaces allows Router A to receive multiple simultaneous connections over a single Frame Relay interface.

The '''ipx network''' interface configuration command enables IPX routing on subinterface serial interface 0.1 for network 200.

The '''ipx sap-incremental''' interface configuration command enables the incremental SAP feature. The required '''eigrp''' keyword enables Enhanced IGRP and its transport mechanism and, in this case, specifies an autonomous system number of 90. Because this command uses the '''rsup-only''' keyword, the router sends incremental SAP updates on this link.

The '''frame-relay interface-dlci''' interface configuration command associates data link connection identifier (DLCI) 101 with subinterface serial interface 0.1.

The '''ipx router eigrp''' global configuration command starts an Enhanced IGRP process and assigns to it autonomous system number 90.

The '''network''' IPX-router configuration command enables Enhanced IGRP for network 200.

Router B is configured as follows:

<pre>ipx routing
!
interface ethernet 0
ipx network 300
!
interface serial 0
encapsulation frame-relay
ipx network 200
ipx sap-incremental eigrp 90 rsup-only
!
ipx router eigrp 90
network 200 </pre>

The '''ipx routing''' global configuration command enables IPX routing on the router.

The '''ipx network''' interface configuration command enables IPX routing on Ethernet interface 0 for network 300.

On serial interface 0, the '''encapsulation frame-relay''' interface configuration command establishes Frame Relay encapsulation using Cisco's own encapsulation, which is a 4-byte header, with 2 bytes to identify the DLCI and 2 bytes to identify the packet type.

The '''ipx network''' interface configuration command enables IPX routing on subinterface serial 0 for network 200.

The '''ipx sap-incremental''' interface configuration command enables the incremental SAP feature. The required '''eigrp''' keyword enables Enhanced IGRP and its transport mechanism and, in this case, specifies an autonomous system number of 90. Because this command uses the '''rsup-only''' keyword, the router sends incremental SAP updates on this link.

The '''ipx router eigrp''' global configuration command starts an Enhanced IGRP process and assigns to it autonomous system number 90.

The '''network''' IPX-router configuration command enables Enhanced IGRP for network 200.

{{note|The absence of the '''ipx router rip''' command means the IPX RIP is still being used for IPX routing, and the use of the '''rsup-only''' keyword means that the router is sending incremental SAP updates over the Frame Relay link.}}

== AppleTalk Network ==
This case study illustrates the integration of Enhanced IGRP into an existing AppleTalk internetwork in two phases: configuring an AppleTalk network and adding Enhanced IGRP to an AppleTalk network. The key considerations for integrating Enhanced IGRP into an AppleTalk network are as follows:
* Route selection
* Metric handling
* Redistribution from AppleTalk to Enhanced IGRP and vice versa
===Configuring an AppleTalk Network===
Cisco routers support AppleTalk Phase 1 and AppleTalk Phase 2. For AppleTalk Phase 2, Cisco routers support both extended and nonextended networks. In this case study, Routers A, B, and C are running AppleTalk, as illustrated in [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Configuring an AppleTalk network|Figure: Configuring an AppleTalk network]].

===== Figure: Configuring an AppleTalk network=====

[[image:nd201711.jpg]]

The configuration for Router A is as follows:

<pre>appletalk routing
interface ethernet 0
appletalk cable-range 10-10
appletalk zone casestudy
interface serial 0
appletalk cable-range 50-50
appletalk zone casestudy </pre>
=== Adding Enhanced IGRP to an AppleTalk Network ===
To add Enhanced IGRP to an AppleTalk network, configure Enhanced IGRP on the interface that connects to the routers. Do not disable RTMP on the interfaces that connect to AppleTalk hosts or that connect to AppleTalk routers that do not support Enhanced IGRP. RTMP is the enabled by default when AppleTalk routing is enabled and when an interface is assigned an AppleTalk cable range.

In this case study, Routers D and E are running AppleTalk Enhanced IGRP. Routers F and G run both AppleTalk and AppleTalk Enhanced IGRP. Router G redistributes the routes from the AppleTalk network to the AppleTalk Enhanced IGRP network, and vice versa. (See [[Internetwork Design Guide -- Integrating Enhanced IGRP into Existing Networks#Figure: Example of adding Enhanced IGRP to an AppleTalk network|Figure: Example of adding Enhanced IGRP to an AppleTalk network]].)

===== Figure: Example of adding Enhanced IGRP to an AppleTalk network=====

[[image:nd201712.jpg]]

The configuration for Router G is as follows:

<pre>appletalk routing eigrp 1
interface ethernet 1
appletalk cable-range 125-125
appletalk zone Marketing Lab
appletalk protocol eigrp
interface serial 1
appletalk cable-range 126-126
appletalk zone WAN
appletalk protocol eigrp
no appletalk protocol rtmp </pre>

The configuration for Router F is as follows:

<pre>appletalk routing eigrp 2
interface serial 0
appletalk cable-range 126-126
appletalk zone WAN
appletalk protocol eigrp
no appletalk protocol rtmp </pre>

A''' show appletalk route''' command on Router G shows that the first set of routes is learned from an RTMP update, that the second set of routes is directly connected, and that the last route is learned by AppleTalk Enhanced IGRP via serial interface 1:

<pre>R Net 103-103 [1/G] via 125.220, 0 sec, Ethernet1, zone Marketing Lab
R Net 104-104 [1/G] via 125.220, 1 sec, Ethernet1, zone Marketing Lab
R Net 105-105 [1/G] via 125.220, 1 sec, Ethernet1, zone Marketing Lab
R Net 108-108 [1/G] via 125.220, 1 sec, Ethernet1, zone Marketing Lab
C Net 125-125 directly connected, Ethernet1, zone Marketing Lab
C Net 126-126 directly connected, Serial1, zone Wan
E Net 127-127 [1/G] via 126.201, 114 sec, Serial1, zone Networkers </pre>

A '''show appletalk route '''command on Router F shows that routes are learned from AppleTalk Enhanced IGRP:

<pre>E Net 103-103 [2/G] via 126.220, 519 sec, Serial0, zone Marketing Lab
E Net 104-104 [2/G] via 126.220, 520 sec, Serial0, zone Marketing Lab
E Net 105-105 [2/G] via 126.220, 520 sec, Serial0, zone Marketing Lab
E Net 108-108 [2/G] via 126.220, 520 sec, Serial0, zone Marketing Lab
E Net 125-125 [1/G] via 126.220, 520 sec, Serial0, zone Marketing Lab
C Net 126-126 directly connected, Serial0, zone Wan
C Net 127-127 directly connected, Ethernet1, zone Networkers </pre>

==== Route Selection ====
AppleTalk Enhanced IGRP routes are automatically preferred over Routing Table Maintenance Protocol (RTMP) routes. Whereas the AppleTalk metric for route determination is based on hop count only, AppleTalk Enhanced IGRP uses a combination of these configurable metrics: delay, bandwidth, reliability, and load.
==== Metric Handling ====
The formula for converting RTMP metrics to AppleTalk Enhanced IGRP metrics is hop count multiplied by 252524800. This is a constant based on the bandwidth for a 9.6-Kbps serial line and includes an RTMP factor. An RTMP hop distributed into Enhanced IGRP appears as a slightly worse path than an Enhanced IGRP-native, 9.6-Kbps serial link. The formula for converting Enhanced IGRP to RTMP is the value of the Enhanced IGRP external metric plus 1.
==== Redistribution ====
Redistribution between AppleTalk and Enhanced IGRP and vice versa is automatic by default. Redistribution involves converting the Enhanced IGRP metric back into an RTMP hop count metric. In reality, there is no conversion of an Enhanced IGRP composite metric into a RTMP metric. Because a hop count is carried in an Enhanced IGRP metric tuple as the Enhanced IGRP route spreads through the network, 1 is added to the hop-count carried in the Enhanced IGRP metric blocks through the network and put into any RTMP routing tuple generated.

There is no conversion of an Enhanced IGRP metric back into an RTMP metric because, in reality, what RTMP uses as a metric (the hop count) is carried along the Enhanced IGRP metric all the way through the network. This is true of Enhanced IGRP-derived routes and routes propagated through the network that were originally derived from an RTMP route.
== Summary ==
This case study illustrates the integration of Enhanced IGRP in graduated steps, starting at the periphery of the network before adding Enhanced IGRP into the core network. With Enhanced IGRP for IP networks, route summarization and redistribution of routing updates are key considerations. To add Enhanced IGRP to IPX networks, it is critical to configure RIP and SAP on interfaces connecting to Novell hosts or routers that do not support Enhanced IGRP. When adding Enhanced IGRP to AppleTalk networks, turn off RTMP on the interfaces that are configured to support Enhanced IGRP.

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]

Internetwork Design Guide -- Increasing Security on IP Networks

2012-10-16T21:28:19Z

Pzimmerm: added metadata

{{Template:Required Metadata}}
<meta name="keywords" content="security, internetworking"></meta>
Network security is a broad topic that can be addressed at the data link, or media, level (where packet snooping and encryption problems can occur), at the network, or protocol, layer (the point at which Internet Protocol (IP) packets and routing updates are controlled), and at the application layer (where, for example, host-level bugs become issues).

As more users access the Internet and as companies expand their networks, the challenge to provide security for internal networks becomes increasingly difficult. Companies must determine which areas of their internal networks they must protect, learn how to restrict user access to these areas, and determine which types of network services they should filter to prevent potential security breaches.

Cisco Systems provides several network, or protocol, layer features to increase security on IP networks. These features include controls to restrict access to routers and communication servers by way of console port, Telnet, Simple Network Management Protocol (SNMP), Terminal Access Controller Access Control System (TACACS), vendor token cards, and access lists. Firewall architecture setup is also discussed.

{{caution|Although this case study addresses network-layer security issues, which are the most relevant in the context of an Internet connection, ignoring host-level security, even with network-layer filtering in place, can be dangerous. For host-level security measures, refer to your application's documentation and the recommended reading list at the end of this case study.}}

{| align="right" border="1"
|align="center"|'''Guide Contents'''
|-
|[[Internetwork Design Guide#Internetworking Design Basics|Internetworking Design Basics]] [[Internetwork Design Guide#Designing various internetworks|Designing various internetworks]] [[Internetwork Design Guide#Network Enhancements|Network Enhancements]] [[Internetwork Design Guide#IP Routing Concepts|IP Routing Concepts]] [[Internetwork Design Guide#UDP Broadcast Flooding|UDP Broadcast Flooding]] [[ Internetwork Design Guide#Large-Scale H.323 Network Design for Service Providers|Large-Scale H.323 Network Design for Service Providers]] [[Internetwork Design Guide#LAN Switching|LAN Switching]] [[Internetwork Design Guide#Subnetting an IP Address Space|Subnetting an IP Address Space]] [[Internetwork Design Guide#IBM Serial Link Implementation Notes|IBM Serial Link Implementation Notes]] [[Internetwork Design Guide#References and Recommended Reading|References and Recommended Reading]]
|}

== Understanding Cisco's Approach to Network Security ==
When most people talk about security, they mean ensuring that users can only perform tasks they are authorized to do, can only obtain information they are authorized to have, and cannot cause damage to the data, applications, or operating environment of a system.

The word security connotes protection against malicious attack by outsiders. Security also involves controlling the effects of errors and equipment failures. Anything that can protect against a deliberate, intelligent, calculated attack will probably prevent random misfortune as well.

Security measures keep people honest in the same way that locks do. This case study provides specific actions you can take to improve the security of your network. Before going into specifics, however, it will help if you understand the following basic concepts that are essential to any security system:
* Know your enemy
: This case study refers to attackers or intruders. Consider who might want to circumvent your security measures and identify their motivations. Determine what they might want to do and the damage that they could cause to your network.
: Security measures can never make it impossible for a user to perform unauthorized tasks with a computer system. They can only make it harder. The goal is to make sure the network security controls are beyond the attacker's ability or motivation.
* Count the cost
: Security measures almost always reduce convenience, especially for sophisticated users. Security can delay work and create expensive administrative and educational overhead. It can use significant computing resources and require dedicated hardware.
: When you design your security measures, understand their costs and weigh those costs against the potential benefits. To do that, you must understand the costs of the measures themselves and the costs and likelihoods of security breaches. If you incur security costs out of proportion to the actual dangers, you have done yourself a disservice.
* Identify your assumptions
: Every security system has underlying assumptions. For example, you might assume that your network is not tapped, or that attackers know less than you do, that they are using standard software, or that a locked room is safe. Be sure to examine and justify your assumptions. Any hidden assumption is a potential security hole.
* Control your secrets
: Most security is based on secrets. Passwords and encryption keys, for example, are secrets. Too often, though, the secrets are not really all that secret. The most important part of keeping secrets is knowing the areas you need to protect. What knowledge would enable someone to circumvent your system? You should jealously guard that knowledge and assume that everything else is known to your adversaries. The more secrets you have, the harder it will be to keep all of them. Security systems should be designed so that only a limited number of secrets need to be kept.
* Remember human factors

Many security procedures fail because their designers do not consider how users will react to them. For example, because they can be difficult to remember, automatically generated "nonsense" passwords are often found written on the undersides of keyboards. For convenience, a "secure" door that leads to the system's only tape drive is sometimes propped open. For expediency, unauthorized modems are often connected to a network to avoid onerous dial-in security measures.

If your security measures interfere with essential use of the system, those measures will be resisted and perhaps circumvented. To win compliance, you must make sure that users can get their work done, and you must sell your security measures to users. Users must understand and accept the need for security.

Any user can compromise system security, at least to some degree. Passwords, for instance, can often be found simply by calling legitimate users on the telephone, claiming to be a system administrator, and asking for them. If your users understand security issues, and if they understand the reasons for your security measures, they are far less likely to make an intruder's life easier.

At a minimum, users should be taught never to release passwords or other secrets over unsecured telephone lines (especially cellular telephones) or electronic mail (email). Users should be wary of questions asked by people who call them on the telephone. Some companies have implemented formalized network security training for their employees; that is, employees are not allowed access to the Internet until they have completed a formal training program.
* Know your weaknesses
: Every security system has vulnerabilities. You should understand your system's weak points and know how they could be exploited. You should also know the areas that present the largest danger and prevent access to them immediately. Understanding the weak points is the first step toward turning them into secure areas.
* Limit the scope of access
: You should create appropriate barriers inside your system so that if intruders access one part of the system, they do not automatically have access to the rest of the system. The security of a system is only as good as the weakest security level of any single host in the system.
* Understand your environment
: Understanding how your system normally functions, knowing what is expected and what is unexpected, and being familiar with how devices are usually used, help you to detect security problems. Noticing unusual events can help you to catch intruders before they can damage the system. Auditing tools can help you to detect those unusual events.
* Limit your trust
: You should know exactly which software you rely on, and your security system should not have to rely upon the assumption that all software is bug-free.
* Remember physical security
: Physical access to a computer (or a router) usually gives a sufficiently sophisticated user total control over that computer. Physical access to a network link usually allows a person to tap that link, jam it, or inject traffic into it. It makes no sense to install complicated software security measures when access to the hardware is not controlled.
* Security is pervasive
: Almost any change you make in your system may have security effects. This is especially true when new services are created. Administrators, programmers, and users should consider the security implications of every change they make. Understanding the security implications of a change is something that takes practice. It requires lateral thinking and a willingness to explore every way in which a service could potentially be manipulated.
== Controlling Access to Cisco Routers ==
It is important to control access to your Cisco routers. You can control access to the router using the following methods:
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Console Access|Console Access]]
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Telnet Access|Telnet Access]]
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Simple Network Management Protocol (SNMP) Access|Simple Network Management Protocol (SNMP) Access]]
* [[Internetwork Design Guide -- Increasing Security on IP Networks#Controlling Access to Network Servers That Contain Configuration Files|Controlling Access to Network Servers That Contain Configuration Files]]

You can secure the first three of these methods by employing features within the router software. For each method, you can permit nonprivileged access and privileged access for a user (or group of users). Nonprivileged access allows users to monitor the router, but not to configure the router. Privileged access allows the user to fully configure the router.

For console port and Telnet access, you can set up two types of passwords. The first type of password, the login password, allows the user nonprivileged access to the router. After accessing the router, the user can enter privileged mode by entering the '''enable''' command and the proper password. Privileged mode provides the user with full configuration capabilities.

SNMP access allows you to set up different SNMP community strings for both nonprivileged and privileged access. Nonprivileged access allows users on a host to send the router SNMP get-request and SNMP get-next-request messages. These messages are used for gathering statistics from the router. Privileged access allows users on a host to send the router SNMP set-request messages in order to make changes to the router's configurations and operational state.
=== Console Access ===
A console is a terminal attached directly to the router via the console port. Security is applied to the console by asking users to authenticate themselves via passwords. By default, there are no passwords associated with console access.
==== Nonprivileged Mode Password ====
You configure a password for nonprivileged mode by entering the following commands in the router's configuration file. Passwords are case-sensitive. In this example, the password is "1forAll."

line console 0
login
password 1forAll

When you log in to the router, the router login prompt is as follows:

User Access Verification
Password:

You must enter the password "1forAll" to gain nonprivileged access to the router. The router response is as follows:

router>

Nonprivileged mode is signified on the router by the > prompt. At this point, you can enter a variety of commands to view statistics on the router, but you cannot change the configuration of the router. Never use "cisco," or other obvious derivatives, such as "pancho," for a Cisco router password. These will be the first passwords intruders will try if they recognize the Cisco login prompt.
==== Privileged Mode Password ====
Configure a password for privileged mode by entering the following commands in the router's configuration file. In this example, the password is "san-fran."

enable-password san-fran

To access privileged mode, enter the following command:

router> enable
Password:

Enter the password "san-fran" to gain privileged access to the router. The router responds as follows:

router#

Privileged mode is signified by the # prompt. In privileged mode, you can enter all commands to view statistics and configure the router.
==== Session Timeouts ====
Setting the login and enable passwords may not provide enough security in some cases. The timeout for an unattended console (by default 10 minutes) provides an additional security measure. If the console is left unattended in privileged mode, any user can modify the router's configuration. You can change the login timeout via the command '''exec-timeout''' mm ss, where mm is minutes and ss is seconds. The following commands change the timeout to 1 minute and 30 seconds:

line console 0
exec-timeout 1 30

==== Password Encryption ====
All passwords on the router are visible via the '''write terminal''' and '''show configuration''' privileged mode commands. If you have access to privileged mode on the router, you can view all passwords in cleartext by default.

There is a way to hide cleartext passwords. The command '''service password-encryption''' stores passwords in an encrypted manner so that anyone performing a '''write terminal''' and '''show configuration''' will not be able to determine the cleartext password. However, if you forget the password, regaining access to the router requires you to have physical access to the router.

{{note|Although encryption is helpful, it can be compromised and thus should not be your only network-security strategy. }}

=== Telnet Access ===
You can access both nonprivileged and privileged mode on the router via Telnet. As with the console port, Telnet security is provided when users are prompted by the router to authenticate themselves via passwords. In fact, many of the same concepts described in the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Console Access|Console Access]]" section earlier in this article apply to Telnet access. You must enter a password to go from nonprivileged mode to privileged mode, and you can encrypt passwords and specify timeouts for each Telnet session.
==== Nonprivileged Mode Password ====
Each Telnet port on the router is known as a virtual terminal. There are a maximum of five virtual terminal (VTY) ports on the router, allowing five concurrent Telnet sessions. (The communication server provides more VTY ports.) On the router, the virtual terminal ports are numbered from 0 through 4. You can set up nonprivileged passwords for Telnet access via the virtual terminal ports with the following configuration commands. In this example, virtual terminal ports 0 through 4 use the password "marin":

line vty 0 4
login
password marin

When a user telnets to a router IP address, the router provides a prompt similar to the following:

% telnet router
Trying ...
Connected to router.
Escape character is '^]'.
User Access Verification
Password:

If the user enters the correct nonprivileged password, the following prompt appears:

router>

==== Privileged Mode Password ====
The user now has nonprivileged access to the router and can enter privileged mode by entering the '''enable''' command as described in the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Privileged Mode Password|Privileged Mode Password]]" section earlier in this article.
==== Restricting Telnet Access to Particular IP Addresses ====
If you want to allow only certain IP addresses to use Telnet to access the router, you must use the '''access-class''' command. The command '''access-class''' ''nn'' '''in''' defines an access list (from 1 through 99) that allows access to the virtual terminal lines on the router. The following configuration commands allow incoming Telnet access to the router only from hosts on network 192.85.55.0:

access-list 12 permit 192.85.55.0 0.0.0.255
line vty 0 4
access-class 12 in

==== Restricting Telnet Access to Cisco Products via TCP Ports ====
It is possible to access Cisco products via Telnet to specified TCP ports. The type of Telnet access varies, depending upon the following Cisco software releases:
* Software Release 9.1 (11.4) and earlier and 9.21 (3.1) and earlier
* Software Release 9.1 (11.5), 9.21 (3.2), and 10.0 and later
===== Earlier Software Releases =====
For Software Release 9.1 (11.4) and earlier and Software Release 9.21 (3.1) and earlier, it is possible, by default, to establish TCP connections to Cisco products via the TCP ports listed in [[Internetwork Design Guide -- Increasing Security on IP Networks#Table: TCP Port Telnet Access to Cisco Products (Earlier Releases)|Table: TCP Port Telnet Access to Cisco Products (Earlier Releases)]].

===== Table: TCP Port Telnet Access to Cisco Products (Earlier Releases)=====

{| border = 1
|-
!TCP Port Number
!Access Method
|-
|

7
|

Echo
|-
|

9
|

Discard
|-
|

23
|

Telnet (to virtual terminal VTY ports in rotary fashion)
|-
|

79
|

Finger
|-
|

1993
|

SNMP over TCP
|-
|

2001 through 2999
|

Telnet to auxiliary (AUX) port, terminal (TTY) ports, and virtual terminal (VTY) ports
|-
|

3001 through 3999
|

Telnet to rotary ports (access via these ports is only possible if the rotaries have been explicitly configured first with the '''rotary''' command)
|-
|

4001 through 4999
|

Telnet (stream mode) mirror of 2000 range
|-
|

5001 through 5999
|

Telnet (stream mode) mirror of 3000 range (access via these ports is possible only if the rotaries have been explicitly configured first)
|-
|

6001 through 6999
|

Telnet (binary mode) mirror of 2000 range
|-
|

7001 through 7999
|

Telnet (binary mode) mirror of 3000 range (access via these ports is possible only if the rotaries have been explicitly configured first)
|-
|

8001 through 8999
|

Xremote (communication servers only)
|-
|

9001 through 9999
|

Reverse Xremote (communication servers only)
|-
|

10001 through 19999
|

Reverse Xremote rotary (communication servers only; access via these ports is possible only if the ports have been explicitly configured first)
|}

{{caution|Because Cisco routers have no TTY lines, configuring access (on communication servers) to terminal ports 2002, 2003, 2004, and greater could potentially provide access (on routers) to virtual terminal lines 2002, 2003, 2004, and greater. To provide access only to TTY ports, you can create access lists to prevent access to VTYs.}}

When configuring rotary groups, keep in mind that access through any available port in the rotary group is possible (unless access lists are defined). Cisco recommends that if you are using firewalls that allow in-bound TCP connection to high-number ports, remember to apply appropriate in-bound access lists to Cisco products.

The following is an example illustrating an access list denying all in-bound Telnet access to the auxiliary port and allowing Telnet access to the router only from IP address 192.32.6.7:

<pre>access-class 51 deny 0.0.0.0 255.255.255.255
access-class 52 permit 192.32.6.7
line aux 0
access-class 51 in
line vty 0 4
access-class 52 in </pre>

To disable connections to the echo and discard ports, you must disable these services completely with the '''no service tcp-small-servers''' command.

{{caution|If the '''ip alias''' command is enabled on Cisco products, TCP connections to any destination port are considered valid connections. You may want to disable the '''ip alias''' command.}}

You might want to create access lists to prevent access to Cisco products via these TCP ports. For information on how to create access lists for routers, see the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Configuring the Firewall Router|Configuring the Firewall Router]]" section later in this article. For information on how to create access lists for communication servers, see the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Configuring the Firewall Communication Server|Configuring the Firewall Communication Server]]" section later in this article.
===== Software Releases 9.1 (11.5), 9.21 (3.2), and 10.0 and Later =====
With Software Release 9.1 (11.5), 9.21 (3.2), and any version of Software Release 10, the following enhancements have been implemented:
* Direct access to virtual terminal lines (VTYs) through the 2000, 4000, and 6000 port ranges has been disabled. If you want to keep access open, you can set up one-to-one mapping of VTY-to-rotary ports.
* Connections to echo and discard ports (7 and 9) can be disabled with the '''no service tcp-small-servers''' command.
* All Cisco products allow connections to IP alias devices only on destination port 23.

For later releases, a Cisco router accepts TCP connections on the ports listed in [[Internetwork Design Guide -- Increasing Security on IP Networks#Table: TCP Port Telnet Access to Cisco Products (Later Releases)|Table: TCP Port Telnet Access to Cisco Products (Later Releases)]] by default.

===== Table: TCP Port Telnet Access to Cisco Products (Later Releases)=====

{| border = 1
|-
!TCP Port Number
!Access Method
|-
|

7
|

Echo
|-
|

9
|

Discard
|-
|

23
|

Telnet
|-
|

79
|

Finger
|-
|

1993
|

SNMP over TCP
|-
|

2001
|

Auxiliary (AUX) port
|-
|

4001
|

Auxiliary (AUX) port (stream)
|-
|

6001
|

Auxiliary (AUX) port (binary)
|}

Access via port 23 can be restricted by creating an access list and assigning it to virtual terminal lines. Access via port 79 can be disabled with the '''no service finger''' command. Access via port 1993 can be controlled with SNMP access lists. Access via ports 2001, 4001, and 6001 can be controlled with an access list placed on the auxiliary port.
==== Terminal Access Controller Access Control System (TACACS) ====
Nonprivileged and privileged mode passwords are global and apply to every user accessing the router from either the console port or from a Telnet session. As an alternative, the Terminal Access Controller Access Control System (TACACS) provides a way to validate every user on an individual basis before they can gain access to the router or communication server. TACACS was derived from the United States Department of Defense and is described in Request For Comments (RFC) 1492. TACACS is used by Cisco to allow finer control over who can access the router in nonprivileged and privileged mode.

With TACACS enabled, the router prompts the user for a username and a password. Then, the router queries a TACACS server to determine whether the user provided the correct password. A TACACS server typically runs on a UNIX workstation. Public domain TACACS servers can be obtained via anonymous ftp to ftp.cisco.com in the /pub directory. Use the /pub/README file to find the filename. A fully supported TACACS server is bundled with CiscoWorks Version 3.

The configuration command '''tacacs-server host''' specifies the UNIX host running a TACACS server that will validate requests sent by the router. You can enter the '''tacacs-server host''' command several times to specify multiple TACACS server hosts for a router.
===== Nonprivileged Access =====
If all servers are unavailable, you may be locked out of the router. In that event, the configuration command '''tacacs-server last-resort''' ['''password''' | '''succeed'''] allows you to determine whether to allow a user to log in to the router with no password ('''succeed''' keyword) or to force the user to supply the standard login password ('''password''' keyword).

The following commands specify a TACACS server and allow a login to succeed if the server is down or unreachable:

tacacs-server host 129.140.1.1
tacacs-server last-resort succeed

To force users who access the router via Telnet to authenticate themselves using TACACS, enter the following configuration commands:

line vty 0 4
login tacacs

===== Privileged Access =====
This method of password checking can also be applied to the privileged mode password with the '''enable use-tacacs''' command. If all servers are unavailable, you may be locked out of the router. In that event, the configuration command '''enable last-resort''' ['''succeed''' | '''password'''] allows you to determine whether to allow a user to log in to the router with no password ('''succeed''' keyword) or to force the user to supply the enable password ('''password''' keyword). There are significant risks to using the '''succeed''' keyword. If you use the '''enable use-tacacs''' command, you must also specify the '''tacacs-server authenticate enable''' command.

The '''tacacs-server extended''' command enables a Cisco device to run in extended TACACS mode. The UNIX system must be running the extended TACACS daemon, which can be obtained via anonymous ftp to ftp.cisco.com. The filename is xtacacsd.shar. This daemon allows communication servers and other equipment to talk to the UNIX system and update an audit trail with information on port usage, accounting data, or any other information the device can send.

The command '''username''' <'''user'''> '''password''' ['''0''' | '''7'''] <'''password'''> allows you to store and maintain a list of users and their passwords on a Cisco device instead of on a TACACS server. The number 0 stores the password in cleartext in the configuration file. The number 7 stores the password in an encrypted format. If you do not have a TACACS server and still want to authenticate users on an individual basis, you can set up users with the following configuration commands:

username steve password 7 steve-pass
username allan password 7 allan-pass

The two users, Steve and Allan, will be authenticated via passwords that are stored in encrypted format.
===== Token Card Access =====
Using TACACS service on routers and communications servers, support for physical card key devices, or token cards, can also be added. The TACACS server code can be modified to provide support for this without requiring changes in the setup and configuration of the routers and communication servers. This modified code is not directly available from Cisco.

The token card system relies on a physical card that must be in your possession in order to provide authentication. By using the appropriate hooks in the TACACS server code, third-party companies can offer these enhanced TACACS servers to customers. One such product is the Enigma Logic SafeWord security software system. Other card-key systems, such as Security Dynamics SmartCard, can be added to TACACS as well.
=== Simple Network Management Protocol (SNMP) Access ===
SNMP is another method you can use to access your routers. With SNMP, you can gather statistics or configure the router. Gather statistics with get-request and get-next-request messages, and configure routers with set-request messages. Each of these SNMP messages has a community string that is a cleartext password sent in every packet between a management station and the router (which contains an SNMP agent). The SNMP community string is used to authenticate messages sent between the manager and agent. Only when the manager sends a message with the correct community string will the agent respond.

The SNMP agent on the router allows you to configure different community strings for nonprivileged and privileged access. You configure community strings on the router via the configuration command '''snmp-server community''' <string> ['''RO''' | '''RW'''] [access-list]. The following sections explore the various ways to use this command.

Unfortunately, SNMP community strings are sent on the network in cleartext ASCII. Thus, anyone who has the ability to capture a packet on the network can discover the community string. This may allow unauthorized users to query or modify routers via SNMP. For this reason, using the '''no snmp-server trap-authentication''' command may prevent intruders from using trap messages (sent between SNMP managers and agents) to discover community strings.

The Internet community, recognizing this problem, greatly enhanced the security of SNMP version 2 (SNMPv2) as described in RFC 1446. SNMPv2 uses an algorithm called MD5 to authenticate communications between an SNMP server and agent. MD5 verifies the integrity of the communications, authenticates the origin, and checks for timeliness. Further, SNMPv2 can use the data encryption standard (DES) for encrypting information.
==== Nonprivileged Mode ====
Use the '''RO''' keyword of the''' snmp-server community''' command to provide nonprivileged access to your routers via SNMP. The following configuration command sets the agent in the router to allow only SNMP get-request and get-next-request messages that are sent with the community string "public":

snmp-server community public RO 1

You can also specify a list of IP addresses that are allowed to send messages to the router using the access-list option with the '''snmp-server community''' command. In the following configuration example, only hosts 1.1.1.1 and 2.2.2.2 are allowed nonprivileged mode SNMP access to the router:

access-list 1 permit 1.1.1.1
access-list 1 permit 2.2.2.2
snmp-server community public RO 1

==== Privileged Mode ====
Use the '''RW''' keyword of the '''snmp-server community''' command to provide privileged access to your routers via SNMP. The following configuration command sets the agent in the router to allow only SNMP set-request messages sent with the community string ''private'':

snmp-server community private RW 1

You can also specify a list of IP addresses that are allowed to send messages to the router by using the access-list option of the '''snmp-server community''' command. In the following configuration example, only hosts 5.5.5.5 and 6.6.6.6 are allowed privileged mode SNMP access to the router:

access-list 1 permit 5.5.5.5
access-list 1 permit 6.6.6.6
snmp-server community private RW 1

=== Controlling Access to Network Servers That Contain Configuration Files ===
If a router regularly downloads configuration files from a Trivial File Transfer Protocol (TFTP) or Maintenance Operations Protocol (MOP) server, anyone who can access the server can modify the router configuration files stored on the server.

Communication servers can be configured to accept incoming local area transport (LAT) connections. Protocol translators and their translating router brethren can accept X.29 connections. These different types of access should be considered when creating a firewall architecture.
== Setting Up Your Firewall Architecture ==
A firewall architecture is a structure that exists between you and the outside world to protect you from intruders. In most circumstances, intruders are represented by the global Internet and the thousands of remote networks it interconnects. Typically, a network firewall consists of several different machines as shown in [[Internetwork Design Guide -- Increasing Security on IP Networks#Figure: Typical firewall architecture|Figure: Typical firewall architecture]].

===== Figure: Typical firewall architecture=====

[[image:nd201601.jpg]]

In this architecture, the router that is connected to the Internet (exterior router) forces all incoming traffic to go to the application gateway. The router that is connected to the internal network (interior router) accepts packets only from the application gateway.

The application gateway institutes per-application and per-user policies. In effect, the gateway controls the delivery of network-based services both into and from the internal network. For example, only certain users might be allowed to communicate with the Internet, or only certain applications are permitted to establish connections between an interior and exterior host.

The route and packet filters should be set up to reflect the same policies. If the only application that is permitted is mail, only mail packets should be allowed through the router. This protects the application gateway and avoids overwhelming it with packets that it would otherwise discard.
== Controlling Traffic Flow ==
This section uses the scenario illustrated in [[Internetwork Design Guide -- Increasing Security on IP Networks#Figure: Controlling traffic flow via the firewall router|Figure: Controlling traffic flow via the firewall router]] to describe the use of access lists to restrict traffic to and from a firewall router and a firewall communication server.

===== Figure: Controlling traffic flow via the firewall router=====

[[image:nd201602.jpg]]

In this case study, the firewall router allows incoming new connections to one or more communication servers or hosts. Having a designated router act as a firewall is desirable because it clearly identifies the router's purpose as the external gateway and avoids encumbering other routers with this task. In the event that the internal network needs to isolate itself, the firewall router provides the point of isolation so that the rest of the internal network structure is not affected.

Connections to the hosts are restricted to incoming file transfer protocol (FTP) requests and email services as described in the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Configuring the Firewall Router|Configuring the Firewall Router]]" section later in this article. The incoming Telnet, or modem, connections to the communication server are screened by the communication server running TACACS username authentication, as described in the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Configuring the Firewall Communication Server|Configuring the Firewall Communication Server]]" section later in this article.

{{note|Connections from one communication server modem line to another outgoing modem line (or to the outside world) should be disallowed to prevent unauthorized users from using your resources to launch an attack on the outside world. Because intruders have already passed the communication server TACACS authentication at this point, they are likely to have someone's password. It is an excellent idea to keep TACACS passwords and host passwords distinct from one another.}}

=== Configuring the Firewall Router ===
In the firewall router configuration that follows, subnet 13 of the Class B network is the firewall subnet, whereas subnet 14 provides the connection to the worldwide Internet via a service provider:

<pre>interface ethernet 0
ip address B.B.13.1 255.255.255.0
interface serial 0
ip address B.B.14.1 255.255.255.0
router igrp
network B.B.0.0 </pre>

This simple configuration provides no security and allows all traffic from the outside world onto all parts of the network. To provide security on the firewall router, use access lists and access groups as described in the next section.
==== Defining Access Lists ====
Access lists define the actual traffic that will be permitted or denied, whereas an access group applies an access list definition to an interface. Access lists can be used to deny connections that are known to be a security risk and then permit all other connections, or to permit those connections that are considered acceptable and deny all the rest. For firewall implementation, the latter is the more secure method.

In this case study, incoming email and news are permitted for a few hosts, but FTP, Telnet, and rlogin services are permitted only to hosts on the firewall subnet. IP extended access lists (range 100 to 199) and transmission control protocol (TCP) or user datagram protocol (UDP) port numbers are used to filter traffic. When a connection is to be established for email, Telnet, FTP, and so forth, the connection will attempt to open a service on a specified port number. You can, therefore, filter out selected types of connections by denying packets that are attempting to use that service. For a list of well-known services and ports, see the "[[Internetwork Design Guide -- Increasing Security on IP Networks#Filtering TCP and UDP Services|Filtering TCP and UDP Services]]" section later in this article.

An access list is invoked after a routing decision has been made but before the packet is sent out on an interface. The best place to define an access list is on a preferred host using your favorite text editor. You can create a file that contains the '''access-list''' commands, place the file (marked readable) in the default TFTP directory, and then network load the file onto the router.

The network server storing the file must be running a TFTP daemon and have TCP network access to the firewall router. Before network loading the access control definition, any previous definition of this access list is removed by using the following command:

no access-list 101

The '''access-list''' command can now be used to permit any packets returning to machines from already established connections. With the '''established''' keyword, a match occurs if the TCP datagram has the acknowledgment (ACK) or reset (RST) bits set.

access-list 101 permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 established

If any firewall routers share a common network with an outside provider, you may want to allow access from those hosts to your network. In this case study, the outside provider has a serial port that uses the firewall router Class B address (B.B.14.2) as a source address as follows:

access-list 101 permit ip B.B.14.2 0.0.0.0 0.0.0.0 255.255.255.255

The following example illustrates how to deny traffic from a user attempting to spoof any of your internal addresses from the outside world (without using 9.21 input access lists):

access-list 101 deny ip B.B.0.0 0.0.255.255 0.0.0.0 255.255.255.255

The following commands allow domain name system (DNS) and network time protocol (NTP) requests and replies:

access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 53
access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 123

The following command denies the network file server (NFS) user datagram protocol (UDP) port:

access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2049

The following commands deny OpenWindows on ports 2001 and 2002 and deny X11 on ports 6001 and 6002. This protects the first two screens on any host. If you have any machine that uses more than the first two screens, be sure to block the appropriate ports.

access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 6001
access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 6002
access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2001
access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2002

The following command permits Telnet access to the communication server (B.B.13.2):

access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.2 0.0.0.0 eq 23

The following commands permit FTP access to the host on subnet 13:

access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 21
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 20

For the following examples, network B.B.1.0 is on the internal network. [[Internetwork Design Guide -- Increasing Security on IP Networks#Figure: Controlling traffic flow via the firewall router.|Figure: Controlling traffic flow via the firewall router.]]The following commands permit TCP and UDP connections for port numbers greater than 1023 to a very limited set of hosts. Make sure no communication servers or protocol translators are in this list.

<pre>access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023 </pre>

{{note|Standard FTP uses ports above 1023 for its data connections; therefore, for standard FTP operation, ports above 1023 must all be open. For more details, see the "[[Internetwork Design Guide -- Increasing Security on IP Networks#File Transfer Protocol (FTP) Port|File Transfer Protocol (FTP) Port]]" section that follows.}}

The following commands permit DNS access to the DNS server(s) listed by the Network Information Center (NIC):

access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 53
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 eq 53

The following commands permit incoming simple mail transfer protocol (SMTP) email to only a few machines:

access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 25
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 eq 25

The following commands allow internal network news transfer protocol (NNTP) servers to receive NNTP connections from a list of authorized peers:

access-list 101 permit tcp 16.1.0.18 0.0.0.1 B.B.1.100 0.0.0.0 eq 119
access-list 101 permit tcp 128.102.18.32 0.0.0.0 B.B.1.100 0.0.0.0 eq 119

The following command permits Internet control message protocol (ICMP) for error message feedback:

access-list 101 permit icmp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Every access list has an implicit "deny everything else" statement at the end of the list to ensure that attributes that are not expressly permitted are in fact denied.
===== File Transfer Protocol (FTP) Port =====
Many sites today choose to block incoming TCP sessions originated from the outside world while allowing outgoing connections. The trouble with this is that blocking incoming connections kills traditional FTP client programs because these programs use the '''PORT''' command to tell the server where to connect to send the file. The client opens a "control" connection to the server, but the server then opens a "data" connection to an effectively arbitrarily chosen (> 1023) port number on the client.

Fortunately, there is an alternative to this behavior that allows the client to open the "data" socket and allows you to have the firewall and FTP too. The client sends a PASV command to the server, receives back a port number for the data socket, opens the data socket to the indicated port, and finally sends the transfer.

In order to implement this method, the standard FTP client program must be replaced with a modified one that supports the PASV command. Most recent implementations of the FTP server already support the PASV command. The only trouble with this idea is that it breaks down when the server site has also blocked arbitrary incoming connections.

Source files for a modified FTP program that works through a firewall are now available via anonymous FTP at ftp.cisco.com. The file is /pub/passive-ftp.tar.Z. This is a version of BSD 4.3 FTP with the PASV patches. It works through a firewall router that allows only incoming established connections.

{{caution|Care should be taken in providing anonymous FTP service on the host system. Anonymous FTP service allows anyone to access the hosts, without requiring an account on the host system. Many implementations of the FTP server have severe bugs in this area. Also, take care in the implementation and setup of the anonymous FTP service to prevent any obvious access violations. For most sites, anonymous FTP service is disabled.}}

==== Applying Access Lists to Interfaces ====
After this access list has been loaded onto the router and stored into nonvolatile random-access memory (NVRAM), assign it to the appropriate interface. In this case study, traffic coming from the outside world via serial 0 is filtered before it is placed on subnet 13 (ethernet 0). Therefore, the '''access-group''' command, which assigns an access list to filter incoming connections, must be assigned to Ethernet 0 as follows:

interface ethernet 0
ip access-group 101

To control outgoing access to the Internet from the network, define an access list and apply it to the outgoing packets on serial 0 of the firewall router. To do this, returning packets from hosts using Telnet or FTP must be allowed to access the firewall subnetwork B.B.13.0.
===== Filtering TCP and UDP Services =====
Some well-known TCP and UDP port numbers include the services listed in [[Internetwork Design Guide -- Increasing Security on IP Networks#Table: Well-Known TCP and UDP Services and Ports|Table: Well-Known TCP and UDP Services and Ports]].

===== Table: Well-Known TCP and UDP Services and Ports=====

{| border = 1
|-
!Service
!Port Type
!Port Number
|-
|

File Transfer Protocol (FTP)-Data
|

TCP
|

20
|-
|

FTP-Commands
|

TCP
|

21
|-
|

Telnet
|

TCP
|

23
|-
|

Simple Mail Transfer Protocol (SMTP)-Email
|

TCP
|

25
|-
|

Terminal Access Controller Access Control System (TACACS)
|

UDP
|

49
|-
|

Domain Name Server (DNS)
|

TCP and UDP
|

53
|-
|

Trivial File Transfer Protocol (TFTP)
|

UDP
|

69
|-
|

finger
|

TCP
|

79
|-
|

SUN Remote Procedure Call (RPC)
|

UDP
|

111
|-
|

Network News Transfer Protocol (NNTP)
|

TCP
|

119
|-
|

Network Time Protocol (NTP)
|

TCP and UDP
|

123
|-
|

NeWS
|

TCP
|

144
|-
|

Simple Management Network Protocol (SNMP)
|

UDP
|

161
|-
|

SNMP (traps)
|

UDP
|

162
|-
|

Border Gateway Protocol (BGP)
|

TCP
|

179
|-
|

rlogin
|

TCP
|

513
|-
|

rexec
|

TCP
|

514
|-
|

talk
|

TCP and UDP
|

517
|-
|

ntalk
|

TCP and UDP
|

518
|-
|

Open Windows
|

TCP and UDP
|

2000
|-
|

Network File System (NFS)
|

UDP
|

2049
|-
|

X11
|

TCP and UDP
|

6000
|}

===== CERT Advisory =====
The Computer Emergency Response Team (CERT) recommends filtering the services listed in [[Internetwork Design Guide -- Increasing Security on IP Networks#Table: CERT Advisory on TCP and UDP Services and Ports|Table: CERT Advisory on TCP and UDP Services and Ports]].

===== Table: CERT Advisory on TCP and UDP Services and Ports=====

{| border = 1
|-
|

''' Service'''
|

''' Port Type'''
|

''' Port Number'''
|-
|

DNS zone transfers
|

TCP
|

53
|-
|

TFTP daemon (tftpd)
|

UDP
|

69
|-
|

link-commonly used by intruders
|

TCP
|

87
|-
|

SUN RPC
|

TCP and UDP
|

111
|-
|

NFS
|

UDP
|

2049
|-
|

BSD UNIX '''r''' commands ('''rsh''', '''rlogin''', and so forth)
|

TCP
|

512 through 514
|-
|

line printer daemon (lpd)
|

TCP
|

515
|-
|

UNIX-to-UNIX copy program daemon (uucpd)
|

TCP
|

540
|-
|

Open Windows
|

TCP and UDP
|

2000
|-
|

X Windows
|

TCP and UDP
|

6000+
|}

{{note|Cisco recommends that you filter the finger TCP service at port 79 to prevent outsiders from learning about internal user directories and the names of hosts from which users log in. }}

===== Input Access Lists =====
In Software Release 9.21, Cisco introduces the ability to assign input access lists to an interface. This allows a network administrator to filter packets before they enter the router, instead of as they leave the router. In most cases, input access lists and output access lists accomplish the same functionality; however, input access lists are more intuitive to some people and can be used to prevent some types of IP address "spoofing" where output access lists will not provide sufficient security.

[[Internetwork Design Guide -- Increasing Security on IP Networks#Figure: A host that is spoofing|Figure: A host that is spoofing]] illustrates a host that is "spoofing," or illegally claiming to be an address that it is not. Someone in the outside world is claiming to originate traffic from network 131.108.17.0. Although the address is spoofed, the router interface to the outside world assumes that the packet is coming from 131.108.17.0. If the input access list on the router allows traffic coming from 131.108.17.0, it will accept the illegal packet. To avoid this spoofing situation, an input access list should be applied to the router interface to the outside world. This access list would not allow any packets with addresses that are from the internal networks of which the router is aware (17.0 and 18.0).

===== Figure: A host that is spoofing=====

[[image:nd201603.jpg]]

If you have several internal networks connected to the firewall router and the router is using output filters, traffic between internal networks will see a reduction in performance created by the access list filters. If input filters are used only on the interface going from the router to the outside world, internal networks will not see any reduction in performance.

{{note|If an address uses source routing, it can send and receive traffic through the firewall router. For this reason, you should always disable source routing on the firewall router with the '''no ip source-route '''command.}}

=== Configuring the Firewall Communication Server ===
In this case study, the firewall communication server has a single inbound modem on line 2:

<pre>interface Ethernet0
ip address B.B.13.2 255.255.255.0
!
access-list 10 deny B.B.14.0 0.0.0.255
access-list 10 permit B.B.0.0 0.0.255.255
!
access-list 11 deny B.B.13.2 0.0.0.0
access-list 11 permit B.B.0.0 0.0.255.255
!
line 2
login tacacs
location FireWallCS#2
!
access-class 10 in
access-class 11 out
!
modem answer-timeout 60
modem InOut
telnet transparent
terminal-type dialup
flowcontrol hardware
stopbits 1
rxspeed 38400
txspeed 38400
!
tacacs-server host B.B.1.100
tacacs-server host B.B.1.101
tacacs-server extended
!
line vty 0 15
login tacacs </pre>

==== Defining Access Lists ====
In this example, the network number is used to permit or deny access; therefore, standard IP access list numbers (range 1 through 99) are used. For incoming connections to modem lines, only packets from hosts on the internal Class B network and packets from those hosts on the firewall subnetwork are permitted:

access-list 10 deny B.B.14.0 0.0.0.255
access-list 10 permit B.B.0.0 0.0.255.255

Outgoing connections are allowed only to internal network hosts and to the communication server. This prevents a modem line in the outside world from calling out on a second modem line:

access-list 11 deny B.B.13.2 0.0.0.0
access-list 11 permit B.B.0.0 0.0.255.255

==== Applying Access Lists to Lines ====
Apply an access list to an asynchronous line with the '''access-class '''command. In this case study, the restrictions from access list 10 are applied to incoming connections on line 2. The restrictions from access list 11 are applied to outgoing connections on line 2.

access-class 10 in
access-class 11 out

=== Using Banners to Set Up Unauthorized Use Notifications ===
It is also wise to use the '''banner exec''' global configuration command to provide messages and unauthorized use notifications, which will be displayed on all new connections. For example, on the communication server, you can enter the following message:

<pre>banner exec ^C

If you have problems with the dial-in lines, please send mail to helpdesk@Corporation X.com. If you get the message "% Your account is expiring", please send mail with name and voicemail box to helpdesk@CorporationX.com, and someone will contact you to renew your account. Unauthorized use of these resources is prohibited. </pre>
== Securing Nonstandard Services ==
There are a number of nonstandard services available from the Internet that provide value-added services when connecting to the outside world. In the case of a connection to the Internet, these services can be very elaborate and complex. Examples of these services are World Wide Web (WWW), Wide Area Information Service (WAIS), gopher, and Mosaic. Most of these systems are concerned with providing a wealth of information to the user in some organized fashion and allowing structured browsing and searching.

Most of these systems have their own defined protocol. Some, such as Mosaic, use several different protocols to obtain the information in question. Use caution when designing access lists applicable to each of these services. In many cases, the access lists will become interrelated as these services become interrelated.
== Summary ==
Although this case study illustrates how to use Cisco network layer features to increase network security on IP networks, in order to have comprehensive security, you must address all systems and layers.
== Recommended Reading ==
This section contains a list of publications that provide internetwork security information.<a name="wp4065"> </a>
Books and Periodicals

Cheswick, B. and Bellovin, S. ''Firewalls and Internet Security.'' Addison-Wesley.

Comer, D.E and Stevens, D.L., ''Internetworking with TCP/IP.'' Volumes I-III. Englewood Cliffs, New Jersey: Prentice Hall; 1991-1993.

Curry, D. ''UNIX System Security-A Guide for Users and System Administrators.''

Garfinkel and Spafford. ''Practical UNIX Security.'' O'Reilly & Associates.

Quarterman, J. and Carl-Mitchell, S.'' The Internet Connection'', Reading, Massachusetts: Addison-Wesley Publishing Company; 1994.

Ranum, M. J. ''Thinking about Firewalls'', Trusted Information Systems, Inc.

Stoll, C. ''The Cuckoo's Egg''. Doubleday.

Treese, G. W. and Wolman, A. ''X through the Firewall and Other Application Relays.''
=== Requests For Comments (RFCs) ===
RFC 1118. "The Hitchhiker's Guide to the Internet." September 1989.

RFC 1175. "A Bibliography of Internetworking Information." August 1990.

RFC1244. "Site Security Handbook." July 1991.

RFC 1340. "Assigned Numbers." July 1992.

RFC 1446. "Security Protocols for SNMPv2." April 1993.

RFC 1463. "FYI on Introducing the Internet-A Short Bibliography of Introductory Internetworking Readings for the Network Novice." May 1993.

RFC 1492. "An Access Control Protocol, Sometimes Called TACACS." July 1993.
=== Internet Directories ===
Documents at ''gopher.nist.gov''.
The "Computer Underground Digest" in the'' /pub/cud directory at ftp.eff.org.''
Documents in the'' /dist/internet_security ''directory at ''research.att.com.''

[[Category: Internetwork Design]]
[[Category:Internetworking Case Studies]]