Re: Return route not added on demand dial router
From: Bill Grant (not.available_at_online)
Date: 08/27/04
- Next message: Bill Grant: "Re: Weird site to site issue... ?"
- Previous message: Phil H: "PPP connection to an embedded realtime OS, options?"
- In reply to: GeorgeR: "Re: Return route not added on demand dial router"
- Next in thread: GeorgeR: "Re: Return route not added on demand dial router"
- Reply: GeorgeR: "Re: Return route not added on demand dial router"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 27 Aug 2004 13:41:45 +1000
The only time I have seen this is if the connection does not bind to the
demand dial interface on the answering router. From the RRAS console, can
you check that the dd interface actually changes to the "connected" state?
If it doesn't, that explains why the static route isn't added. If it
does, it is an odd malfunction and you will probably need to lodge a call
with Microsoft.
"GeorgeR" <grasch@dataspecialists.com> wrote in message
news:ebd75c4d.0408251215.156cb7fe@posting.google.com...
> Sorry for the delay in the follow up here. We reinstalled service pack
> 4 on the server on the receiving end of the calls. Sorry for the
> confusion as well on the previous post. The route table I was
> referring to is the table visible through the graphic user interface
> associated with the RRAS application. The routing table as visible
> using route print yields a different story.
>
> I have had multiple people examine this and all say it is set up fine.
> We have checked the user and interface names. They match. The static
> routes we have added have been by using the wizard in the RRAS
> application. All appears OK. Despite all this the difference is
> clearly identified as the routing table on the machine initiating the
> call being correct and the routing table on the machine receiving the
> call being wrong.
>
> On the machine receiving the call the problem is clearly that the
> static route back to the calling machine is not added. The routing
> table on the receiving machine changes once the call is connected to
> add the following entries in the routing table. An entry is added for
> the modem on the receiving end ... An entry is added for the modem on
> the calling end. Beyond that we do not have the most critical entry
> which is for us an entry which would point back to the calling
> network. That is 192.168.101.0 with a mask of 255.255.255.0.
>
> This is bit frustrating as it seems likely people do this kind of
> stuff everyday and we seem to have no way forward now. Any other ideas
> are appreciated.
>
> Thanks,
>
> George
>
>
>
> "Bill Grant" <not.available@online> wrote in message
news:<OBpvSdnhEHA.556@TK2MSFTNGP10.phx.gbl>...
> > As you say, you have no access to the gateway until you set up the
> > connection. In fact the gateway doesn't exist until you make the
connection.
> > That is why you use the demand-dial interface name as the symbolic name
for
> > the connection. You can link the routes to this interface, and the
system
> > will then make the necessary links when the connection is made. Have you
set
> > up these routes from the New Static Route wizard, and selected the
> > demand-dial interface from the dropdown interface list (and left the
gateway
> > address blank)?
> >
> > Where do you see these routes you describe? From the RRAS console?
> >
> > What do you see if you do a route print from a command prompt? The
> > subnet route to the calling router's subnet should have the IP adress
of
> > the VPN connection as the gateway address and the IP address of the
> > demand-dial interface as the interface address.
> >
> > The routers at both ends of the connection must have a subnet route
to
> > the "other" subnet through the VPN tunnel. They should be "real" IP
> > addresses, not things like 0.0.0.0 or 1.1.1.1 .
> >
> > "GeorgeR" <grasch@dataspecialists.com> wrote in message
> > news:ebd75c4d.0408191840.40ecc35c@posting.google.com...
> > > What follows is an excerpt from the routing table on the receiving end
> > > once the connection has been made. I have only included the entries
> > > for the demand dial interface items.
> > >
> > > 192.168.101.0 255.255.255.0 0.0.0.0 dd_dsi1
> > > 192.168.101.255 255.255.255.255 0.0.0.0 dd_dsi1
> > > 224.0.0.0 240.0.0.0 0.0.0.0 dd_dsi1
> > > 255.255.255.255 255.255.255.255 0.0.0.0 dd_dsi1
> > >
> > > and the following entry appears relevant as well and is the ip address
> > > of the modem after the connection has been made
> > >
> > > 192.168.101.82 255.255.255.255 127.0.0.1 loopback
> > >
> > > The receiving end machine is on a 192.168.0 subnet
> > >
> > > Once the connection is made it is obvious that the receiving end
> > > machine
> > > has some knowledge of the calling interface. It went to the trouble of
> > > adding the above routes to the routing table. But how does it know how
> > > to make it's way back. When I ping or tracert on the receiving end
> > > something along the lines of tracert 192.168.101.242 (a server on our
> > > end)
> > > the tracert goes right out the default gateway on the receiving
> > > machine
> > > it behaves as if the entry is not in the routing table. What I do not
> > > understand is given the above entries how does it know to make it's
> > > way
> > > to the modem (192.168.101.82)? Nothing about that entry in any way
> > > ties
> > > to the dd_dsi1 interface information.
> > >
> > > George
> > >
> > >
> > > "Bill Grant" <not.available@online> wrote in message
> > news:<OxS4gcdhEHA.2540@TK2MSFTNGP10.phx.gbl>...
> > > > That is odd. The address should be the IP address allocated to the
> > > > demand-dial interface. Are you sure you have the static route linked
to
> > the
> > > > demand-dial interface?
> > > >
> > > > "GeorgeR" <grasch@dataspecialists.com> wrote in message
> > > > news:ebd75c4d.0408181421.35f6d3ac@posting.google.com...
> > > > > We reviewed the configuration and verified all is a described
here.
> > > > > The name of the interface on the receiving end matches the user
name
> > > > > on the initiating end. In viewing each system I can see the static
> > > > > route has been added to the routing table but the problem appears
to
> > > > > be in the gateway associated with that static route. The gateway
is
> > > > > always identified as 0.0.0.0 instead of pointing to the ip address
of
> > > > > the "way back" to the other system. Since we have no access to the
> > > > > gateway when setting up the static route it seems as if the OS
should
> > > > > be updating the gateway to reflect the information available once
the
> > > > > connection has completed.
> > > > >
> > > > > George
> > > > >
> > > > > "Bill Grant" <not.available@online> wrote in message
> > news:<ea7WDOecEHA.1408@TK2MSFTNGP12.phx.gbl>...
> > > > > > No routing is set up by default. You need to set up static
routes
> > and
> > > > > > link them to the demand dial interfaces at both ends. To
activate
> > the
> > route
> > > > > > on the answering router, you must connect to the demand dial
> > interface.
> > You
> > > > > > make this happen by using the name of the demand dial interface
as
>
> > the
> > > > > > username when you make the connection.
> > > > > >
> > > > > > What happens is this. If a RRAS router receives an incoming
> > connection
> > > > > > where the username matches one of its demand dial interfaces, it
> > connects to
> > > > > > that interface and activates any static routes linked to that
> > interface.
> > If
> > > > > > the username does not match a demand dial interface's name it is
> > assumed
> > to
> > > > > > be a simple client-server request, and only a host route is
> > established
> > back
> > > > > > to the caller through the link.
> > > > > >
> > > > > >
> > > > > > "GeorgeR" <grasch@dataspecialists.com> wrote in message
> > > > > > news:ebd75c4d.0407231929.e85d4cb@posting.google.com...
> > > > > > > I have two servers. I have created a demand dial environment
> > between
> > > > > > > the two servers using modems. When server A initiates a
> > conversation
> > > > > > > with server B the modem on A is activated, the connection is
made
> > and
> > > > > > > authenticates successfully. Both machines indicate a
successful
> > > > > > > connection. The routing table on Server A looks correct and it
is
> > > > > > > possible to see the route to server B. On Server B we do not
see a
> > > > > > > route back to Server A. Because of this we cannot make
anything
> > work
> > > > > > > between the two servers. On Server A we have a static route to
> > Server
> > > > > > > B and it is obvious by the fact the modem dials and a
connection
> > is
> > > > > > > made the the static route is being used. On Server B we have a
> > static
> > > > > > > route back to Server A in the event Server B were to initiate
the
> > > > > > > traffic. When Server A connects with Server B the routing
table on
> > > > > > > Server B does not indicate the route back to Server A. All
traffic
> > on
> > > > > > > Server B continues to use the default gateway. Everything
looks OK
> > > > > > > configuration wise but obviously we have missed something.
Does
> > anyone
> > > > > > > have any ideas?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > George
- Next message: Bill Grant: "Re: Weird site to site issue... ?"
- Previous message: Phil H: "PPP connection to an embedded realtime OS, options?"
- In reply to: GeorgeR: "Re: Return route not added on demand dial router"
- Next in thread: GeorgeR: "Re: Return route not added on demand dial router"
- Reply: GeorgeR: "Re: Return route not added on demand dial router"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
