Mailing List Archive: Cisco: NSP

netflow not recording correct origin-as

Index | Next | Previous | View Threaded

spork at bway

Jun 13, 2012, 9:28 PM

Post #1 of 4 (368 views)
Permalink

netflow not recording correct origin-as

It's been a very long time since I touched netflow, but I recently
installed FlowViewer since I wanted to grab some stats (we collect
netflow data, but don't do much with it) since we are transit
shopping. Thought it would be interesting to see, for example how
much traffic ends up somewhere like cogent to see if it's worth
throwing them in the mix.

After digging up from FlowViewer to "sh ip cache verbose flow", I'm
starting to think either I totally misunderstood how this works or
there's something wonky with IOS. We have our own AS and we have
transit to HE.net and Level3. If I run any report in flow-tools or
flowviewer that shows source/destination AS counts, it shows about
99% of my traffic with a source or destination AS of 3356. This is
obviously not true - traffic graphs show that we run about 2/3
inbound from HE. When I look at the src/dst AS in "sh ip cache
verbose flow", I see the same thing. Here's a single line showing
what I believe is incorrect AS info:

SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts
Port Msk AS Port Msk AS NextHop B/Pk Active

Fa2/0 86.21.123.0 AT3/0.2535 216.220.114.xxx 06 00 02 2
E055 /0 3356 2D3D /32 0 216.220.114.xxx 52 2.9

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.

I'm on a 7206 w/an NPE-G2. IOS 12.4(24)T6.

Both transit links have "ip flow ingress" and "ip flow egress". I
also started with just ingress on those interfaces as well as an ATM
OC-3 interface and another GigE port, but the ATM interface did not
seem to be grabbing flows from the subinterfaces. My AS problem is
the same with either configuration.

My export config is this:

ip flow-export source Loopback0
ip flow-export version 5 origin-as
ip flow-export destination 216.220.107.41 9800
ip flow-top-talkers
top 40
sort-by packets

Am I doing something obviously wrong here?

Thanks,

Charles
--
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
spork [at] bway - 212.655.9344

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

gert at greenie

Jun 14, 2012, 1:16 AM

Post #2 of 4 (331 views)
Permalink

Re: netflow not recording correct origin-as [In reply to]

Hi,

On Thu, Jun 14, 2012 at 12:28:35AM -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.

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".

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net

spork at bway

Jun 14, 2012, 1:47 AM

Post #3 of 4 (330 views)
Permalink

Re: netflow not recording correct origin-as [In reply to]

On Jun 14, 2012, at 4:16 AM, Gert Doering wrote:

> Hi,
>
> On Thu, Jun 14, 2012 at 12:28:35AM -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?

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

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

Thanks so much, I really appreciate the answers and the explanation.

Charles

> gert
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany gert [at] greenie
> fax: +49-89-35655025 gert [at] net

--
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
spork [at] bway - 212.982.9800

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

gert at greenie

Jun 14, 2012, 2:01 AM

Post #4 of 4 (328 views)
Permalink

Re: netflow not recording correct origin-as [In reply to]

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
fax: +49-89-35655025 gert [at] net

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads