[雙語翻譯]--校園網(wǎng)外文翻譯--校園網(wǎng)中vlan誘導(dǎo)特征的共享（英文）

1、Characterizing VLAN-Induced Sharing in a Campus NetworkMukarram Bin Tariq, Ahmed Mansy, Nick Feamster, Mostafa Ammar {mtariq,amansy,feamster,ammar}@cc.gatech.edu School of Computer Science, Georgia Tech. Atlanta, GAABSTR

2、ACTMany enterprise, campus, and data-center networks have complex layer-2 virtual LANs (“VLANs”) below the IP layer. The interac- tion between layer-2 and IP topologies in these VLANs introduces hidden dependencies betwe

3、en IP level network and the physical infrastructure that has implications for network management tasks such as planning for capacity or reliability, and for fault diagnosis. This paper characterizes the extent and effect

4、 of these dependencies in a large campus network. We first present the design and imple- mentation of EtherTrace, a tool that we make publicly available, which infers the layer-2 topology using data passively collected f

5、rom Ethernet switches. Using this tool, we infer the layer-2 topol- ogy for a large campus network and compare it with the IP topol- ogy. We find that almost 70% of layer-2 edges are shared by 10 or more IP edges, and a

6、single layer-2 edge may be shared by as many as 34 different IP edges. This sharing of layer-2 edges and switches among IP paths commonly results from trunking multiple VLANs to the same access router, or from colocation

7、 of academic depart- ments that share layer-2 infrastructure, but have logically separate IP subnet and routers. We examine how this sharing affects the accuracy and specificity of fault diagnosis. For example, applying

8、network tomography to the IP topology to diagnose failures caused by layer-2 devices results in only 54% accuracy, compared to 100% accuracy when our tomography algorithm takes input across layers.Categories and Subject

9、Descriptors: C.2.3 [Computer Commu- nication Networks]: Network Operations, Network ManagementGeneral Terms: Management, Measurement, ReliabilityKeywords: Network Diagnosis, Network Virtualization, VLAN, VLAN-induced dep

10、endency1. INTRODUCTIONVirtual LANs (VLANs) enable many distinct LANs to coexist on a fixed set of physical switches and links. Enterprise, campus, and data-center networks use VLANs to group hosts into common ad- ministr

11、ative or functional units, independent of their location in the physical network topology. For example, a campus network con-Permission to make digital or hard copies of all or part of this work for personal or classroom

12、 use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, t

13、o post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IMC’09, November 4–6, 2009, Chicago, Illinois, USA. Copyright 2009 ACM 978-1-60558-770-7/09/11 ...$10.00.figuration may plac

14、e all students on a common VLAN to make it easier for a network administrator to apply common policies to the group of users. VLANs offer network operators flexibility for spec- ifying management and security policies wi

15、thin an enterprise and allow operators to implement some level of isolation by separating hosts into different broadcast domains. This flexibility, however, comes at some cost: IP layer paths that are otherwise disjoint

16、may be “trunked” at layer 2, thereby introducing sharing between paths that might have otherwise experienced independent performance and failure characteristics (e.g., if they had not shared physical in- frastructure). M

17、oreover, because these layer-2 paths are not visible at the IP layer, this sharing may make it more difficult to diagnose some performance problems with conventional IP-layer tools (e.g., traceroute). To properly design

18、and debug their networks, network oper- ators need tools that provide some visibility into network paths that share common network elements at lower layers (e.g., layer- 2 switches or middleboxes). Unfortunately, current

19、 understanding of this sharing—how to measure and characterize it, as well as its effects on network reliability, troubleshooting, and diagnosis—is poor. If operators could instead have better visibility into cross- laye

20、r dependencies, they might be able to better design their net- works to avoid dependencies that might compromise redundancy, and they might also be able to diagnose performance or availabil- ity problems more quickly by

21、identifying common lower-layer net- work elements on paths that might appear independent at higher layers. This paper does not tackle the challenging question of network design. Instead, we take an initial first step in

22、cross-layer analysis, focusing on how VLANs create sharing and dependencies between IP-layer paths that are otherwise disjoint. We present a preliminary study that characterizes the dependencies that exist among IP sub-

23、nets that run over the VLANs on a large campus network. We also characterize the causes of this sharing, as well as the implications of sharing for both reliability and network fault diagnosis. Towards this goal, this pa

24、per presents three contributions:? EtherTrace, a passive layer-2 topology discovery tool. EtherTrace infers the VLAN (layer-2 network) topology us- ing mostly passive measurements of bridge and ARP tables from the switch

25、es in the network. We have made EtherTrace publicly available [7].? An empirical analysis and characterization of VLAN- induced sharing in a large campus network. We analyze VLAN-induced sharing across IP network segment

