gert at greenie
Jun 14, 2012, 2:01 AM
Post #4 of 4
Re: netflow not recording correct origin-as
[In reply to]
On Thu, Jun 14, 2012 at 04:47:49AM -0400, Charles Sprickman wrote:
> >> That's a flow from 220.127.116.11 which is AS 5089 to one of our
> >> customers. Fa2/0 is HE.net. So not only is this flow not sourced
> >> from AS3356, it's not even coming in via our transit link to 3356.
> >> This seems totally wrong.
> > Flows source AS numbers are not mapped by inbound interface or whatever,
> > but by mapping of the source address to BGP-bestpath. So if you would
> > send outbound packets to that IP address to 3356, that's the AS number
> > you'd see.
> Thanks, that's very helpful.
> Is the current config that collects ingress and egress on the
> transit links the current best practice for this or should I revert
> to ingress-only on all the interfaces that I care about?
I think that very much depends on topology. We use ingress-only, but
on all interfaces - so every flow is seen. If your topology is simple
enough and your hardware can do that (egress is "sort of new"), using
ingress+egress on the upstream interfaces should give the very same
> > As for "why do you see AS 3356 in the flow records if the traffic does
> > not end in 3356" - do you, by change, have an incomplete BGP table plus
> > a default route coming in from 3356? In that case, everything matched
> > by the default route would be "3356".
> Please don't think I'm a total idiot, but I thought we did have full
> routes. We do not. Back before we dropped in the NPE-G2 we had an
> NPE-300. IIRC, we ran into both memory issues as well as some cpu
> issues whenever bgp dropped and came back from one of the providers.
> On the Level3 side I believe I'm simply filtering out everything but
> default and on the HE side they are sending customer routes only.
Heh :-) - it certainly smelled like that. (The other option would have
been netflow being set to "peer-as", but you had that right)
> If you'd humor me for a moment, I'd appreciate it. Here's our
> current memory situation:
> Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
> Processor 6B934E0 1883686692 151092916 1732593776 1698819632
> I/O 78000000 67108864 8825864 58283000 58056480 58227804
> Transient 77000000 16777216 143752 16633464 14181572 16584768
> Would a full table from both transit providers (with soft reconfig
> enabled) fit comfortably in that amount of memory or not?
I've not run a full table for a while (we filter all /23+/24 from
other regions), so we only have about 340k entries right now. Those
fit comfortably into a NPE-G1:
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 63539C40 934044380 339686128 594358252 589054872 380396252
... with 594 Mb free, out of a total of 1G. Full 450k routes should
take about 20% more RAM "or so", so that would still be easily done.
Your NPE-G2 seems to have 2G, so I would not expect any issues here.
> I would like to get better reporting on what our top ASes are, but I
> don't want to push this thing over the edge to do it. I'm also
> feeling a bit better about HE.net these days and would not mind
> pushing more outbound traffic their way. And in the coming months
> we may be adding more transit from a third or fourth provider and it
> might be best to let bgp make decisions about where traffic should
What I did at another customers' site for a while is to permit only
AS paths up to a path length of 2 - so you get "direct peers of your
upstreams", but not "all the rest of the world". This was something
like 20.000 prefixes, so it's a very limited view (made sense in this
specific situation because all the traffic went to customers in the
same market). You could experiment with as path lenghts of 3 or 4,
and see whether this will give you enough fine-grained visibility...
... or filter out all /23+/24s (but keep a default route!)...
USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net