[pmacct-discussion] src_as_path finding

[Markus Weber]

Hi Paolo (and others),

nfacctd: am I correct that src_as_path is filled in by looking
up best path for src_ip in the agent's associated RIB and then
use that one?

If so then src_as_path would be wrong for asymmetric traffic
(as stated in the documents) e.g. if traffic on PE comes in
from peer A, but reverse path is preferred for peer B (or via
iBGP).

However, with ADD-PATH the "more likely" correct src_as_path
might be in the RIB.

Naive as I am I would think that a map like (similar to other
src maps e.g MED, local pref, peer)

  ip_src_bgpnexthop=<NH or list of NHs> id=<PE> in=<IngressIf>

could hint the src_as_path lookup by using ip_src_bgpnexthop for
NF packets received from PE ingressing on IngressIf to find a
RIB entry with a matching NH.

True, there would be only a benefit for ADD-PATH, mostly only
for the first AS (as everything behind remains pure guessing),
the ip_src_bgpnexthop would have to be multiple IPs (e.g. v4 & v6),
multi-point links (like IX) without src_mac (another possible
match field) are still "pure luck to get it right" and the case
"what to do" and "how to mark" if no match is found (or multiple
matches) is another question (*).

How hard do you think would it be (and I fear this goes beyond
my *current* understanding of the code ...) to implement this?

Or is that just a stupid useless idea?

Cheers,
Markus


(*) It would be nice also to have some kind of optional flag if
lookup was successful and src_as_path lookup is most likely
"symmetric" or not; and fallback to current behavior ...

[Paolo Lucente]

Hi Markus,

You are indeed right about the status quo of src_as_path. If you see,
there is a bgp_peer_src_as_type that can be set to 'map' and a
bgp_peer_src_as_map that allows to provide a map very similar to what
you described:

https://github.com/pmacct/pmacct/blob/1.7.1/examples/peers.map.example

See the input interface, the bgp_nexthop (RPF), potentially src_mac and
vlan (if vendors would dare one day to support these in NetFlow/IPFIX
for kits they sell to SPs - or if using sFlow) knobs. What this will
return is a peer source ASN instead of the full AS-PATH: would you like
to experiment / PoC and, if happy enough, we can build an equivalent
feature - with all the obvious disclaimers possible to inform about
otential inaccuracy - for AS-PATH? How does it sound?

Paolo

Post by Markus Weber
Hi Paolo (and others),
nfacctd: am I correct that src_as_path is filled in by looking
up best path for src_ip in the agent's associated RIB and then
use that one?
If so then src_as_path would be wrong for asymmetric traffic
(as stated in the documents) e.g. if traffic on PE comes in
from peer A, but reverse path is preferred for peer B (or via
iBGP).
However, with ADD-PATH the "more likely" correct src_as_path
might be in the RIB.
Naive as I am I would think that a map like (similar to other
src maps e.g MED, local pref, peer)
  ip_src_bgpnexthop=<NH or list of NHs> id=<PE> in=<IngressIf>
could hint the src_as_path lookup by using ip_src_bgpnexthop for
NF packets received from PE ingressing on IngressIf to find a
RIB entry with a matching NH.
True, there would be only a benefit for ADD-PATH, mostly only
for the first AS (as everything behind remains pure guessing),
the ip_src_bgpnexthop would have to be multiple IPs (e.g. v4 & v6),
multi-point links (like IX) without src_mac (another possible
match field) are still "pure luck to get it right" and the case
"what to do" and "how to mark" if no match is found (or multiple
matches) is another question (*).
How hard do you think would it be (and I fear this goes beyond
my *current* understanding of the code ...) to implement this?
Or is that just a stupid useless idea?
Cheers,
Markus
(*) It would be nice also to have some kind of optional flag if
lookup was successful and src_as_path lookup is most likely
"symmetric" or not; and fallback to current behavior ...
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

[Markus Weber]

Hi Paolo,

guess you remember who introduced here pmacct and with it the use
of the peer maps, don't you? If not - do I have to get concerned?

What you outlined sounds great but I must admit my understanding
of the code is (not yet) sufficient to even start to work on this
(neither on my own nor guided). I know you love contributions ...

Further I would suggest to first outline the "function" of such a
feature in more detail, the side effects, corner cases and alike
and maybe evaluate if such a feature is of much use at all to have
it in the code base.

It certainly may improve the src_as_path quality, but everything
beyond the adjacent AS remains still pure guessing.
So while bgp_peer_src_as_map is great for private interconnects to
ensure correct adjacent peer AS and to some extend for IXes (works
often better than expected), src_as_path comes with a significant
higher uncertainty.

OTOH, what we observe now is often mismatches of src_as_path's first
AS and forced set bgp_peer_src_as via peer.maps (with asymmetric
traffic). Something which could be marked during post-processing
step, but if quality could be here improved upfront, it's always
good ...

I'll try to find some time in the next weeks and maybe we can
talk about it at NLNOG - if not earlier, but I doubt I'll be much
further then.

Best regards,
Markus

Post by Paolo Lucente
Hi Markus,
You are indeed right about the status quo of src_as_path. If you see,
there is a bgp_peer_src_as_type that can be set to 'map' and a
bgp_peer_src_as_map that allows to provide a map very similar to what
https://github.com/pmacct/pmacct/blob/1.7.1/examples/peers.map.example
See the input interface, the bgp_nexthop (RPF), potentially src_mac and
vlan (if vendors would dare one day to support these in NetFlow/IPFIX
for kits they sell to SPs - or if using sFlow) knobs. What this will
return is a peer source ASN instead of the full AS-PATH: would you like
to experiment / PoC and, if happy enough, we can build an equivalent
feature - with all the obvious disclaimers possible to inform about
otential inaccuracy - for AS-PATH? How does it sound?
Paolo

