APE Route reflector stability
Would someone like to comment on what's happening with the APE route reflectors? The flap statistics I'm seeing are impressive - those servers got wings now? :-) Cheers, Gordon
On Fri, Jul 14, 2006 at 07:56:44AM +1200, Gordon Smith said:
Would someone like to comment on what's happening with the APE route reflectors?
What are you seeing? As always, contacting the provider in question (Citylink, in this case) is likely to get more traction than a post to NZNOG.
The flap statistics I'm seeing are impressive - those servers got wings now? :-)
They get restarted whenever a peer is amended, so I'd expect them to restart most days. That's why there are two of them, so that at least one is up at any given time (we always do staggered restarts). The restart is required because the route servers configs are machine generated from RPSL, generally adding or amending a host causes all ACL's to get renamed. So a restart is the saner alternative to trying to manually edit a BGP config that (currently) runs to some 8000 lines. Cheers Si
Hi all. On Fri, Jul 14, 2006 at 07:56:44AM +1200, Gordon Smith said:
Would someone like to comment on what's happening with the APE route reflectors? The flap statistics I'm seeing are impressive - those servers got wings now? :-)
This turned out to be caused by another ISP lighting up a new router and a) getting the netmask wrong b) forgetting to disable proxy-arp So, those setting up new routers, especially Cisco kit that defaults to turning proxy-arp on, "no ip proxy-arp" is your friend. An interesting observation is that of the ~40 active peers, only two seemed to be adversely affected by the proxy-arp, and they're both Juniper boxes. I'm wondering if Junipers may have a more trusting approach to handling ARP replies than other kit. So, if anybody has bright ideas on ways that the ARP handling of Junipers can be made a little more cynical (ie, something more like the Linux handling where it does unicast ARP until the other end stops responding, and then goes back to broadcast ARP, but something less restrictive than static ARP entries), I'm all ears. Cheers Si
participants (2)
-
Gordon Smith -
Simon Blake