[zebra 17495] Re: Announcement: Zebra/ospf config walkthrough

> I thought this would be a place to announce a config guide type thing
> for ospf, please check http://aggriffiths.d2.net.au/andrewg/
Let's do link exchange with pilot.org.ua/zebra, Ok ?

    DO4-UANIC

[zebra 17507] Announcement - IPv6 Peer problems.

We're currently experiencing problems here at IPv6 Peer.

Here are the services that will be affected:
- IPv6 BGP.
- Zebra Documentation (http://www.ipv6peer.net/zebra)
- IPv6 Peer OSPF/BGP/IPsec VPN.
- Basically, everything.

I've just received new hardware and most of the machines are getting
converted to FreeBSD 5.0.

The expected downtime is of 3 days.

I am also willing to maintain the documentation for Zebra since it has
got my precious attention. Any objections ?

--

-- 
Jean-Francois Laforest
----------------------------------------------
McGill Computer Engineering Department
http://www.mcgill.ca/ece/research
http://www.ipv6peer.net/
fuzzball <at> ipv6peer.net
-----------------------------------------------

[zebra 17508] Re: OSPF[point-to-multipoint, route filtering]

On Wed, Jan 29, 2003 at 02:34:29AM +1100, Andrew Griffiths wrote:
> Hi guys/(girls?)
> 
> Was wondering if some people could clue me in here.
> 
> 1) Will Roger Venning's point-to-multipoint patch be applied to zebra?
> If not, can you give any tips for what needs to be done to make it
> acceptable. As was pointed out, this is something needed for wireless
> experimenters. (Otherwise it seems to get stuck in the loading state).

Roger Venning's point-to-multipoint patch has been enormously useful in
my wireless networking project.  I hope that it will be accepted into
the official sources.

Dave

> 
> 2) Two, is it possible to filter routes from ospf in the same area?
> 
> Generally what I'm thinking, it'd be the same as rip's filtering abilities.
> 
> This is especially handy for what I/we (referring to, say,
> melbourne.wireless.org.au (which, at the moment, is down))  people want 
> to do, as it'll help prevent
> bogon announcements/misconfiguation errors, default routes etc. I 
> realise (http://tania.be.linux.org/zebra/msg00230.html) has been brought 
>  up before, though I was wondering if anyone had any intention of 
> implementing it.
> 
> I've tried googling, but all I found was a reference 

[zebra 17509] Status of SNMP MIB support

Hello

Does anybody know the status of the SNMP MIB support in Zebra?

I am trying to set up SNMP support against OSPF.

I have managed to start net-snmp with smux support and I can see some of
the MIB variables of the OSPFd. But does anybody know if some
set-rutines are developed for the MIB-variables that can be set?

Best regards
Petter Larsen

[zebra 17510] Zebra site in Spanish

[zebra 17511] Re: metric of static routes, more default routes

--On Saturday, February 1, 2003 12:55 am +0100 0ndrej <0 <at> amu.cz> wrote:

> I observed, that the static routes distributed via zebra/ospfd have
> always (on all the other routers) the metric assigned by the originating
> router. In another wording - the metric of the path between the routers
> is not added to the metric of the static route.
>
> We would like to have more default routes, each of them being selected
> based on smaller metric. Is it possible somehow?

Look up the difference between type-1 and type-2 external routes.

Rick

[zebra 17512] Re: HITLESS-RESTART and Forwarding Entry

d.deepak wrote:
[...]
> 
>  Problem: Here if there was any LSA that explained to OSPF that the
> 1.1.1.1 would be no more the best route or what so ever, how will the
> route get deleted from the Forwarding table. Becoz 1.1.1.1 still remains
> as the route given by OSPF. The draft never&nbs! ! p;explains any such
> situation comming across HITLESS-RESTART.

If I understand your statement correctly, then I'd guess the common 
solution would be marking the routes of a going-down OSPF process as 
"stale", with some preset timeout (the sensible presumed period it takes 
for the router to complete the graceful restart and get back to steady 
state). During router re-synchronization, each newly injected route will 
override an older "stale" route, if such route with matching properties 
exists. After timeout expiration, all OSPF routes that are yet marekd as 
"stale" will be flushed from the RIB (and thus from FIB as well).

This whole process should most probably be carried out by the RIB daemon 
(Zebra). I believe there isn't such mechanim in current Zebra, although 
I assume it wouldn't be too complicated to implement.

No idea about your other questions... 

Gilad

[zebra 17514] Re: metric of static routes, more default routes

Rick Payne wrote:
> 
> --On Saturday, February 1, 2003 12:55 am +0100 0ndrej <0 <at> amu.cz> wrote:
> 
>> I observed, that the static routes distributed via zebra/ospfd have
>> always (on all the other routers) the metric assigned by the originating
>> router. In another wording - the metric of the path between the routers
>> is not added to the metric of the static route.
>>
>> We would like to have more default routes, each of them being selected
>> based on smaller metric. Is it possible somehow?
> 
> 
> Look up the difference between type-1 and type-2 external routes.
> 
> Rick

hmmmm .. could you be please more specific, like where should I look to? 
I looked up in all the docs about zebra I could find (the loong html, 
various web collections) and nothing. I wouldnt ask, if I could find it 
there beforehand.

What about some example line in zebra.conf ? I'm postive it would be 
helpfull for more people and some could even include it their howto...

thanks
0.

[zebra 17515] Re: metric of static routes, more default routes

0ndrej wrote:
> Rick Payne wrote:

>> Look up the difference between type-1 and type-2 external routes.
>>
>> Rick
> 
> 
> hmmmm .. could you be please more specific, like where should I look to?

The OSPF RFC section 2.3 <http://www.ietf.org/rfc/rfc2328.txt>

     OSPF supports two types of external metrics.  Type 1 external
     metrics are expressed in the same units as OSPF interface cost
     (i.e., in terms of the link state metric).  Type 2 external
     metrics are an order of magnitude larger; any Type 2 metric is
     considered greater than the cost of any path internal to the AS.
     Use of Type 2 external metrics assumes that routing between
     AS'es is the major cost of routing a packet, and eliminates the
     need for conversion of external costs to internal link state
     metrics.

So you usually want external routes to have a Type 2 metric.
These Type 2 metrics can be compared with another Type 2
metric.  So you can say "this default route is better than
that default route".

Type 2 metrics are always worse than a Type 1 metric.  Type 1
metrics are comparible with interior routes.  This doesn't
matter for default (as there's no interior default route
in area 0).  It does matter is you learn both a route both
from the interior and from the exterior.  In that case the
interior route is always the best route.

There are occassions when you don't want this behaviour
(like if you have a geographically large network with
default injected in differing cities), thus the nerd knob
to make a exterior-learned route or a generated default
route a Type 1 metric.

I suggest you don't use this knob unless you really need
it.  If you simply want to have a number of routers
homed to differing ISPs, then use Type 2 metrics.

You'll also need to look up "backdoor route" for your
BGP configuration.

I'm sorry about the state of the Zebra documentation.
It could be a lot better at explaining routing concepts
and sane use of the routing protocols, and I hope one
day to find the time to do that 

In the mean time, I'd suggest a good book on the
routing protocol (Halibi for BGP, Moy for OSPF)
and the Cisco documentation.

--

-- 
  Glen Turner                (08) 8303 3936 or +61 8 8303 3936
  Australian Academic and Research Network   www.aarnet.edu.au

[zebra 17516] I need some help