26、s for the Georgia Tech campus network. The topology discovery and analysis uses bridge-table entries from 1,461 switches cor- responding to about 29,000 active MAC addresses spanningFigure 1: Port labels show the hosts w

27、hose frames are received on that port. Switches that are along the path between hosts 1 and 2 (i.e., the shaded nodes) receive the frames from these hosts on two different ports. Other switches receive the frames from th

28、e hosts on the same port, if at all.Specifically, for hosts x and y, the elements on the path are given as a set of 3-tuples as follows:? S(x, y) = {(e.b, e.p, e.v) : e ∈ Tx?y,e.b ∈ B(Tx) ∩ B(Ty),e.v ∈ V (Tx) ∩ V (Ty)} (

29、1)The first constraint in Equation 1 selects all of the bridge, port, VLAN tuples that belong to either hosts, except those that are iden- tical (i.e., where the bridge hears from the two hosts on the same port and VLAN

30、tag). The second and third constraints ensure that EtherTrace includes only the bridges that receive frames from both hosts on same VLANs. There are two sub-cases. Although network administrators usu- ally configure each

31、 VLAN to correspond to one IP subnet, it is possible to connect multiple VLANs by connecting two non-trunk ports with a loop cable, in which case the spanning-trees on the VLANs merge. If the two hosts are on such VLANs,

32、 the above al- gorithm will still work correctly because the merged VLANs will appear in V (Tx) ∩ V (Ty). The second sub-case occurs when a pair of bridges along a path are connected through a passive com- ponent, such a

33、s a hub or a repeater element. EtherTrace cannot recognize such passive elements. If the two hosts are on such a segment, EtherTrace declares an empty path between the hosts. In most modern network deployments, each host

34、 connects directly to a switch port and there is little, if any, communication that takes place over hubs or buses. As a result, EtherTrace will fail in only a few cases. Similar to this sub-case, it is possible that Eth

35、erTrace is not aware of presence of some switches in the network and thus does not obtain bridge tables from them. EtherTrace is unable to detect such switches if they appear on the path.Case 2: Hosts on different VLANs.

36、 When hosts are on different VLANs on the network, EtherTrace can determine the layer-2 path between these hosts by using the IP-level traceroute between these hosts. EtherTrace first infers the layer-2 path elements for

37、 each IP-path segment and then concatenates them to determine elements on the entire path. If the traceroute between the hosts x and y is {h1 · · · hk}, h1 = x and hk = y then the set of layer-2 elements o

38、n the path is:Data Sources Switches 1,358 successfully polled for this dataset. (1,461 total in the network.) Routers 31 CPR Nodes 79Dataset Bridge Tables Polling Interval: 4 hours. ARP Tables Polling Interval: 1 hour. 2

39、8,836 active MAC ad- dresses; 88,932 including stale. IP Trace-routes Once every five minutes.Table 1: Summary of the dataset.Duration < 1s < 2s < 5s < 20s < 40s < 57sSwitches 700 986 1114 1280 1340 135

40、848% 67% 76% 87% 91% 93%Table 2: Latency for obtaining bridge-table entries from the switches. 93% of switches replied within one minute.S(x, y) = [i=1:k?1? S(hi, hi+1) (2)Implementation. We have implemented EtherTrace i

41、n Python with a MySQL database backend and made it publicly available [7]. The current implementation of EtherTrace relies on a database that is continually updated with the bridge tables from switches, ARP tables from r

42、outers, and traceroute information from the hosts in the network. Obtaining the bridge tables from the switches and ARP tables from the routers requires administrative access to these devices, but once the intermediate d

43、atabase is populated with these tables, the inference is passive and does not require interaction with the network devices. As a result users do not require administrative access to the network devices to obtain the laye

44、r-2 paths.3. DATA AND TOPOLOGYThis section describes the data and the process of inferring the layer-2 topology using EtherTrace.3.1 DataTypes of data. We rely on three sources of data, all from the Georgia Tech campus n

45、etwork. The first is the bridge table entries obtained from all the switches; we poll these switches every four hours using SNMP. The second is the ARP tables; we poll these routers hourly. These tables provide us with I

46、P address to MAC address mappings. The third is the IP traceroutes between 79 CPR nodes [4], end hosts that are deployed in mostly distinct subnets on the campus network. These nodes perform pairwise traceroutes to each

47、other once every five minutes. Historically, this data has been collected for auditing purposes, which is why each data set has different polling intervals. The traceroute data from the CPR nodes is the only one designed

48、 for active measurement. This paper focuses on characterization of VLAN-induced dependencies in a stable network, so the slow up- date rates suffice for this study.Completeness and consistency. Because the ARP and bridge