Полезная информация

cc/td/doc/product/software/ios120/12cgcr
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring XNS

Configuring XNS

This chapter describes how to configure standard Xerox Network System (XNS) routing and Ungermann-Bass Net/One XNS routing. It also provides configuration examples. For a complete description of the XNS commands in this chapter, refer to the "XNS Commands" chapter in the Network Protocols Command Reference, Part 3. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.


Note Not all Cisco access servers support XNS. For more information, refer to the release notes for the current Cisco IOS release.

Ungermann-Bass Net/One Environments

Some of the tasks described in this chapter explain how to configure Ungermann-Bass Net/One XNS routing. Net/One uses XNS at the network layer. However, Net/One as a whole is not equivalent to standard XNS. When using Cisco routers in Net/One environments, keep in mind the following differences between Net/One and standard XNS environments:

Net/One uses a distance-vector routing protocol, similar to standard XNS RIP. The major difference between the two protocols is the metrics. Standard RIP uses hop count to determine the best route to a remote network, while the Net/One protocol uses a path-delay metric. The standard RIP protocol maintains information only about hop counts, while the Net/One protocol maintains information about both hop count and its own metrics.

Ungermann-Bass routers generate standard RIP updates by extracting the hop-count values from the Ungermann-Bass routing protocol. When configured in Ungermann-Bass emulation mode, Cisco routers participate in this protocol and behave (insofar as routing protocols are concerned) like Ungermann-Bass routers.

Cisco routers also can be configured to listen to standard RIP updates when in Ungermann-Bass Net/One emulation mode. When a Cisco router in Ungermann-Bass emulation mode receives a RIP packet, each route in that packet is treated as though it had come from an Ungermann-Bass routing packet. The hop count used is the actual hop count from the RIP packet. The delay metric used is computed by assuming that each hop is the longest-delay link used by Ungermann-Bass, which is a 9.6-kbps serial link. Information from RIP packets is used in creating outgoing Ungermann-Bass updates, and vice versa.


Note Older versions of Cisco IOS software implemented a restricted version of the Ungermann-Bass routing protocol. Using that software in certain configurations could create routing instability and forwarding loops. If you are planning to use Releases 8.3 and earlier in Ungermann-Bass environments, consult the Release 8.3 documentation for information about the restrictions.

XNS Addresses

An XNS address consists of a network number and a host number expressed in the format network.host.

The network number identifies a physical network. It is a 32-bit quantity that must be unique throughout the entire XNS internetwork. The network number is expressed in decimal. A network number of zero identifies the local network. The XNS network number is expressed in decimal format in Cisco's configuration files and routing tables. However, the router internally converts the network number into hexadecimal. This means, for instance, that a network analyzer will display the network number in hexadecimal.

The host number is a 48-bit quantity that is unique across all hosts ever manufactured. It is represented by dotted triplets of four-digit hexadecimal numbers.

The following is an example of an XNS address:

47.0000.0x00.23fe

When XNS routing is enabled, the address used is either the IEEE-compliant address specified in the XNS routing configuration command or the first IEEE-compliant address in the system. The address also is used as the node address for non-LAN media, notably serial links.

Configuration Task List

To configure XNS routing, complete the tasks in the following sections. At a minimum, you must enable routing.

See the "XNS Configuration Examples" section at the end of this chapter for configuration examples.

Enable XNS Routing

When enabling XNS routing, you can enable either standard XNS routing or Ungermann-Bass Net/One routing. You use standard routing for XNS networks that do not have any Ungermann-Bass systems. You use Net/One routing for networks that do have Ungermann-Bass systems.

Standard XNS routing uses the standard XNS RIP protocol, while Net/One uses an Ungermann-Bass proprietary routing protocol. Net/One routers generate both Ungermann-Bass update packets and standard RIP update packets; however, they listen only to Ungermann-Bass updates. The standard XNS RIP uses a hop count to determine the best route to a distant network, while the Ungermann-Bass protocol uses a path-delay metric. The Cisco IOS software supports both the reception and the generation of Ungermann-Bass routing packets.

Enable Standard XNS Routing

To enable standard XNS routing, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

xns routing [address]

Enable XNS routing on the router.

2 . 

interface type number

Enter interface configuration mode.

3 . 

xns network number

Enable XNS routing on an interface.

For an example of how to enable XNS routing, see the "XNS Routing Configuration Example" section at the end of this chapter.

If you omit the address from the xns routing global configuration command, the Cisco IOS software uses the address of the first IEEE-compliant (Token Ring, FDDI, or Ethernet) interface MAC address it finds in its interface list. The software uses the address 0123.4567.abcd for non-IEEE-compliant interfaces.

To forward XNS packets across a Token Ring interface, you must specify an XNS encapsulation type to use on the interface. To do this, use one of the following commands in interface configuration mode:
Command Purpose

xns encapsulation snap

Encapsulate XNS packets being forwarded across an IBM Token Ring network.

xns encapsulation ub

Encapsulate XNS packets being forwarded across an Ungermann-Bass Token Ring network.

xns encapsulation 3com

Encapsulate XNS packets being forwarded across an older 3Com Token Ring network.

Enable Concurrent Routing and Bridging

You can route XNS on some interfaces and transparently bridge it on other interfaces simultaneously. To do this, you must enable concurrent routing and bridging. To enable concurrent routing and bridging for the router, use the following command in global configuration mode:
Command Purpose

bridge crb

Enable concurrent routing and bridging for the router.

Enable Ungermann-Bass Net/One Routing

To enable Ungermann-Bass Net/One routing, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

xns ub-emulation

Enable Ungermann-Bass Net/One routing on the router.

2 . 

interface type number

Enter interface configuration mode.

3 . 

xns hear-rip [access-list-number]

Enable the receipt of RIP updates on the interface.

For an example of how to enable Ungermann-Bass Net/One routing, see the "Net/One Routing Configuration Example" section at the end of this chapter.

Control Access to the XNS Network

To control access to XNS networks, you create access lists and then apply them with filters to individual interfaces.

Following are the two types of XNS access lists that you can use to filter routed traffic:

Of the following two different types of filters you can define for XNS interfaces, you can apply one of each type to each interface:

Table 6 summarizes the types of filters and the commands you use to define them. Use the show xns interface command to display the filters defined on an interface.


Table 6:
Filter Type Command Used to Define Filter
Generic filters

Filter based on protocol, address and address mask, port and port mask.

xns access-group access-list-number

Routing table filters

Filter which networks are added to the routing table.

xns input-network-filter access-list-number

Filter which networks are advertised in routing updates.

xns output-network-filter access-list-number

Control the routers from which updates are accepted.

xns router-filter access-list-number

XNS Filters

You perform one or more of the tasks in the following sections to control access to XNS networks:

Keep the following in mind when configuring XNS network access control:

Create Access Lists

To create access lists, use one or more of the following commands in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} source-network[.source-address [source-address-mask]]
[destination-network[.destination-address [destination-address-mask]]]

Create a standard XNS access list.

