|
|
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 XNS commands, refer to the "XNS Commands" chapter in the Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Command Reference publication. 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. |
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, consider 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. |
An XNS address consists of a network number and a host number expressed in the format network.host.
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.
To configure XNS routing, perform 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.
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, their default is to receive only Ungermann-Bass updates. To receive RIP updates, use the xns hear-rip global configuration command.
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.
To enable standard XNS routing, use the following commands beginning in global configuration mode:
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 specify this encapsulation type, use one of the following commands in interface configuration mode:
You can route XNS on some interfaces and transparently bridge it on other interfaces simultaneously. Toenable this type of routing, 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 |
To enable Ungermann-Bass Net/One routing, use the following commands, beginning in global configuration mode:
| Command | Purpose | |
|---|---|---|
Step1 | xns ub-emulation | |
Step2 | interface type number | |
Step3 | xns hear-rip [access-list-number] |
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.
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.
| 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 |
You perform one or more of the tasks in the following sections to control access to XNS networks:
Consider the following when you configure XNS network access control:
To create access lists, use either 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]]]
| |
access-list access-list-number {deny | permit}
protocol [source-network [.source-host | Create an extended XNS access list. |
Once you have created an access list, you activate the access list by applying it to a filter on the appropriate interfaces as described in the sections that follow.
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.
Generic filters determine which packets to send out an interface, based on the source of the packet and destination addresses, XNS protocol type, and source and destination socket numbers.
To create generic filters, perform the following tasks:
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]]]
| |
access-list access-list-number {deny | permit}
protocol [source-network [.source-host | 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 |
For an example of creating a generic access list, see the "3Com Access List Example" section at the end of this chapter.
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:
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]]]
| |
access-list access-list-number {deny | permit}
protocol [source-network [.source-host |
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.
To tune XNS network performance, perform the tasks in one or more of the following sections:
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 routing table of the router, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
xns route network network.host |
You can set the delay between XNS RIP updates. Normally, RIP sends routing table updates every 30seconds.
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 |
For an example of setting the RIP update timer, see the "Routing Update Timers Example" section at the end of this chapter.
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 among 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. |
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 an 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 destination host field of the packet. 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 0 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 1's, 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 sender of the packet. A helper address can be a directed broadcast address, in which case the helpered packet is forwarded to a remote network and is rebroadcast 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:
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 |
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 thischapter.
When considering which packets will be forwarded via helpering, you can forward packets that have been generated by a specific XNS protocol. To forward packets, 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. |
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. Anall-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 1's (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 the flooding behavior of an interface, use one of the following commands in interface configuration mode:
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 broadcasts whose network address is all 0's.
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 |
You can configure XNS over X.25, Frame Relay, and Switched Multimegabit Data Service (SMDS) networks by configuring the appropriate address mappings as described in the "Configuring X.25 and LAPB," "Configuring Frame Relay," and "Configuring SMDS" chapters in the Cisco IOS Wide-Area Networking Configuration Guide.
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 ConfigurationGuide.
To monitor an XNS network, use one or more of the following commands in EXEC mode:
Use the following configuration examples to help in configuring XNS routing on your router:
The following example shows how to enable 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 IEEE802 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
The following example shows how to enable 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
The following partial example shows how to control specific services between networks 1002 and 1006 in a 3Com network. Echo and error packets, along with 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
The following example show how to allow 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
The following example shows how to create 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
The following example shows how to set up helpering for the configuration shown in Figure 29. 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
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 broadcast has nothing to do with helpering or protocol forwarding.
Posted: Mon Jul 17 13:16:48 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.