Mailing List Archive

bgpd mrt dump received
more from hasso's marc-trawling:

http://marc.theaimsgroup.com/?l=zebra&m=102588991031606&w=4

expands the mrt bgp dump commands..

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Since aerosols are forbidden, the police are using roll-on Mace!
Re: bgpd mrt dump received [ In reply to ]
Hi -

Here are some somewhat newer versions of diffs I have previously sent in
to the zebra list. These are against 0.92a of bgpd, as I have yet to move
on to anything newer. Clearly not all of these are useful for general
consumption, but given the GPL, I would like these published in a place
like this, so as to be in compliance with provide all code changes.

- Marc

On Mon, 4 Aug 2003, Paul Jakma wrote:

> more from hasso's marc-trawling:
>
> http://marc.theaimsgroup.com/?l=zebra&m=102588991031606&w=4
>
> expands the mrt bgp dump commands..
>
> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Since aerosols are forbidden, the police are using roll-on Mace!
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>
Re: bgpd mrt dump received [ In reply to ]
On Mon, 4 Aug 2003, Marc Evans wrote:

> Hi -
>
> Here are some somewhat newer versions of diffs I have previously
> sent in to the zebra list.

very interesting.

> These are against 0.92a of bgpd, as I have yet to move on to
> anything newer.

Would you be interested in trying out quagga? :)

Btw, i think your zebra.hash.diff was accepted into zebra.org CVS.

> Clearly not all of these are useful for general consumption,

could you explain the prefix splitting patches?

Also, there appears to be some work on speeding up prefix matching,
ie in the zebra.aspath.diff diff. Might it be an idea to unify the
prefix bit check (and attendent table, which is duplicated in
bgpd/bgp_table.c) to a macro in lib/prefix.h? or even better, just
speed up the existing prefix_ functions using table lookups. Modern
processors seem to prefer tight functions over inlined code.

Finally, the aspath patch adds some new files, eg bgp_neighbor.{c,h}
and bgp_origin.{c,h}. These are marked as copyright Kunihiro Ishiguro
(1999) and John Shriver (2002) - can you comment more on that?

> but given the GPL, I would like these published in a place like
> this, so as to be in compliance with provide all code changes.

Very interesting. thanks.

> - Marc

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The reason that every major university maintains a department of
mathematics is that it's cheaper than institutionalizing all those people.
Re: bgpd mrt dump received [ In reply to ]
On Mon, 4 Aug 2003, Paul Jakma wrote:

> On Mon, 4 Aug 2003, Marc Evans wrote:
>
> Would you be interested in trying out quagga? :)

Yes, I will be watching its development and will likely experiment with it
over time.

> Btw, i think your zebra.hash.diff was accepted into zebra.org CVS.

Yes, I think some form of it was included.

> > Clearly not all of these are useful for general consumption,
>
> could you explain the prefix splitting patches?

Well, it is useful for doing experimentation with breaking the BGP spec
(yikes!). The idea is that for prefixes that we hear, combined with other
selection filters, we then re-announce them back into the iBGP mesh. This
is most useful for research purposes, but probably very unwise for
production use.

> Also, there appears to be some work on speeding up prefix matching,
> ie in the zebra.aspath.diff diff. Might it be an idea to unify the
> prefix bit check (and attendent table, which is duplicated in
> bgpd/bgp_table.c) to a macro in lib/prefix.h? or even better, just
> speed up the existing prefix_ functions using table lookups. Modern
> processors seem to prefer tight functions over inlined code.

Yes, I found the regex code to be incredibly inefficient, and therefore
crafted this code which was far less cpu intense. I do believe that it
could be useful, or some variation as you suggest, to general users, such
that many filters that I see are looking for a specific source or transit
provider.

> Finally, the aspath patch adds some new files, eg bgp_neighbor.{c,h}
> and bgp_origin.{c,h}. These are marked as copyright Kunihiro Ishiguro
> (1999) and John Shriver (2002) - can you comment more on that?

John Shriver works with me. I can have him confirm this if you would like.
The Kunihiro reference is because we used his code as a template, removing
and changing it as needed.

> > but given the GPL, I would like these published in a place like
> > this, so as to be in compliance with providing all code changes.
>
> Very interesting. thanks.

NP. I'd hate to see these lost or moth balled, if they might be useful to
other users.

- Marc