| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2134.1 | Might just be a connect direct to the target | MARVIN::RIGBY | No such thing as an alpha beta | Tue Feb 25 1997 17:16 | 3 |
| For what its worth OUI 00-00-77 is used in MIPS boxes (Interphase adaptors).
What's the rest of the packet?
|
| 2134.2 | target is DU system | CHEFS::DAVIDSONS | | Wed Feb 26 1997 02:18 | 7 |
| Thanks, I'll try and get a dump of complete packet.
If it was a connect direct to target wouldn't there be an entry
in the end node cache? Also the target is a Digital Unix system.
BTW. All five DU system behave the same regardless of which initiates
the dlogin, also IP is OK ie. can telnet between the DU systems.
|
| 2134.3 | Any spurious routers out there? | MARVIN::SHAND | Mike Shand | Wed Feb 26 1997 06:11 | 19 |
| I'm really guessing in the dark here, but one possibility is that there
is some system with mac address 0:0:77:88:9B:53 on the LAN which rightly
or wrongly is sending ISHs so that the DU boxes *think* it is the router.
This would explain why the packets are being sent there. If we assume that
the 0:0:77:88:9B:53 isn't in fact a correctly working router, and doesn't
forward the packets or generate a redirect, then you would get the behaviour
you observe. You would not expect an ES cache entry in this case (with the "new"
ES cache algorithm, you would with the old algorithm, but the new algorithm
doesn't form a cache entry until it has something positive to put in there).
It would help a great deal if you could get us some real packet traces,
including any other OSI traffic if there is any (e.g. all the FE SAP traffic).
This would allow us to spot for routers etc. You could take a look at the
adjacecnies in your DU boxes too.
What exactly is the LAN configuration supposed to be? What routers (if any) do
you have?
Mike
|
| 2134.4 | HP IS vs DEC ES | CHEFS::DAVIDSONS | | Thu Feb 27 1997 13:33 | 26 |
| Excellent guess, you were spot on!
The HP had MAC address 0:0:7:88:9B:53 and was configured as an IS.
(had to be an IS for ES config on VME cards, for which it routed OK)
The NSAP addresses have different domains:
DEC: 470027814E4C44014459594F4F4357504F2542
HP: 47002781455552005541312020111111112222
The HP was only routing for its' own domain and was not responding
to packets noticed in .0 note.
Outstanding questions:
- should an IS (eg. HP) respond to an ES request from a different
domain to say it does not route for that domain or should it ignore
the ES requests as it appears to do?
- should an ES (eg. DEC) request an IS in a different domain to route
its' packets?
Thanks,
Stuart.
(I hope to post a trace tomorrow)
|
| 2134.5 | A router should be prepared to route | MARVIN::SHAND | Mike Shand | Wed Mar 05 1997 04:56 | 37 |
| If something advertises itself as an IS (by sending an ISH) then it should
be prepared to route whatever OSI packets are sent to it. At the very least it
should forward them (and issue redirects) to another router which CAN route
them. It is not acceptable to just drop the packets.
- should an IS (eg. HP) respond to an ES request from a different
domain to say it does not route for that domain or should it ignore
the ES requests as it appears to do?
Neither. As I said above, it should forward the packets. The only possibility
which is close to saying it doesn't route is to send a so called "null
redirect", which says "I don't know who can forward this, but I know I can't".
This is a redirect message with a null subnetwork address. This action is NOT
standardized, but if you send such a redirect to a DIGITAL OSI implementation
it will cause any existing cache entry to be deleted. However, this wouldn't
help in this case, since there is no other cache entry, and only one router
adjacency, so the packets will just be sent back to the "router" again.
- should an ES (eg. DEC) request an IS in a different domain to route
its' packets?
No. Any router should do, as I outlined above. A level 1 router in the "wrong"
domain should be able to forward the packets to a level 2 router which can reach
that domain.
How about letting the DEC systems autoconfigure into the HP domain as well
(or manually configuring them if you prefer). Alternatively how about adding the
DEC domain to the HP "router".
A further possibility would be to run the DEC systems in segregated mode and
use PhaseIV compatible addresses. The effect of this is that it will look for a
phaseIV router adjacency, and finding none will transmit the packet to the mac
address derived from the PhaseIV address.
Mike
|