LINX Technical News

1
LINX Technical News

• Mike Hughes
• ltmike_at_linx.netgt

2
Agenda

• Quick overview of peering networks
• Multicast developments
• sFlow data collection and tools

3
Network Overview

• Two matched redundant networks
• One using Foundry equipment
• Other using Extreme equipment
• Nx10G multi-ring core network
• Network maintenance programmed on a single
  platform at a time
• Should provide very high availability
• Switched traffic now 120Gb/sec
• Not including PI traffic

4
Network Upgrades in 2006

• We upgraded both platforms in 2006
• Completed upgrade of Extreme Network
• Replacing older BD6800 series with BD8800
• From 8G/slot to 40G/slot
• Also upgraded Foundry network
• Adding RX-16 systems (40G/slot)
• Both networks multi-ring reconfigured

5
Foundry Network
6
Extreme Network
7
Multicast Developments

• Things had been flat in this area for a long
  while
• However, renewed interest from BBC and others
  caused a surge in multicast traffic

8
Projected traffic growth gt 120Mb

• Bogons
• 40 tv channels
• 40 more to come
• BBC
• 5 main channels _at_ 360k, 360K, 1.2M, 5M
• 1 HD channel at 20M
• 5 itv at various rates up to 2M
• a load (12) of other channels at 3 - 5M
• Other new members joining
• Example Global MIX

9
Old Situation Ancient kit and no PIM snooping

• BBC were sending 40Mb/s. Finally some use for
  multicast!
• mcast4500 only had 10Mb interface on exchange,
  ensuing neighbor messages and session drops not
  considered fun.
• Some members slightly concerned about 40Mb
  turning up completely unsolicited on their
  interfaces.

10
Action taken

• Replace 4500 with 7200vxr with gig interface
• Implement PIM-snooping on Foundry LAN.

ip multicast passive ip pimsm-snooping
11
Impact of PIM-snooping
12
Foundry related PIM commands
The first graph is a multicast sender on the
network, the second a receiver. Thats literally
all we had to go on before enabling pim snooping.
We now have show ip multicast to assist us in
getting more specific information on the
multicast traffic.
13
Output from show ip multicast

• Switch1 (multicast sender)
• IP multicast snooping is enabled - Passive
• IP pimsm snooping is enabled
• VLAN ID 6
• Active 195.66.230.53 Router ports 2/1 16/1
  12/1 3/14 3/6
• Report FID 0x0405
• Number of Multicast Groups 5
• 1 Group 239.255.255.255
• IGMP report ports 2/1
• Mapped mac address 0100.5e7f.ffff Fid
  0x040b
• PIMv2 G join ports
• 2 Group 224.0.1.40
• IGMP report ports 2/1 12/1
• Mapped mac address 0100.5e00.0128 Fid
  0x040c
• PIMv2 G join ports

• Switch8 (multicast receiver)
• IP multicast snooping is enabled - Passive
• IP pimsm snooping is enabled
• VLAN ID 6
• Active 195.66.230.12 Router ports 13/7 2/1
  13/9 13/2 11/21 11/6 11/19 13/3
• 7/1
• Report FID 0x0403
• Number of Multicast Groups 5
• 1 Group 224.0.1.40
• IGMP report ports 2/1
• Mapped mac address 0100.5e00.0128 Fid
  0x040a
• PIMv2 G join ports
• 2 Group 239.255.255.255
• IGMP report ports 2/1
• Mapped mac address 0100.5e7f.ffff Fid
  0x0410
• PIMv2 G join ports

14
Advantages from PIM Snooping

• Gives us greater insight into exactly whats going
  on.
• Assists in troubleshooting problems members have
  on the exchange.
• Possibility of a looking glass for members to do
  their own diagnosis.

15
sFlow Tools

• Were currently collecting sFlow data from the
  switches
• Massive amounts of data
• Lack of free/suitable open-source tools
• Need to build things yourself
• Challenges in data storage and retrieval
• Are there issues with data retention?

16
sFlow Member Requests

• Obvious application member-to-member
  (MAC-to-MAC) MRTG-like flow graphs
• A beta of this already available
• Issues with sampling rate and data archiving
• Send a filtered sFlow stream to members so they
  can process it themselves
• Build an sFlow distributor
• Take apart, sort and re-assemble sFlow datagrams

17
sFlow Other Uses

• A real peering matrix
• Based on observation rather than declaration
• Milan exchange is now doing this
• SPAM/Attack detection
• e.g. SpamHINTS project
• Providing filtered interesting only data
• Suitably anonymised
• Possible to detect other miscreant activity?

18
sFlow Non-tech Issues

• User privacy/anonymity
• Its already sampled (1/8k, 1/2k pkts), so likely
  impossible to reconstruct a conversation
• Possible to strip out interesting data and
  throw the rest away
• AMS-IX approach keeps only mac and ethertype
• Operator privacy
• Does an sFlow generated peering matrix breach
  peering NDAs? Fixable with opt-outs?

19
Organisational

• Nothing much changes still mutual, non-profit
• Will be strengthening our engineering team which
  supports members in the new year
• Will move London office in Q1 07
• More space, better layout
• Better lab (really important!)

20
Questions?