[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::dnu_osi

Title:	DECnet/OSI for {ULTRIX,OSF/1}
Notice:	Indicate version and platform when writing...see #2 for kits
Moderator:	BULEAN::CARR

Created:	Wed Sep 25 1991
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2187
Total number of notes:	10469

2180.0. "Routing Vector router misleads endsystem" by MARVIN::GOUGH (Raoul Gough) Fri May 16 1997 12:47

I've got a DUnix 4.0 end system here which has a problem when there is a
Routing Vector router on the network.  We've analysed the problem here and
believe that we can explain it (but not really fix it).  I'm writing from
IPEG Reading, where I got Mike Shand to help me out.  You might be interested
in this, even if nobody is going to fix the problem.


The end system has got four interfaces, one of which connects to the office
network, and the others connect to networks we use for testing network
equipment.  It loses Decnet+ connectivity to systems on the local networks
when there is a Routing Vector router on the office network (actually an
OpenVMS system which doesn't support Link State routing).  The Routing Vector
router gets a default route from all of the Link State routers on the network
and redirects the end system to one of those.  This causes the end system to
believe that it has a good route to the address, which it uses despite
receiving destination unknown messages from the Link State router singled out.

The only workaround we've come up with is to create static routes on the local
networks.  Is there any way to make it give up the redirect route?


Regards,
Ray.

T.R	Title	User	Personal Name	Date	Lines
2180.1		quarry.zk3.dec.com::matt	The Code Warrior	`Fri May 16 1997 14:05`	4
	I suppose Routing should do a rouv_cache_flush() on the NSAPAddress received in the error report. It should also do that for a returned- to-sender Phase IV packet. I wonder why we never though about this in the new routing stuff?
2180.2		BULEAN::LEE		`Fri May 16 1997 19:50`	17
	RE: .0 Where does Mike Shand think the bug is? If the redirect from the OpenVMS router is correct, then I think the problem is mainly in the architecture. Once the endsystem received the redirect, a cache will be created unless there was a direct path cached already. There is no way for the endsystem not to use it because ES always thinks that the routers should know better. In this case using the reachable address/static route is the solution. RE: .1 On an OpenVMS endsystem, transport will disconnect the link when it receives a destination unreachable ER packet and no cache flushing in Routing.
2180.3	It is in the architecture	MARVIN::GOUGH	Raoul Gough	`Mon May 19 1997 15:00`	30
	> RE: .0 > > Where does Mike Shand think the bug is? > > If the redirect from the OpenVMS router is correct, then I think the > problem is mainly in the architecture. Once the endsystem received > the redirect, a cache will be created unless there was a direct path > cached already. There is no way for the endsystem not to use it > because ES always thinks that the routers should know better. > In this case using the reachable address/static route is the solution. As I recall, Mike figured that it was an architectural problem. The link state routers had to get some information into the distance vector router. I think that it was designed to help out Clustered systems or Cluster Aliases, but I don't know anything about those myself. Mike reached the same conclusion, the end system is going to believe that the router knows what it's talking about. However, it should be possible to discard the route later in the light of further information (as in .1?). I'm supposing that somebody believed it was worth fixing. Re: the static route solution. I've been living with that for a while now but I'm not really happy with it. Some of the systems have got multiple routes to the end system and it doesn't seem to fail over properly with more than one static route defined (maybe that's another problem). Ray.
2180.4		BULEAN::LEE		`Mon May 19 1997 19:16`	10
	RE: .1 & .3 Flush the cache of the NSAP that is in the error report packet will not really solve the problem here. Without the cache, the ES will send the packet to the OpenVMS router again, and again that router will redirect to a link state router, and a dynamic cache will be created on the ES again. So this is going in circles... I guess the solution is for the OpenVMS router to support link state routing in the future.
2180.5	ES doesn't always choose the same router	MARVIN::GOUGH	Raoul Gough	`Tue May 20 1997 17:59`	16
	From .4: As I understand it, the ES will choose one of the routers on the network at random (or round-robin or some other method). So it won't always get the Distance-vector router. What it really needs to do is try one of the other interfaces, which it will do with a configurable frequency. I think it does it sooner when it has no information at all. > Flush the cache of the NSAP that is in the error report packet > will not really solve the problem here. Without the cache, > the ES will send the packet to the OpenVMS router again, and again > that router will redirect to a link state router, and a dynamic cache > will be created on the ES again. So this is going in circles... Ray.