Flow-based Traffic Accounting at SWITCH Simon Leinen Team Leader LAN, SWITCH

advertisement
ITU-T Workshop on
IP Traffic Flow Measurement
(Geneva, Switzerland, 24 March 2011)
Flow-based Traffic Accounting at
SWITCH
Simon Leinen
Team Leader LAN, SWITCH
Geneva, 24 March 2011
About SWITCH
National Research and Education Network
(NREN) for Switzerland
Provide Internet(1+2) to universities
One of the first Swiss ISPs
Fiber-based since 2001
Operates C/DWDM, routers, peerings
Upstreams in Geneva and Zurich
Peerings in Geneva, Zurich, Amsterdam
Total ext. traffic levels: 10-20 Gb/s
Geneva, 24 March 2011
2
How SWITCH uses Netflow data
Volume-based charging
Traffic planning for peering & transit
Security - early warnings, forensics
To support research (ETHZ EE-CSG)
Geneva, 24 March 2011
3
Volume-based charging at SWITCH
Principle mandated by foundation:
Costs recovery must distribute
charges according to costs caused!
Implementation: Volume charges
In addition to fee components based on:
Access capacity
Access type (redundant/non-redundant)
Headcount
Value-added services
Geneva, 24 March 2011
4
Volume Charges: First Attempt
Early model: count (using SNMP)
bytes crossing SWITCHsite i/f
only in that direction - outbound is free!
Unwanted customer reactions:
Reduce cheap local traffic (e.g. USENET)
Build back-door connections between
universities
Fear of new services such as multicast
Geneva, 24 March 2011
New model (since 1998)
Only off-net traffic is charged
Still inbound-only, i.e. Internetsite
Research traffic (e.g GÉANT) exempt
Transit & commercial peerings charged
Initially: Only transatlantic traffic
Other intricacies
Nights (20-08 local) and weekends free
IPv6 currently free to encourage use
Geneva, 24 March 2011
6
“Fluxoscope” Accounting System
Consume (unsampled) flows from
border routers
Aggregate off-net flows online by:
Customer ID
Peer AS
Application (guessed from ports etc.)
Write statistics to files every 5 min
Post-process offline (bills, graphs, …)
Geneva, 24 March 2011
7
Why Unsampled?
Because our routers can do it
Hardware Netflow implementation
And they are bad at sampling
Billing might work with sampling
As long as sampling is random/unbiased
We charge large aggregates
Secondary applications are the
problem! (security, research)
Geneva, 24 March 2011
8
Issue: Cost/Performance
Performance of the underlying
measurement
even though our platform does Netflow
"in hardware”
too many flows  occasional acct. loss
router CPU overworked with flow export
Cost of processing data
Servers, licenses, storage, operations
Geneva, 24 March 2011
9
Accounting Load @~22Gb/s
Flows/s processed by Fluxoscope jobs
Geneva, 24 March 2011
Issue: Where does value accrue?
No idea who initiated a connection
At SWITCH, we charge the receiver
Questionable because sender controls
“Information creates value for receiver”
Not applicable to e.g. commercial
content providers
Geneva, 24 March 2011
Issue: Asymmetric Routing
On IXPs, not sure which neighbor AS
traffic really came from
Netflow includes “source AS” (peer or
origin), but these are derived from local
router’s routing tables
Geneva, 24 March 2011
Download