Hi,
Suppose I have this kind of setup:
ISP A ISP C local_dst
ISP D
\ | |
/
\ <-----> | |
/
routerA <------> routerB <--------->core_switch <--------> routerC
/ <-----> |
\
/ |
\
ISP B client_router
local_dst
Now, the goal is to record all flows incoming and outgoing the client's subnet,
and further determine on which ISP it came out and on which it came in, sort of
like what percentage of traffic of this client is going in/out through this
ISP etc, and do all the necessary rerouting tricks.
To further explain the above diagram:
routerA has 5 interfaces, two of which are connected to ISP A and ISP B (fe0,
fe1 respectively).
routerA also has these three redundant load-balanced links which connects it
to routerB. (via se0, se1, se2 respectively)
routerB is connected to routerA via the redundant load-balanced links (se3,
se4, se5 respectively)
routerB also has one interface connected to ISP C (fe2)
routerB has one interface connected to core_switch (se4)
client_router has one interface plugged also into core_switch(se5) (we don't
have control over the client's router)
routerC has one interface connected to ISP D (fe3)
routerC has one interface that connects it to core_switch(se6)
Now, to capture all the incoming traffic destined to client's subnet
(192.168.0.1/24) and determine on which ISP it went through, I will have to
enable netflow sensors on interfaces fe0, fe1 (routerA), fe2(routerB),
fe3(routerC)
Then create filter file with: exporter router, input interface,
ip-destination-address
The problem arises when the traffic is egressing the client's network.
The flow of the client's traffic will always be going through the core_switch
first, then to routerB's interface(se4).
When it reaches routerB's se4 interface, it has a choice of either:
1. Get out to routerB's fe2 interface and be delivered by ISP C.
2. Go back to the core_switch, still via routerB's se4 interface and then go to
the routerC's se6 and finally go out to routerC's fe3 to be delivered by ISP D
3. Lastly, when the traffic is already inside routerB, it can also go out to
one of the redundant load-balanced interfaces (se3, se4, se5) and then cross
routerA entering either of the three load-balanced links (se0, se1, se2) then
go out either routerA's fe0(ISP A) or fe1(ISP B)
So, the big question is: where will I put enable the netflow sensor to create
filter for client's outgoing traffic and differentiate them on which ISP it
went out without generating duplicate flow records. The only filter-definition
I can think of includes exporter_ip, output_interface, also perhaps source
subnet.
If I enable netflow sensor on routerB's se4 interface, I can create a filter
with: exporter_ip, output_interface for clientOUTviaISPC
Next, to catch outgoing traffic going out via ISP D, ISP A, ISP B, I'm really
lost on which router's interface I should enable the sensor.
Can you help me out on this one?
By the way, I was searching the archive for similar scenario and this is the
closest one I found.
http://mailman.splintered.net/pipermail/flow-tools/2005-May/002740.html
Although it didn't say anything about outgoing traffic and determining on which
ISP it came out but still preventing duplicate flows.
I'm thinking perhaps I should create the filter file for the outgoing using the
IP next hop, or the next hop AS or whatsoever.. And I will have to configure
our routers to export "peer-as"
Any brighter idea?
I hope the diagram above displays correctly in your email. I am composing this
on yahoo webmail. Anyway, I'm attaching a screenshot of
the diagram. Further, we might be interested in the future of all local traffic
from client's network going to local_dst. But as of now, we are only after the
traffic to and from that client's network via those upstream providers.
Thanks!
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail <<attachment: diagram.jpg>>
_______________________________________________ Flow-tools mailing list [EMAIL PROTECTED] http://mailman.splintered.net/mailman/listinfo/flow-tools
