Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!daemon From: Nick Thille Newsgroups: comp.dcom.sys.cisco Subject: DECnet and IPX routing in the presence of a TR interface? Message-ID: <35042@boulder.Colorado.EDU> Date: 14 May 91 00:22:39 GMT Sender: daemon@boulder.Colorado.EDU Lines: 154 Eriks, > - Why is this so? I'm not trying [wouldn't even think! :-)] to route DECnet > on the TR... so why the tie-in? There was some conflict between the first part of the DECnet address (It needs to look like a DEC hardware address) and the token ring broadcast address. This is because DECnet demands that the address begin with AA00. The binary for the first two bytes is 10101010. Ethernet sends least significant bit first. The first bit to hit the wire is 0, indicating not a broadcast. The second bit to hit the wire is 1, indicating it is a locally administered address. When you send the same address on token ring, it is sent most significant bit first. The first bit to hit the wire is 1, indicating a broadcast. The second is 0, indicating that it is not a locally administered address. As you can see, this doesn't work too well. One can get sneaky and set the addresses for the token ring interfaces and ethernet interfaces differently so that you won't get bit my this problem, but if you want to route IPX or XNS, all addresses on the router need to be the same. This is where the rub comes in. In release 8.2, cisco came up with a work-around by swapping the bits in the DECnet address on Token Ring. Rather than get too bogged down in the technical details, I will attach a note describing the changes. > - Is this restriction expected to be lifted in a forseeable future release > of the cisco software? If so, when? The restriction is lifted in the currently shipping release, 8.2(3), and was lifted in release 8.2(1) which began shipping in December. Hope this help, Nick Thille Customer Engineering cisco Systems Excerpted from technical notes for 8.2 release: DECNET on Token Ring Prior to this release, DECNET was not supported across Token Ring media. With this release, DECNET Phase IV/ Phase V routing is fully supported between cisco routers. In addition, DECNET communication can take place between a cisco router routing DECNET traffic and a Token Ring node that meets certain criteria. Configuring the cisco for DECNET IV on Token Ring is very similar to configuring DECNET IV on Ethernet. The only difference is the specification of a token ring interface rather than an ethernet. Below is an example of a Token Ring configuration: decnet routing 10.4 interface tokenring 0 decnet cost 10 interface tokenring 1 decnet cost 10 The DECNET Address Translation Gateway is also fully supported. Interoperability Implementation Details The cisco Token Ring DECNET implementation will interoperate not only with cisco routers but other Token Ring DECNET nodes if certain criteria are met. These criteria must be explicitly mentioned because there is not an agreed upon standard for DECNET IV on Token Ring. DECNET V follows various ISO-OSI standards and should interoperate without any special constraints. DECNET IV requires that certain MAC level addresses be used before communication can take place. Below are the MAC addresses that the cisco DECNET IV on Token Ring implementation uses. Any non-cisco implementation that conforms to these criteria will be able to communicate via the cisco Token Ring DECNET IV implementation. Implementation details: 1) Canonical (IEEE 802.1a) addresses in non-MAC layers. When a DECnet node uses a MAC address in a layer above the MAC layer it must be represented in Ethernet (IEEE 802.1a canonical) storage order. An example of such a packet is the HELLO packet. 2) Individual DECNET Node MAC addresses on Token Ring are of the form 5500.2000.abcd (native token ring) where 'abcd' is the Token Ring representation of the 'area.node' assigned to the host. It is the bitswapped representation used by an Ethernet. ie. If the area, node for a host were 10.18. The corresponding Ethernet MAC address would be AA00.0400.1228. The same node on Token Ring would be 5500.2000.4814 (native). 3) End Node Multicast address is assigned to the Token Ring functional address C000.2000.0000 (native). 4) Router Multicast address is assigned to the Token Ring functional address C000.4000.0000 (native). --------------------------------------------------------------------------- DECNET/XNS/Novell Split In previous releases it was not possible to run DECnet IV and any of the XNS varients simultaneously in a router that included both Ethenet and Token Ring interfaces. This restriction has now been removed. ** There are no changes to the syntax of any configuration commands. ** The current implementation has the following characteristics: XNS implementation: When "XNS routing" is enabled, all ethernet interfaces have their MAC addresses changed. The value used is either the ethernet address specified in the XNS routing configuration command or the first Ethernet address in the system. The address selected in the above sequence is also used as the node address that non-LAN media (noteably serial links) use for their XNS node addresses. If there are no Ethernets in the system, then the xns routing configuration command requires the ethernet address to be specified. This address is then used as the "default" xns node address used for non-LAN nodes. The ethernet addresses are changed to one value to remain compatible with the XNS specification. True XNS networks assume that this is true. Non-Ethernet LAN media (FDDI, Token-Ring), use the native hardware address assigned without modification. This allows coexistence with other protocols that have constraints on what addresses can be assigned (such as DECnet IV). Novell Netware (IPX) implementation: The cisco IPX implementation no long coerces addresses on network interfaces in any way. An interface takes as its Novell node address whatever hardware MAC address is currently assigned to the interface. If later the MAC address is coerced to some other value, the Novell node address will automatically change to the new address. Like the XNS implementation, the address parameter to the "novell routing" configuration command establishes the "default" novell node address. This address is used as the novell node address for any non-LAN interfaces (such as serial links). ---------------------------------------------------------------------------