From: Brian Hescock (bhescock@xxxxxxxxx)
Date: Tue Feb 06 2001 - 21:36:29 GMT-3
I'm doing some testing with dlsw over isdn and noticed that when doing
debugs on all packets with port 2065 I would only see them initiated by
the peer with the higher ip address. This naturally made a big difference
when trying to bring up the isdn link (using just the keepalives) since
the remote side was the lower ip address and would never send out any
packets unless it received one first for the other peer (or so it seems,
dlsw isn't one of my stronger points). Also, there has to be a better
method than making the one ip address higher on the remote, any other
solutions?
Of course, we probably wouldn't want keepalives to keep the link up anyway
so I would assume I should turn keepalives off. But why do we need to
lower the default timeout value of 90 seconds if we aren't using
keepalives, doesn't make much sense. I wouldn't think timeout would be
applicable if keepalives are turned out (but the docs very clearly say to
lower the value).
So let's say I have keepalives turned off. How is this going to affect me
when my primary link is up? Do I need to configure them as a dynamic peer
instead? And when using legacy ddr you use a dialer map for llc2. I'm
using dialer profiles so I don't need dialer maps, I just need to make
sure I define my interesting traffic. Even with dynamic peers, will
defining an access-list (for dialer-list) allowing ports 2065, 1981, 1982,
and 1983 handle everything for me?
And finally, what would be the best method for dlsw over isdn to bring up
the link, a dialer watch-group for the ip address / network of the remote
peer and let my dynamic routing protocol learn the new path via isdn?
Brian
p.s. IBM is just down the street, anyone want to join me in nuking them so
we can be done with token ring once and for all? I'll take Bill Gates
over IBM networking any day...
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:39 GMT-3