Hi Paolo,
On 30 Οκτ 2009, at 12:26 ΠΜ, Paolo Lucente wrote:
On Thu, Oct 29, 2009 at 10:09:16AM +0200, Zenon Mousmoulas wrote:
BGP RIB lookups. However, for traffic flowing from sources behind
that path (inbound for us), how would one go about doing just that?
[ ... ]
This is quite similar in concept to the mechanics of calculating the
source peer AS: an RPF lookup would be required again, which should
return the AS-path instead of the next-hop. Of course once again we
have the assumption that routing is symmetric, which however in
internet environments is far from the truth, but it's still better
than nothing. How difficult would it be to implement this so that we
could have a src_as_path aggregation primitive?
Implementing a trivial src_as_path is quick and easy ... but is that
any useful? It's something non-deterministic and it's also not always
possible to infer whether it's correct or pure rubbish. When i posed
myself that question some time ago, i thought that even if a trivial
implementation takes just a couple of hours, bottom line it's time
wasted.
In general I agree with you that src_as_path is mostly an educated
guess of the RPF path. However I think it is conceptually possible to
determine when this theoretical path and the actual path are not
congruent, since we are in a position to know the ingress point
(router and interface) for the flow (depending also on the aggregation
scheme of the netflow feed). So, after looking up the BGP next-hop, it
should be possible to look up if this peer matches the ingress
interface (provided the flow record is indeed exported by this peering
router) and only then record the src_as_path. I am fully aware this
description sounds a lot easier than the actual implementation would
be, however I believe it should be feasible at some point. Until then,
however, I believe it would do no harm to have the option to record a
'naive' src_as_path.
I guess on a topic like "src_as_path" there is margin for a study,
some research or at least some ample discussion maybe bringing in
further interested people (coming from the NREN world, you perhaps
can think of somebody at this propo?) with the goal of coming up
with something clever.
In principle I would say that people with an NREN background, such as
myself, would probably not have much to contribute to such a
discussion, because NRENs, unlike commercial operators, seldom need to
be involved in complex, heavy inter-domain traffic engineering with
BGP. Nonetheless I could invite to the discussion some colleagues who
have more experience on the topic than I do.
Recently, for example, having spoken to somebody on similar topics
i started wondering if further information about ingress traffic is
better inferred from the network itself (say: BGP, NetFlow, TTL
values, etc.), from out-of-band data (say: AS macros, RIPE data,
etc.) which would be all part of a map or a mix of the two.
Even though I am not an expert on the matter, as stated previously, I
would probably agree about the value of such "out-of-band" data.
However, judging from the little I know about RPSL, I think this would
bring along too much implementation and processing complexity for
software like pmacct, which should remain focused on performance
optimization. Therefore I feel it could be better suited for
delegation to external software, such as a policy daemon, that could
accept and respond to queries from pmacct through a simple interface/
protocol.
In any case we should keep in mind that such data may either not be
always available, for a number of reasons, or some times may be
impossible to model in a uniform way. I would actually argue that at
present this could be true for the majority of cases (meaning that for
most networks such information is not published at all or is published
inconsistently).
Best regards,
Z.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
