> 

----- Original Message ----
From: Andrew Mabe <[EMAIL PROTECTED]>
To: jay alvarez <[EMAIL PROTECTED]>
Sent: Saturday, February 3, 2007 4:19:56 AM
Subject: Re: [Flow-tools] multiple routers with scattered upstreams (another 
adventures of duplicate flows..)

> what are the routing protocols in this diagram.  Do you talk BGP to  
> client_router?

Client router doesn't talk BGP to us


> I assume you are talking BGP with your ISP A-D, is that correct?

Exactly!



> What types of routers are each router and what is core switch?
Router 1 I guess is a juniper M20, Router 2 and 3 are Cisco, or I might be 
mistaken, I'll still need to confirm this to the network guys. But will it 
matter? The switch is a cisco catalyst, not sure of the exact model.


> How much traffic / how many flows are you passing to client_router?
You are talking about the incoming traffic via ISP A-D going to client's subnet 
right?
We are still doing some configuration changes that is why ISP A-D interfaces 
aren't netflow enabled yet. Why do we need to find this out?


Lastly, what I am worried is not being able to filter out traffic going in and 
out to the client's subnet as I am thinking I can do it by, first with outgoing 
traffic by having a filter that consists of exporter_ip, source-ip, output 
interface, and for incoming, exporter_ip, input_interface, destination-ip. What 
I am worried is receiving duplicate flows, because to be able to filter out 
outgoing traffic via ISP A and B, I will have to enable sensors on either of 
the three routerA's interfaces facing routerB. But by doing so, when a traffic 
origination from the client enters routerB, a flow will be recorded.. Then 
another flow will be recorded if it has been routed to routerA to be delivered 
to ISP A and B. 

The worry comes when using a flowscan reporting module, e.g; CUFlow. In CUFlow, 
I can specify the subnet I want to measure the traffic. But how can I trim down 
the flows that have been recorded or exported twice. If I will disable the 
sensor on routerB's interface where the client's traffic enter first, I will 
not be able to record flows which are routed into ISP C.


On Jan 31, 2007, at 10:54 PM, jay alvarez wrote:

>
> 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
> <diagram.jpg>
> _______________________________________________
> Flow-tools mailing list
> [EMAIL PROTECTED]
> http://mailman.splintered.net/mailman/listinfo/flow-tools






 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
_______________________________________________
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools

Reply via email to