eriks@elsbeth.yorku.ca (Eriks Rugelis) (05/14/91)
Hi,
I'm posting this question here because I expect that the answer may be of
interest to a wider audience...
I have an AGS/3 that has a number of MCI Ethernets and a 4 Mb Token-Ring card.
All of the Ethernets and the Token-Ring are configured to route IP. The
Ethernets are also configured to route DECnet.
I would like to experiment with IPX routing between one of the Ether interfaces
and the Token-Ring. However, the AGS complains (and the manual confirms) that
DECnet and IPX routing cannot operate in the same crate while a Token-Ring
interface is present.
My questions are:
- Why is this so? I'm not trying [wouldn't even think! :-)] to route DECnet
on the TR... so why the tie-in?
- Is this restriction expected to be lifted in a forseeable future release
of the cisco software? If so, when?
Thanks,
EriksEriks Rugelis <eriks@elsbeth.yorku.ca> (05/14/91)
I wrote: > However, the AGS complains (and the manual confirms) that >DECnet and IPX routing cannot operate in the same crate while a Token-Ring >interface is present. I neglected to mention that the router in question is running 8.1(21). I've had a couple of replies that indicate that 8.2(3) resolves this issue (indeed, one of the respondents says that he has this configuration running right now). Apparently this is covered in the GS 8.2(3) release notes (I only have 8.2(1) delivered and have never installed it). Thanks to those that replied. Eriks
"Roger Fajman" <RAF@CU.NIH.GOV> (05/14/91)
> > However, the AGS complains (and the manual confirms) that > >DECnet and IPX routing cannot operate in the same crate while a Token-Ring > >interface is present. > > I neglected to mention that the router in question is running 8.1(21). I've > had a couple of replies that indicate that 8.2(3) resolves this issue (indeed, > one of the respondents says that he has this configuration running right now). > > Apparently this is covered in the GS 8.2(3) release notes (I only have 8.2(1) > delivered and have never installed it). We tried to do this for XNS and DECnet in a box with a token ring, using 8.2(1). When DECnet was enabled, XNS stopped working on the token ring. Cisco has not been very responsive to our problem report. There does seem to be some ambiguity. The XNS routing command allows a MAC address to be specified, but it is unclear what the bit order is when both Ethernet and token ring are present. I would be interested in hearing from someone who has run XNS, DECnet, token ring, and Ethernet in one router.
Nick Thille <thille@cisco.com> (05/14/91)
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). ---------------------------------------------------------------------------
ralls@cisco.com (05/14/91)
Roger, I'm very sorry if you feel that cisco has over looked your problem. 8.2(1) had many problems, in general we suggest that customers upgrade to 8.2(3) if they encounter difficulties with 8.2(1). I'm sorry that this was not mentioned when you talked to customer support. I will be looking into this problem with XNS/DECnet and token ring, and trying to reproduce the problem here in our lab with 8.2(3). Could you answer a few questions to help me track this down? What exactly happens when XNS stops working? Have you turned on XNS debugging to see if there are any errors, if packets are still getting though. Have you checked "show traffic" to see if there are any obvious problems. Have you tried turning off fastswitching for DECnet and XNS to see if that makes any differnace. If you turn DECnet back off does XNS start working again? Thanks for your help and patience, vicki
ralls@cisco.com (05/14/91)
Actually yes, there is a problem in 8.2(1) fixed in 8.2(3) that might cause exactly the behavoiur that you are seeing. Is is caused by checking addresses a little to restrictively. As a result valid packets would not get though. If you see a number of "multicasts" in the "show xns traffic" then you are probebly seeing this problem. If you do, you should upgrade to 8.2(3). I'll let you know how I do with reproducing the problem here. -vicki
JOHN@heap.cisco.com (John Wright) (05/24/91)
>We tried to do this for XNS and DECnet in a box with a token ring, >using 8.2(1). When DECnet was enabled, XNS stopped working on the >token ring. Cisco has not been very responsive to our problem report. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would like to publicly apologize for the handling you have received, it was in a large part my responsibility. I'm Sorry. cisco endeavors to provide the best products and support in the industry, and we are taking steps to see that our support remains at the high level the majority of our customer have become accustomed with. I see others from cisco have been in contact with you regarding this particular problem. I hope that we will be able to resolve this and any other issues in a more timely fashion. Sincerest Apologies, John Wright Customer Engineering Analyst cisco Systems, Inc. -------