[c-nsp] IPCP associated default route

[Dean Smith]

David

Cant help on your specific question....but we're successfully using object
tracking to achieve (I think) the required result.

Dialer0 = Primary Link (DSL in this case)
Dialer1 = Secondary (ISDN...but still a dialer)

We track the "ip routing" state of Dialer 0. And attach that to the dialer0
default. With a higher cost default via Dialer1

So if PPP on dialer 0 fails...No address negotiated...track object goes
down. Default via Dialer1 takes over.

Don't have the config snippet to hand but from CCO :-

******
Perform this task to track the IP-routing state of an interface. An
IP-routing object is considered up when the following criteria exist:

.IP routing is enabled and active on the interface.

.The interface line-protocol state is up.

.The interface IP address is known. The IP address is configured or received
through the Dynamic Host Configuration Protocol (DHCP) or IP Control
Protocol (IPCP) negotiation.
*******
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
t/122t15/fthsrptk.htm#wp1040072

Dean

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: 09 August 2007 12:39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] IPCP associated default route

Hey,

  The command "ppp ipcp default route" which associates a default route 
with the the IPCP peer address, seems to not use the presence of the 
IPCP host route in the RIB as a watch criteria.

For example, if I have the following configuration:


!
interface Dialer0
  description Primary dialer
  ip address negotiated
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  keepalive 5
  down-when-looped
  ppp authentication chap callin
  ppp chap hostname foo at bar.com
  ppp chap password 0 foo
  !Obtain default for primary via peer address
  ppp ipcp default route
!
!
interface Dialer1
  description Backup dialer
  ip address negotiated
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  keepalive 5
  down-when-looped
  ppp authentication chap callin
  ppp chap hostname foo-backup at bar.com
  ppp chap password 0 foo
!Dont install the peer host route in RIB
!so we dont ECMP route to it via both diallers
  no peer neighbour-route
!
!
!Back up service with static
ip route 0.0.0.0 0.0.0.0 Dialer1 200
!

Both diallers are live all the time (this is a requirement) and 
connected via seperate circuits to the same NAS, the peer host route 
offered via IPCP is the same /32.

      ____circuit A live______
[CPE]____circuit B live______[NAS]


The injection of the peer host route into the RIB is supressed for the 
backup dialer so that we dont end up sending traffic to the /32 (which 
is the next hop of the default created by "ppp ipcp default route") over
both dialers whilst they are up.

The problem that I am having is that if the backup dialer's PPP session 
collapses (i.e circuit fails) then we withdraw the ipcp associated 
default from the primary dialer !

The only reason I can think for this is that the ipcp associated default 
is event managed out of the dynamic dialer mapped ip lists rather than 
the RIB, since two dynamic dialer map ips always exist out via both 
dialers, whenever we lose a dialler mapped ip to the peer host addres
(via either dialer) we withdraw the default from the RIB.

This is most frustrating , I dont wish to hardcode the peer host address 
into this device since it could change in the future,
can somebody confirm that this behaviour is expected, (seen in 12.4)
and if so does it indeed use the dynamic dialer maps to build
the association (and hence track the event?)
and if so, how can I supress the dynamic dialer mapped ip being 
installed via the backup dialer.

Of course there are a multitude of other approaches to dial backup which 
we currently have in place, this was however a new one for dial backed 
up dial that we are trying to get working (where both circuits are 
live), any help or other insight would be appreciated.

Kind Regards,

David Freedman

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/