Slides from my talk at NORDUnet 2011 in Reykjavik

1. Automatic topology detection in NAV
NORDUnet 2011, Reykjavik
Morten Brekkevold

2. In the beginning...
 A large, heterogenous campus network
 Norwegian University of Science and 2
Technology, in Trondheim
 20.000 students
 Student villages connected

3. Basic NMS needs
 Status monitoring
 Alerts 3
 Traffic statistics

4. The real challenges
 Who's connected, where and when?
 Filtered outage alerts 4
 Network weather map

5. Abuse handling
 Given an IP address, date and time
 Where was the perpetrator 5
connected?
 Block access!

6. The real challenges
 Who's connected, where and when?
 Filtered outage alerts 6
 Network weather map

7. Central node outage
 Router goes down
 100 switches ping-unreachable 7
 Want a single alert, not 100

8. The real challenges
 Who's connected, where and when?
 Filtered outage alerts 8
 Network weather map

9. Weather maps
 Layers 2 and 3
 Traffic load 9
 Automatic layout

10. What is needed?
 A good understanding of the network
topology 10

11. But?
 It's 1999!
 Proprietary discovery protocols 11
 LLDP not invented yet
 No 802.1X authentication

12. The birth of NAV
 Current commercial NMS-es tested
and rejected 12
 Let's write our own!
 Network Administration Visualized
was born
 Made free in 2004, under a GPL
license

13. Approach
 Collect SNMP data
 IETF MIBs 13
 Vendor proprietary MIBs
 Process data

14. First task
 Port classification
 Uplink/downlink 14
 Access port
 How?
 It's in the MAC address!
 Let's find the MAC addresses of all
monitored nodes

15. IP / MAC mappings
 Routers know which IP and MAC
addresses are associated 15
 ARP for IPv4
 ND for IPv6
 NAV has the IPs of all
switches/routers

16. Interface MAC addresses
 Each interface on an Ethernet device
has a unique MAC address 16
 These may appear in other switches'
forwarding tables

17. Now what?
 We know the MAC addresses used
by all monitored infrastructure 17
 Let's get the switches' forwarding
tables!

18. Getting forward
 Infrastructure MAC found on port →
Uplink/downlink port 18
 Otherwise → Access port

19. Processing
 Multiple adjacency candidates per
uplink/downlink must be pruned 19
 Trust data from any port with a single
candidate X
B
Y
R A C
Z

20. Upshot
 Now we also know the switch port
and MAC/IP addresses of every end- 20
user
 Log them!

21. For added accuracy
 CDP (Cisco proprietary)
 LLDP (IEEE standard) 21

22. Cisco Discovery Protocol
 Reports adjacent device and port
without processing 22
 BUT:
 CDP frames are forwarded as regular
ethernet frames through non-CDP
switches
 Non-CDP switches become
“invisible”
A B C

23. Link Layer Discovery
Protocol
 Improves on CDP
 Uses multicast destination addresses 23
that a standards-conforming ethernet
switch must not forward
 Should eliminate “invisible device
problem”

24. Solved challenges
 A full layer 2 topology has been
obtained 24
 A complete log of end-user
connectivity
 We can filter outage alerts based on
topology

25. Filtering outage alert
NAV
server
25

26. What about layer 3?
 Collect routers' IP addresses and
prefixes 26
 Give complete overview of subnet
allocations

27. Layer 3 links
 Discernable through:
 Prefix mask size 27
 Number of connected routers
1 router → Elink (or LAN)
 2 routers → Link
 > 2 routers → Core

28. What about VLANs?
 IEEE 802.1Q
 Subsets of layer 2 topology 28
 Need to collect more data!

29. SNMP 802.1Q & 802.1D
 Get:
 Native VLAN of each switch port 29
 Tagged VLANs on trunk ports
 STP blocked VLANs on switch ports
 Map VLAN IDs to IP subnets

30. VLAN topology
 Each routed VLAN's topology can
now be seen as 30
 a subset of the layer 2 topology
 rooted at one or possibly more
router ports

31. The larger picture
 Physical topology
 ARP/ND
 CAM
 CDP(/LLDP)
31
 VLAN topology
 Trunks
 STP

32. Weather maps
32

33. Geographical maps
33

34. What else?
 There's more to NAV than this
 There are always other ways to use 34
this data

35. End-user detention
 NAV can help track abusers and
restrict access on their switch port: 35
 by shutting it down
 or configuring a restricted quarantine
VLAN

36. IPv6 deployment stats
 IP/MAC mappings include both IPv4
and IPv6 addresses 36
 Can be (and are being) used to
generate IPv6 deployment statistics

37. IPv6 deployment graph
 Consolidated data of 31 HE institutions
 2 year period 37

38. UNINETTs involvement
 Saw the potential of NAV as beneficial
to entire HE community 38
 Provided funding for development
since 2001
 Took control of development in 2006

39. Deployment in Norway
 Success in Norwegian HE community
 36 universities and colleges run NAV 39
 Contributions from all major
universities

40. Nordic collaboration?
 We hope to see a wider Nordic
adoption of NAV 40
 Collaboration on development efforts
to make useful for all involved parties
 How?

41. In closing...
 http://metanav.uninett.no/
 morten.brekkevold@uninett.no 41

42. MIB references
 IP related MIBs
 IP-MIB (RFC 4293)
 IPv6-MIB (deprecated) 42
 CISCO-IETF-IP-MIB
 Interface details
 IF-MIB (RFCs 1573, 2863, 1229)
 Switch forwarding tables
 BRIDGE-MIB (RFC 4188)
 VLAN MIBs
 Q-BRIDGE-MIB (RFC 4363)
 Community indexed BRIDGE-MIB (Cisco)
 Other proprietary MIBs