|
|
The Xerox Network Systems (XNS) protocols, which were developed by the Xerox Corporation, are designed to be used across a variety of communication media, processors, and office applications. Ungermann-Bass, Inc. (now a part of Tandem Computers) adopted XNS in developing its Net/One XNS routing protocol. Standard XNS routing uses the Routing Information Protocol (RIP) update packets and the hop count metric. Ungermann-Bass Net/One uses hello packets and a path-delay metric.
This chapter describes how to configure standard XNS routing and Ungermann-Bass Net/One XNS routing. It also provides configuration examples. For a complete description of the commands discussed in this chapter, refer to the "XNS Commands" chapter in the Router Products Command Reference publication.
Cisco provides a subset of the XNS protocol stack to support XNS routing. XNS traffic can be routed over Ethernet, FDDI, and Token Ring local-area networks (LANs), as well as over point-to-point serial lines running High-Level Data Link Control (HDLC), Link Access Protocol Balanced (LAPB), X.25, Frame Relay, or Switched Multimegabit Data Service (SMDS).
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 our 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, our routers participate in this protocol and behave insofar as routing protocols are concerned like Ungermann-Bass routers.
Our routers also can be configured to listen to standard RIP updates when in Ungermann-Bass Net/One emulation mode. When our 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.
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 our 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.
To configure XNS routing, complete the tasks in the following sections. At a minimum, you must enable routing.
See 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, 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. Our router supports both the reception and the generation of Ungermann-Bass routing packets.
To enable standard XNS routing, perform the following tasks starting in global configuration mode:
For an example of how to enable XNS routing, see the section "Enabling XNS Routing Configuration Example."
If you omit the address from the xns routing command, the router uses the address of the first IEEE-compliant (Token Ring, FDDI, or Ethernet) interface MAC address it finds in its interface list. The router 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, perform one of the following tasks in interface configuration mode:
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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable concurrent routing and bridging for the router. | bridge crb1 |
To enable Ungermann-Bass Net/One routing, perform Step 1, starting in global configuration mode, and optionally perform Step 2 and Step 3:
| Task | Command |
|---|---|
| Step 1 Enable Ungermann-Bass Net/One routing on the router. | xns ub-emulation |
| Step 2 Enter interface configuration mode. | interface type number |
| Step 3 Enable the receipt of RIP updates on the interface. | xns hear-rip [access-list-number] |
For an example of how to enable Ungermann-Bass Net/One routing, see the section "Enabling and Configuring Net/One Routing Configuration Example."
To control access to XNS networks, you create access lists and then apply them with filters to individual interfaces.
There are two types of XNS access lists that you can use to filter routed traffic:
There are two different types of filters you can define for XNS interfaces, and you can apply one of each type to each interface:
Table 22-1 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.
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:
To create access lists, perform one or more of the following tasks in global configuration mode:
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 section "3Com Access List Example."
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:
Step 1 Create a standard or extended access list.
Step 2 Apply a filter to an interface.
To create an access list, perform one of the following tasks in global configuration mode:
To apply a generic filter to an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Apply a generic filter to an interface. | xns access-group access-list-number |
For an example of creating a generic access list, see the section "3Com Access List Example."
Routing table update filters control the entries that the router 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:
Step 1 Create a standard or an extended access list.
Step 2 Apply one or more filters to an interface.
To create an access list, perform one of the following tasks in global configuration mode:
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 section "Extended Access List with Network Mask Option Example."
To assign routing table update filters to an interface, perform one of the following tasks 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 the (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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Add a static route to the routing table. | xns route network network.host |
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 our 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the RIP update timer. | xns update-time interval |
For an example of setting the RIP update timer, see the section "Routing Update Timers Example."
You can set the maximum number of equal-cost, parallel paths to a destination. (Note that when paths have differing costs, the router chooses lower-cost routes in preference to higher-cost routes.) The router 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 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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the maximum number of equal-cost paths to a destination. | xns maximum-paths number |
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. We support 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 router 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 will be forwarded to a remote network and 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 will generate 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 need to ensure that users can broadcast between networks without cluttering the internetwork with unnecessary traffic.
Whenever our router receives an XNS broadcast packet, it processes it as follows:
To configure helpering, which forwards broadcast messages to the specified host or hosts, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Forward broadcast messages to the specified host. | xns helper-address network.host |
You can specify multiple xns helper-address commands on a given interface.
For an example of forwarding broadcast messages, see the section "Helpering Example."
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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Forward packets of a specific XNS protocol to a helper address. | xns forward-protocol protocol |
Different XNS implementations require different flooding behavior. By default, our routers do no flooding. You can, however, configure interfaces on the router to apply flooding to the packets received on an interface.
Whenever our router 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.
Our router 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 router is configured to flood are sent out through all interfaces, except in the following cases:
To define an interface's flooding behavior, perform one of the following tasks 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 broadcast whose network address is all zeroes.
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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Disable XNS fast switching. | no xns route-cache |
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.
To monitor an XNS network, perform one or more of the following tasks at the EXEC prompt:
Use the following configuration examples to help in configuring XNS routing on your router:
The following example enables XNS routing on the 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
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
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
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
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
The following commands set up helpering for the configuration shown in Figure 22-1. The router 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 has nothing to do with helpering or protocol forwarding.
|
|