Subject: RE: Still unclear
From: Jason Lixfeld (jlixfeld@team.look.ca)
Date: Sun Dec 03 2000 - 13:03:44 CST
Andrew, what do you consider peering? Do you consider peering as the
connection from one ISP to another or do you consider peering as the
connection from one ISP to the same ISP or do you consider peering as both?
The way I have flow switching turn on inside my network (so shrink the size
of the files) is as follows (interfaces with "f" denote flow switching
enabled):
ISP 1 --------f RTR 1 f-------f RTR 2 -------------- LAN 2
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
ISP 2 --------f RTR 3 f-------f RTR 4 -------------- LAN 1
f
|
|
|
|
ISP 3
So, as you can see, I have flow switching turned on between some links to
some routers but not all links to all routers. This was done to shrink the
filesize, but at the same time, you can see how there could be some problems
were some traffic would not be logged for example if a packet from LAN 1 or
LAN 2 wanted to exit to ISP3 via RTR 4. The only interaces that has flow
switching enabled is the local end of the link connecting to ISP 3. This
will only catch traffic coming from ISP 3 to our network though. In drawing
this, I realize that I have to turn flow switing on more interfaces, but now
the problem is that the files are going to be too large to be able to be
parsed in the 5 minutes between cflowd runs. After this email, I will turn
flow switching on between RTR 1 and RTR 3 and between RTR 2 and RTR 4.
What I'm wondering, if it's possible to speed up things if flowscan can be
re-written or modified to only care about information from ASPairs as
configured in CampusIO.cf? That's what I'm concerned about now more than
anything. I don't care about anything but the amount of total traffic I am
sending out or recieving from a particular AS.
Dave, is there anything that can be done about this?
-----Original Message-----
From: Andrew Fort
To: 'Jason Lixfeld'; 'flowscan@net.doit.wisc.edu'
Sent: 29/11/00 5:24 PM
Subject: RE: Still unclear
Jason, I think it's due to the topology involved. From your network, if
we
take the case of one border instance (one "peer"), how is data for both
directions actually collected; from your diagram, and your comments that
you
dont get export data from the border interfaces, it would appear you're
logging the peering interfaces on two routers.
Can you show one setup of the peering with addresses and stuff to show
where
you're gathering the data from?
-----Original Message-----
From: Jason Lixfeld [mailto:jlixfeld@team.look.ca]
Sent: Thursday, 30 November 2000 03:51
To: 'flowscan@net.doit.wisc.edu'
Subject: Still unclear
Well, I got the flow files down small enough that there is only a
backlog of
one file instead of 10-15. Thanks to everyone for their help. I'm
still
curious though as to why I would be seeing only one-way traffic from
RRGrapher.cgi. I'm not sure if the problem could be with RRGrapher or
the
flow files but I'd like to try to get it nailed.
Any insight?
--
Help mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe flowscan" in message body
Archive http://net.doit.wisc.edu/~plonka/list/flowscan/archive/
------------------------------------------------------------------------
-
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info:
www.mailshield.com
--
Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe flowscan" in message body
Archive http://net.doit.wisc.edu/~plonka/list/flowscan/archive/
This archive was generated by hypermail 2b25 : Sun Dec 03 2000 - 13:05:52 CST