access-list access-list-number {deny | permit} protocol [source-network[.source-host [source-network-mask.]source-host-mask] source-socket
[destination-network [.destination-host
[destination-network-mask.destination-host-mask] [destination-socket [/pep]]]

Create an extended XNS access list.

Once you have created an access list, you apply it to a filter on the appropriate interfaces as described in the sections that follow. This activates the access list.

For an example of how to create an access list to control services between networks in a 3Com network, see the "3Com Access List Example" section at the end of this chapter.

Create Generic Filters

Generic filters determine which packets to send out an interface, based on the packet's source and destination addresses, XNS protocol type, and source and destination socket numbers.

To create generic filters, perform the following tasks:

    1. Create a standard or extended access list.

    2. Apply a filter to an interface.

To create an access list, use one of the following commands in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} source-network[.source-address [source-address-mask]]
[destination-network[.destination-address [destination-address-mask]]]

Create a standard XNS access list.

access-list access-list-number {deny | permit} protocol [source-network[.source-host
[source-network-mask.]source-host-mask] source-socket
[destination-network [.destination-host
[destination-network-mask.destination-host-mask] [destination-socket[/pep]]]

Create an extended XNS access list.

To apply a generic filter to an interface, use the following command in interface configuration mode:
Command Purpose

xns access-group access-list-number

Apply a generic filter to an interface.

For an example of creating a generic access list, see the "3Com Access List Example" section at the end of this chapter.

Create Filters for Updating the Routing Table

Routing table update filters control the entries that the router or access server accepts for its routing table, and the networks that it advertises in its routing updates.

To create filters to control updating of the routing table, perform the following tasks:

    1. Create a standard or an extended access list.

    2. Apply one or more filters to an interface.

To create an access list, use one of the following commands in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} source-network[.source-address [source-address-mask]]
[destination-network[.destination-address [destination-address-mask]]]

Create a standard XNS access list.

access-list access-list-number {deny | permit} protocol [source-network[.source-host
[source-network-mask.]source-host-mask] source-socket
[destination-network [.destination-host
[destination-network-mask.destination-host-mask] [destination-socket[/pep]]]

Create an extended XNS access list.

Standard access list numbers can be from 400 to 499. Extended access list numbers can be from 500 to 599.

For an example of how to create an extended access list entry, see the "Extended Access List with Network Mask Option Example" section at the end of this chapter.

To assign routing table update filters to an interface, use one of the following commands in interface configuration mode. You can apply one of each of the following filters to each interface.
Command Purpose

xns input-network-filter access-list-number

Control which networks are added to the routing table when XNS routing updates are received.

xns output-network-filter access-list-number

Control which networks are advertised in routing updates sent out by the router.

xns router-filter access-list-number

Control the routers from which routing updates are accepted.

Tune XNS Network Performance

To tune XNS network performance, perform the tasks in one or more of the following sections:

Configure Static Routes

XNS uses RIP to determine the best path when several paths to a destination exist. RIP then dynamically updates the routing table. Static routes usually are not used in XNS environments because nearly all XNS routers support dynamic routing with RIP. However, you might want to add static routes to the routing table to explicitly specify paths to certain destinations. Static routes always override any dynamically learned paths.

Be careful when assigning static routes. When links associated with static routes are lost, traffic might stop being forwarded, even though an alternative path might be available.

To add a static route to the router's routing table, use the following command in global configuration mode:
Command Purpose

xns route network network.host

Add a static route to the routing table.

Set Routing Table Update Timers

You can set the delay between XNS RIP updates. Normally, RIP sends routing table updates every 30 seconds.

You can set RIP timers only in a configuration in which all routers are Cisco routers, because the timers for all routers connected to the same network segment should be the same, and because you cannot set the timer for systems running the Ungermann-Bass routing protocol.

The RIP update value you choose affects internal XNS timers as follows:

To set the RIP update timers, use the following command in interface configuration mode:
Command Purpose

xns update-time interval

Set the RIP update timer.

For an example of setting the RIP update timer, see the "Routing Update Timers Example" section at the end of this chapter.

Set Maximum Paths

You can set the maximum number of equal-cost, parallel paths to a destination. (Note that when paths have differing costs, the Cisco IOS software chooses lower-cost routes in preference to higher-cost routes.) The software distributes output on a packet-by-packet basis in round-robin fashion. That is, the first packet is sent along the first path, the second packet along the second path, and so on. If the final path is reached before all packets are sent, the next packet is sent to the first path, the next to the second path, and so on. This round-robin scheme is used regardless of whether fast switching is enabled.

Limiting the number of equal-cost paths can save memory on routers with limited memory or with very large configurations. Additionally, in networks with a large number of multiple paths and systems with limited ability to cache out-of-sequence packets, performance might suffer when traffic is split between many paths.

To set the maximum number of paths on the router, use the following command in global configuration mode:
Command Purpose

xns maximum-paths number

Set the maximum number of equal-cost paths to a destination.

Control Broadcast Messages

Network end nodes often send broadcast messages to discover services; a request is broadcast to many or all nodes in the internetwork, and one or more of the nodes that can offer that service reply. Both end nodes and routers sometimes send broadcast messages to contain data that must be received by many other nodes. An example is RIP routing updates.

Although broadcast messages can be very useful, they are not without costs. Every node on a physical network must receive and process all broadcasts sent on that network, even if the processing consists of ignoring the broadcasts. If many nodes answer the broadcast, network load might increase dramatically for a short period of time. Also, if the broadcast is propagated to more than one physical network, there is extra load on the networks and the intervening routers.

The following are the types of broadcasts and how each is handled:

All these broadcast types use the host address FFFF.FFFF.FFFF in the packet's destination host field. The destination MAC address used in the underlying LAN frame is the broadcast address. Directed broadcasts intended for remote networks can be sent directly to the MAC address of a router that provides the path to their ultimate destination, and physically broadcast only when they reach it.

Some implementations expect all broadcasts to be treated as local broadcasts. Others expect broadcasts with destination network fields of zero to be treated as all-nets broadcasts. Some do not support directed broadcasts. In addition, some implementations expect packets with destination network fields of all ones, but with destination node fields that correspond to specific hosts, to be flooded throughout the Internet as MAC-layer broadcasts. This way, nodes can be located without knowledge of which physical networks they are connected to. Cisco supports all these models by using helpering and flooding features.

Helpering, which is typically used for service discovery broadcasts, sends the broadcasts to user-specified candidate servers on remote networks. When a packet is helpered, the Cisco IOS software changes its destination address to be the configured helper address, and the packet then is routed toward that address. The host at the helper address is expected to process the packet and (usually) to reply to the packet's sender. A helper address can be a directed broadcast address, in which case the helpered packet is forwarded to a remote network and is rebroadcasted there.

Flooding sends packets throughout the entire XNS Internet. Flooded packets are not modified, except for the hop count field. Flooding is useful when many nodes throughout the Internet need to receive a packet, or when a service that can be anywhere in the Internet must be discovered. You should avoid flooding in large, slow, or heavily loaded networks because the load on the routers, links, and end nodes by heavy flooded traffic is large.

Many broadcast messages are sent when a host first becomes active on the network. A host generates a broadcast packet when it does not know the current address of the host that is supposed to receive its next packet---the local server, for instance. Generally, it is not a good idea to place a router between users and the servers that carry their primary applications; you should minimize Internet traffic. However, if you need that server configuration for some other reason, you must ensure that users can broadcast between networks without cluttering the internetwork with unnecessary traffic.

Whenever the Cisco IOS software receives an XNS broadcast packet, it processes it as follows:

Forward Broadcast Messages to Specified Hosts

To configure helpering, which forwards broadcast messages to the specified host or hosts, use the following command in interface configuration mode:
Command Purpose

xns helper-address network.host

Forward broadcast messages to the specified host.

You can specify multiple xns helper-address configuration mode commands on a given interface.

For an example of forwarding broadcast messages, see the "Helpering Example" section at the end of this  chapter.

Specify XNS Protocol Types for Forwarding Broadcast Messages

When considering which packets will be forwarded via helpering, you can forward packets that have been generated by a specific XNS protocol. To do this, use the following command in global configuration mode:
Command Purpose

xns forward-protocol protocol

Forward packets of a specific XNS protocol to a helper address.

Configure Flooding

Different XNS implementations require different flooding behavior. By default, Cisco routers do no flooding. You can, however, configure interfaces on the router to apply flooding to the packets received on an interface.

Whenever the Cisco IOS software receives an XNS broadcast packet, it processes it for flooding. An all-nets broadcast is one that is forwarded to all networks. XNS networks usually indicate all-nets broadcasts by setting the destination network address to all ones (typically written as -1 or FFFFFFFF). Packets with -1 destination networks and specific destination hosts are sent as MAC-layer broadcasts so that they can be picked up and further flooded by other routers. Flooding is applied to packets received on the interfaces.

The Cisco IOS software chooses the interfaces through which flooded packets are sent using rules designed to avoid packet looping and most packet duplication. The underlying principle of these rules is that packets should be flooded away from their sources, never toward them. Packets that the software is configured to flood are sent out through all interfaces, except in the following cases:

To define an interface's flooding behavior, use one of the following commands in interface configuration mode:
Command Purpose

xns flood broadcast allnets

Flood packets whose destination address is
-1.FFFF.FFFF.FFFF.

xns flood broadcast net-zero

Flood packets whose destination address is 0.FFFF.FFFF.FFFF.

xns flood specific allnets

Flood packets with destinations of -1.specific-host.

It is most closely in accordance with the XNS specification to flood packets with destinations of -1.FFFF.FFFF.FFFF and destinations of -1.specific-host, but not to flood packets with destinations of 0.FFFF.FFFF.FFFF. However, 3Com environments often require flooding of broadcast whose network address is all zeros.

Disable XNS Fast Switching

Fast switching allows higher throughput by switching a packet using a cache created by previous packets. Fast switching is enabled by default on all interfaces.

Packet transfer performance is generally better when fast switching is enabled. However, you may want to disable fast switching in order to save memory space on interface cards and to help avoid congestion when high-bandwidth interfaces are writing large amounts of information to low-bandwidth interfaces.

To disable XNS fast switching on an interface, use the following command in interface configuration mode:
Command Purpose

no xns route-cache

Disable XNS fast switching.

Configure XNS over WANs

You can configure XNS over X.25, Frame Relay, and SMDS networks. To do this, configure the appropriate address mappings as described in the "Configuring X.25 and LAPB," "Configuring Frame Relay," and "Configuring SMDS" chapters in the Wide-Area Networking Configuration Guide.

Route XNS Between Virtual LANs

XNS can be routed over virtual LAN (VLAN) subinterfaces using the Inter-Switched Link (ISL) VLAN encapsulation protocol. Full-feature Cisco IOS software is supported on a per-VLAN basis, allowing standard XNS capabilities to be configured on VLANs. For detailed information about configuring XNS routing between VLANs, refer to the Cisco IOS Switching Services Configuration  Guide.

Monitor the XNS Network

To monitor an XNS network, use one or more of the following commands at the EXEC prompt:
Command Purpose

show xns cache

List the entries in the XNS fast-switching cache.

show xns interface [type number]

Display the status of the XNS interfaces configured in the router and the parameters configured on each interface.

show xns route [network]

List the entries in the XNS routing table.

show xns traffic

Display information about the number and type of XNS packets transmitted and received.

ping xns address

Diagnose basic XNS network connectivity (user-level command).

ping

Diagnose basic XNS network connectivity (privileged command).

XNS Configuration Examples

Use the following configuration examples to help in configuring XNS routing on your router:

XNS Routing Configuration Example

The following example enables XNS routing on a router and then enables XNS on three interfaces. On the Ethernet interfaces, the router uses the preassigned MAC-level addresses as XNS host addresses. On the serial interface, the router uses the MAC address associated with the first IEEE  802 interface found on the router.

xns routing
interface ethernet 0
 xns network 20
interface ethernet 1
 xns network 21
interface serial 1
 xns network 24

Net/One Routing Configuration Example

The following example enables Ungermann-Bass Net/One routing. Serial interface 0 is connected to a non-Net/One portion of the XNS Internet, so the xns hear-rip command is issued to allow the learning of routes from the standard RIP updates used by the remote routers. There are Ungermann-Bass nodes connected to interface Token Ring 0, so the encapsulation on that interface is set to Ungermann-Bass. Broadcast flooding is configured to match the expectations of Net/One.

xns routing
 xns ub-emulation
interface tokenring 0
 xns network 23
 xns flood broadcast allnets
 xns encapsulation ub
 xns flood specific allnets
!
interface ethernet 0
 xns network 20
 xns flood broadcast allnets
 xns flood specific allnets
!
interface ethernet 1
 xns network 21
 xns flood broadcast allnets
 xns flood specific allnets
!
interface serial 0
 xns network 24
 xns hear-rip
 xns flood broadcast allnets
 xns flood specific allnets

3Com Access List Example

The following partial example controls specific services between networks 1002 and 1006 in a 3Com network. Echo and error packets, as well as all Sequenced Packet Protocol (SPP) and Packet Exchange Protocol (PEP) (that is, normal data traffic) can go from network 1002 to network 1006. However, all NetBIOS requests are denied. The final three lines are blanket permissions for RIP, SPP, and PEP packets.

access-list 524 permit 2 1002 0x0000 1006 0x0000
!    permit Echo from 1002 to 1006
access-list 524 permit 3 1002 0x0000 1006 0x0000
!    permit Error from 1002 to 1006
access-list 524 deny 5 -1 0x0000 -1 0x046B
!    deny all NetBIOS
access-list 524 permit 4 1002 0x0000 1006 0x0000
!    permit PEP from 1002 to 1006
access-list 524 permit 5 1002 0x0000 1006 0x0000
!    permit SPP from 1002 to 1006
access-list 524 permit 1
!    permit all RIP
!
!These are needed if you want PEP and SPP to be permitted from
!networks other than 1002
access-list 524 permit 4
!    permit all PEP
access-list 524 permit 5
!    permit all SPP

Extended Access List with Network Mask Option Example

The following example allows protocol type 20 on any socket, from a certain make of machine (Cisco Ethernet), on network 10 to access any hosts on networks 1000 through 1015 on any socket:

access-list 505 permit 20 10.0000.0C00.0000 0000.0000.FFFF 0
1000.0000.0000.0000 15.FFFF.FFFF.FFFF 0

Routing Update Timers Example

The following example creates a routing process that specifies a specific address for use on serial lines and other non-802.x interfaces. It also sets the RIP routing update timers for the three interfaces.

xns routing 0000.0C53.4679
! 
interface ethernet 0
 xns network 20
 xns update-time 20
!
interface serial 0
 xns network 24
 xns update-time 20
!
interface ethernet 1
 xns network 21
 xns update-time 20

Helpering Example

The following commands set up helpering for the configuration shown in Figure 28. The Cisco IOS software forwards packets of protocol type 1 only. Ethernet interface 0 has a helper address set, with the helper on network 12 available through the Ethernet interface 2.

xns routing
xns forward-protocol 1
interface ethernet 0
 xns network 5
 xns helper address 12.FFFF.FFFF.FFFF
interface ethernet 1
 xns network 13
interface ethernet 2
 xns network 12

Figure 28:
Helper Addresses


In this example, the following actions will be taken on broadcast packets:

Broadcast packets destined for network 12 are directed broadcasts and are broadcast on Ethernet interface 2 to network 12. This has nothing to do with helpering or protocol forwarding.


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.