Flow Monitoring Experiences at the Ethernet-Layer - Semantic Scholar

Flow Monitoring Experiences at the Ethernet-Layer Rick Hofstede, Idilio Drago, Anna Sperotto, Aiko Pras

Outline • • • • •

Introduction IPFIX for NGE Monitoring IPFIX Device Prototype Use Cases Conclusions

Flow Monitoring Experiences at the Ethernet-Layer September 6, 2011

2

Introduction NetFlow

• • •

Provides a summary of network activity at the IP-layer Overcomes scalability problems of packet-level capture NetFlow v5: fixed data structures, IPv4

• • •

Source/destination IP address, source/destination port, protocol, packets, octets, start/end time, TCP flags, type of service

NetFlow v9: templates, IPv6 Flexible NetFlow/IPFIX: allows user selection of flow keys and records


3

Introduction Carrier Ethernet

•

Backbone network operators are considering a Carrier Ethernet (NGE) deployment

• • • •

Operations, Administration & Maintenance (OAM) support Improved customer separation Smaller amount of MAC addresses in forwarding tables

How can we monitor a NGE network? SA DA VID C-VID S-VID I-SID B-VID B-SA B-DA

= = = = = = = = =

Source MAC address Destination MAC address VLAN ID Customer VID Service Provider VID Instance ID Backbone VID Backbone SA Backbone DA

IEEE 802.1ah (PBB) IEEE 802.1Qay (PBB-TE)

B-DA

B-SA

IEEE 802.1

DA

SA

Payload

DA

SA

VID

Payload

DA

SA

S-VID

C-VID

Payload

DA

SA

S-VID

C-VID

Payload

IEEE 802.1Q (VLAN) IEEE 802.1ad (PB) B-VID

I-SID


4

IPFIX for NGE Monitoring • •

• •

IPFIX Information Elements (IEs) have been defined by IANA IEs for (NG) Ethernet: sourceMacAddress

destinationMacAddress

ethernetHeaderLength

dot1qVlanId

dot1qCustomerVlanId

ethernetPayloadLength

dot1qPriority

dot1qCustomerPriority

ethernetType

metroEvcID

metroEvcType

IPFIX is flexible enough to cope with different formats Our goal: evaluate the use of IPFIX for NGE flow monitoring


5

IPFIX Device Prototype • • • •

Early-deployment equipment from INVEA-TECH was acquired Probes support IP flow export using NetFlow v5/v9/IPFIX FlowMon Probe platform is easily extensible by means of plugins INVEA-TECH developed a special Ethernet-plugin

• •

Allows Ethernet flow export

•

Native Ethernet flow export to be supported in the future

Expired flows (by active or inactive timeouts) are exported using NetFlow v9


6

IPFIX Device Prototype •

Advantages of presented early-deployment approach: 1. Existing flow processing algorithms can be reused 2. NetFlow collectors can be used, since no suitable IPFIX collectors are available (yet) 3. Existing monitoring tools can be reused


7

IPFIX Device Prototype • •

Hands-on experienced with NGE monitoring needs to be gained INVEA-TECH FlowMon Probes were deployed in the UT’s IEEE 802.1Q-based campus network

•

Devices need to be tested before being deployed in a serviceprovider network

•

UTnet carries 110 VLANs


8

Use Case 1 Traffic Profiling

All active layer-2+ can be monitored and profiled IPv4, IPv6, ARP, Novell IPX, LLDP, DECnet Phase IV protocols, Cisco WLAN Context Control Protocol, MPLS, ... 20k

20k

16k

16k

IPv6 flow records (per min.)

IPv4 flow records (per min.)

12k

8k

4k

0 0:00

4:00

8:00

12:00

16:00

20:00

12k

8k

4k

0 0:00

0:00

(a) IPv4 flow records 35G

35G

30G

30G

25G 20G 15G 10G 5G 0 0:00

4:00

8:00

12:00

16:00

20:00

0:00

20:00

0:00

(b) IPv6 flow records

IPv6 octets (per min.)

•

IPv4 octets (per min.)

•

25G 20G 15G 10G 5G

4:00

8:00

12:00

16:00

(c) IPv4 octets

20:00

0:00

0 0:00

4:00

8:00

12:00

16:00

(d) IPv6 octets

Fig. 3. Tra⇤c profiling for at IPv4 IPv6 Flow Monitoring Experiences theand Ethernet-Layer September 6, 2011

9

Use Case 2

Misconfiguration Detection

•

Cisco’s Catalyst 6500 platform has a DECnet Maintenance Operation Protocol (MOP) interface for management purposes

• •

Interfaces should have been disabled for some time already However, our setup found some DECnet Phase IV protocols traffic


10

Use Case 3

Device Misbehavior Detection (1) • •

Ethertypes are registered by IANA Two unknown ethertypes were detected: 0x8259 and 0x0A59

• •

UT IP ranges: 130.89.0.0/16 and 10.89.0.0/16

One of the data center switches in the UTnet was running on beta firmware

•

A bug in the ‘IGMP Snooping’ functionality was the cause of mangled packets

•

First two octets of the IP addresses were inserted in the ethertype fields


11

Use Case 4

Device Misbehavior Detection (2) •

A campus host with a malfunctioning network driver caused severe problems to the UTnet

• •

Huge amounts of ARP messages were generated Result: core-router almost collapsed 4M

55M

3M

ARP Octets (per min.)

ARP Octets (per min.)

50M

2M

1M

40M

30M 20M

10M 0 0:00

4:00

8:00

12:00

16:00

20:00

(a) ARP octets on March 28, 2011

0:00

0 0:00

4:00

8:00

12:00

16:00

20:00

0:00

(b) ARP octets on April 4, 2011

Fig. 5. Misbehaving host becomes security threat

5

Flow Monitoring Experiences at the Ethernet-Layer September 6, 2011 Related Work

12

Related Technologies • • • • •

NetFlow: only IP-based fields PSAMP: only sampled, no flow processing sFlow: dedicated hardware, only sampled tcpdump: full packets, performance problems on high-speed links ...


13

Conclusions • • • •

IP-layer flow monitoring is not sufficient for NGE networks IPFIX allows to define flow keys based on Ethernet fields All active layer-2+ protocols can be monitored Considered approach cannot replace NetFlow

• •

Flow keys consisting of Ethernet- and IP-fields are needed Will be available in the future


14

Thanks for your attention! Contact:

Rick Hofstede [email protected]

Idilio Drago [email protected]

Anna Sperotto [email protected]

Aiko Pras [email protected]


15

Flow Monitoring Experiences at the Ethernet-Layer - Semantic Scholar

Flow Monitoring Experiences at the Ethernet-Layer - Semantic Scholar

Suggest Documents