Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) Re: GRF problems with gated

On Sun, 5 Apr 1998, Neil J. McRae wrote:

> > I don't know your configuration in detail, but it's worth pointing
> > out that it's likely you didn't need to resolve nexthops with
> > static.  You probably could have listed the interface on the shared
> > medium in the group type routing clause.  E.g., supposing that ef0
> > was the interface on the shared net:
> > 
> >     group type routing peeras XXX proto YYY interface ef0 {
> > 
> > (By the definitition of group type internal, you must have had a
> > shared medium, in terms of which the group type internal peer would
> > write the bgp nexthop.  The configuration above makes the group
> > type routing peer do likewise.)
> > 
> 
> Well yes, but the medium wasn't shared. I had to use group type internal
> peer xxxx gateway xxx. I know! Its a gross hack but it was the only way
> I could make a BSDI 3 machine talk to a GRF in the same AS, Ascend
> didn't support group type internal, and BSD/OS's gated didn't support
> group type routing w/ static as a resolver.

Following this hint and ignoring your advice about Ascend's group
type internal being broken, I reconfigured our routers to not use
group type routing at all - I reconfigured both the GRF and our
pentium-based gated routers to use only group type internal, using
the gateway hack wherever necessary.  This turns out to work.

Pentium-based routers that had previously been unstable when using
group type routing to talk to one another are now stable.

The GRF, which was dropping the session every 30 seconds when using
group type routing, is now quite stable using group type internal.

This is obviously not ideal, but group type routing both on the GRF
and with gated 3.5.8 is so seriously flawed as to be unusable.
 
> Hence the need for a static route that is:
> 
> on the GRF:
> #
> #       NON ROUTE REFLECTION CLIENTS
> 	group type routing peeras 8220 proto static interface all 
>         {
>                 peer 195.110.67.194 gateway 195.110.65.129 logupdown; # barkley
>         };
> };
> #

I was using group type routing with proto ospf; possibly this is what
makes the difference.  

> Then on the BSDI box:
> 
>         group type internal peeras 8220
>         {
>                 peer 195.110.65.130 gateway 195.110.67.193 logupdown
>                 traceoptions "/var/log/gated/grover.log" 
>                 replace size 500k files 2 open update policy;
>         };
> 
> And I had static {}; clauses pointing at each interface. Not ideal
> but at the time it worked. 
> 
> My next GRF step is to upgrade them all to 1.4.6, boy thats going
> to be fun :-).

Is there any reason to upgrade to 1.4.6?  Why is this expected to be
difficult? - or do I misunderstand?

--
Jim Dixon                  VBCnet GB Ltd           http://www.vbc.net
tel +44 117 929 1316                             fax +44 117 927 2015

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>
Follow-Ups: