pptp + bird

[Amadeus]

Hi Ondrej,

this is what I see when the problem occurs:

a) interface (ppp5) is up after it has been re-established by pppd after
connection reset:
# ip a s dev ppp5
923: ppp5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1446 qdisc
pfifo_fast state UNKNOWN qlen 3 link/ppp inet 169.254.0.1 peer
169.254.40.52/32 scope global ppp5

b) it is also present in birdc:
> show interfaces
ppp5 up (index=923)
PtP Multicast AdminUp LinkUp MTU=1446
169.254.0.1/32 (Primary, opposite 169.254.40.52, scope univ)

c) the interface has been rescanned by bird as ppp5:
10-08-2012 11:17:30 <TRACE> static1 < interface ppp5 goes up

d) routes are missing (table 100 = kffc):
# ip r s table 100 dev ppp5
<no output>

-- What happended before --
DOWN event:
10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.129.32/28 via
169.254.40.52 on ppp2
10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.129.32/28 via
169.254.40.52 on ppp2
10-08-2012 11:18:38 <TRACE> static1 > removed [sole] 10.8.131.48/28 via
169.254.40.52 on ppp2
10-08-2012 11:18:38 <TRACE> kffc < removed 10.8.131.48/28 via
169.254.40.52 on ppp2

When I look at the timestamps it seems as if the old interface is not
down before the new one comes up which means that bird won't be able to
set the new routing information as it is still present on the old
interface, does that make sense to you? Is there any trigger in bird to
catch that or do I have to set scan device >>60s?

Thanks,
Amadeus


Am Donnerstag, den 09.08.2012, 11:41 +0200 schrieb Ondrej Zajicek:
> On Wed, Aug 08, 2012 at 11:56:41PM +0200, Amadeus wrote:
> >> if that client reconnects, 169.254.0.1 would become accessible and  
> >> route should reappear (with possibly different iface).
> >
> > Here comes the problem: bird is not adding any routes back, only if I  
> > restart it the static protocol sets all routes correctly again (to the  
> > new interface). I have log option 'all' but it is not saying anything  
> > helpful I guess - what do you suggest to debug this a little better?
> 
> Hello, i cannot reproduce that behavior, works for me.
> 
> You could check (and send me) this:
> 
> 1) State of the iface (show interfaces), whether the problem does not
> correct after the next iface scan (for more often iface scans put this:
> "protocol device { scan time 10; }" to the config file.
> 
> 2) What is a state of static protocol (show static) whether the route
> is 'dormant' (as if the neighbor is not connected) or not.
> 
> 3) 'debug protocols all' in config files and send me log region around
> route removal (during disconnect) and around expected route adding
> (during ppp reconnect).