[c-nsp] netflow not recording correct origin-as

[Gert Doering]

Hi,

On Thu, Jun 14, 2012 at 04:47:49AM -0400, Charles Sprickman wrote:
> >> That's a flow from 86.21.123.0 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 
results...

> > 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
> 1715914532
>       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
> go.

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!)...

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20120614/2624a250/attachment.sig>