Post by Markus Weber
Hi Paolo (and others),
nfacctd: am I correct that src_as_path is filled in by looking
up best path for src_ip in the agent's associated RIB and then
use that one?
If so then src_as_path would be wrong for asymmetric traffic
(as stated in the documents) e.g. if traffic on PE comes in
from peer A, but reverse path is preferred for peer B (or via
iBGP).
However, with ADD-PATH the "more likely" correct src_as_path
might be in the RIB.
Naive as I am I would think that a map like (similar to other
src maps e.g MED, local pref, peer)
  ip_src_bgpnexthop=<NH or list of NHs> id=<PE> in=<IngressIf>
could hint the src_as_path lookup by using ip_src_bgpnexthop for
NF packets received from PE ingressing on IngressIf to find a
RIB entry with a matching NH.
True, there would be only a benefit for ADD-PATH, mostly only
for the first AS (as everything behind remains pure guessing),
the ip_src_bgpnexthop would have to be multiple IPs (e.g. v4 & v6),
multi-point links (like IX) without src_mac (another possible
match field) are still "pure luck to get it right" and the case
"what to do" and "how to mark" if no match is found (or multiple
matches) is another question (*).
How hard do you think would it be (and I fear this goes beyond
my *current* understanding of the code ...) to implement this?
Or is that just a stupid useless idea?
Cheers,
Markus
(*) It would be nice also to have some kind of optional flag if
lookup was successful and src_as_path lookup is most likely
"symmetric" or not; and fallback to current behavior ...
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

[Paolo Lucente]

Hi Markus,

:-D

I like the idea of discussing this at NLNOG to review: intended goals
(ie. why src_as_path is important at all) and how the current feature
works and if/how it can help. Entirely agree with your point "but if
quality could be here improved upfront, it's always good".

Look forward!

Paolo

Post by Markus Weber
Hi Paolo,
guess you remember who introduced here pmacct and with it the use
of the peer maps, don't you? If not - do I have to get concerned?
What you outlined sounds great but I must admit my understanding
of the code is (not yet) sufficient to even start to work on this
(neither on my own nor guided). I know you love contributions ...
Further I would suggest to first outline the "function" of such a
feature in more detail, the side effects, corner cases and alike
and maybe evaluate if such a feature is of much use at all to have
it in the code base.
It certainly may improve the src_as_path quality, but everything
beyond the adjacent AS remains still pure guessing.
So while bgp_peer_src_as_map is great for private interconnects to
ensure correct adjacent peer AS and to some extend for IXes (works
often better than expected), src_as_path comes with a significant
higher uncertainty.
OTOH, what we observe now is often mismatches of src_as_path's first
AS and forced set bgp_peer_src_as via peer.maps (with asymmetric
traffic). Something which could be marked during post-processing
step, but if quality could be here improved upfront, it's always
good ...
I'll try to find some time in the next weeks and maybe we can
talk about it at NLNOG - if not earlier, but I doubt I'll be much
further then.
Best regards,
Markus

Post by Paolo Lucente
Hi Markus,
You are indeed right about the status quo of src_as_path. If you see,
there is a bgp_peer_src_as_type that can be set to 'map' and a
bgp_peer_src_as_map that allows to provide a map very similar to what
https://github.com/pmacct/pmacct/blob/1.7.1/examples/peers.map.example
See the input interface, the bgp_nexthop (RPF), potentially src_mac and
vlan (if vendors would dare one day to support these in NetFlow/IPFIX
for kits they sell to SPs - or if using sFlow) knobs. What this will
return is a peer source ASN instead of the full AS-PATH: would you like
to experiment / PoC and, if happy enough, we can build an equivalent
feature - with all the obvious disclaimers possible to inform about
otential inaccuracy - for AS-PATH? How does it sound?
Paolo

Post by Markus Weber
Hi Paolo (and others),
nfacctd: am I correct that src_as_path is filled in by looking
up best path for src_ip in the agent's associated RIB and then
use that one?
If so then src_as_path would be wrong for asymmetric traffic
(as stated in the documents) e.g. if traffic on PE comes in
from peer A, but reverse path is preferred for peer B (or via
iBGP).
However, with ADD-PATH the "more likely" correct src_as_path
might be in the RIB.
Naive as I am I would think that a map like (similar to other
src maps e.g MED, local pref, peer)
  ip_src_bgpnexthop=<NH or list of NHs> id=<PE> in=<IngressIf>
could hint the src_as_path lookup by using ip_src_bgpnexthop for
NF packets received from PE ingressing on IngressIf to find a
RIB entry with a matching NH.
True, there would be only a benefit for ADD-PATH, mostly only
for the first AS (as everything behind remains pure guessing),
the ip_src_bgpnexthop would have to be multiple IPs (e.g. v4 & v6),
multi-point links (like IX) without src_mac (another possible
match field) are still "pure luck to get it right" and the case
"what to do" and "how to mark" if no match is found (or multiple
matches) is another question (*).
How hard do you think would it be (and I fear this goes beyond
my *current* understanding of the code ...) to implement this?
Or is that just a stupid useless idea?
Cheers,
Markus
(*) It would be nice also to have some kind of optional flag if
lookup was successful and src_as_path lookup is most likely
"symmetric" or not; and fallback to current behavior ...
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists