What should you configure to allow communication between these two devices through the switches?

Exam Objectives Fast Track

Virtual LANs

A VLAN, according to the official IEEE definition, defines broadcast domains at Layer 2. VLANs, as a Layer 2 entity, really have little to do with the TCP/IP protocol stack, but VLANs make a huge difference in how switches and routers operate on a TCP/IP network.

Routers do not propagate broadcasts as bridges do, so a router automatically defines broadcast domains on each interface. Layer 2 LAN switches logically create broadcast domains based on configuration of the switch. The configuration tells the LAN switch what to do with a broadcast received on a port in terms of what other ports should receive it (or if it should even be flooded to all other ports).

When LAN switches are used to connect LAN segments, the broadcast domains cannot be determined just by looking at the network diagram. Systems can belong to different, the same, or even multiple, broadcast domains. The configuration files in the LAN switches determine the boundaries of these domains as well as their members. Each broadcast domain is a type of “virtual bridge” within the switch. This is shown in Figure 2.6.

Each virtual bridge configured in the LAN switch establishes a distinct broadcast domain, or VLAN. Frames from one VLAN cannot pass directly to another VLAN on the LAN switch (or else you create one big VLAN or broadcast domain). Layer 3 internetworking devices such as routers must be used to connect the VLANs, allowing internetworking and at the same time keeping the VLAN broadcast domains distinct. All devices that can communicate directly without a router (or other Layer 3 or higher device) share the same broadcast domain.

VPLS Scalability Factors

The way for VPLS to emulate IEEE 802.3-alike broadcast domains and to avoid loops at the same time is to (a) create a full mesh of PWEs among all the PEs and (b)to enforce the split horizon rule. As a consequence of the PWE full-mesh, the control and data planes are impacted by the so-called “N2” issue:

From a control plane perspective, each PE node will require:

(N-1) TLDP sessions; N = the number of PEs in a particular network

(M-1) PWEs (mesh-SDP) per VPLS; M = number of PEs in a particular VPLS instance

(N-1)*2 initiated LSP tunnels assuming secondary LSPs; N = number of PEs in a particular VPLS network

(N-1)*2 terminated LSPs

(X) transit LSPs (if P function)

From a data plane standpoint, each PE node will require BUM replication: N-1 copies of the same BUM frame replicated at the ingress PE, even though all the copies may go over the same physical interface (ring topologies). This is inefficient and unnecessarily consumes bandwidth.

In a nutshell, we could state that the main scalability factors to take into account in VPLS networks are:

TLDP sessions scaling

PWE scaling

MPLS tunnel scaling

Replication efficiency

16.7.1.4 Virtual local area networks

VLANs commonly are used to split up groups of network users into manageable broadcast domains, to create logical segmentation of workgroups, and to enforce security policies among logical segments.

Setting up VLANs is a way to segment networks to increase network flexibility without changing the physical network topology. With network segmentation, each switch port connects to a segment that is a single broadcast domain. When a switch port is configured to be a member of a VLAN, it is added to a group of ports (workgroup) that belong to one broadcast domain. Ports are grouped into broadcast domains by assigning them to the same VLAN. Frames received in one VLAN can only be forwarded within that VLAN, and multicast, broadcast, and unknown unicast frames are flooded only to ports in the same VLAN.

The IBM DS 5000V supports jumbo frames with a maximum transmission unit (MTU) of 9216 bytes. Within each frame, 18 bytes are reserved for the Ethernet header and CRC trailer. The remaining space in the frame (up to 9198 bytes) comprise the packet, which includes the payload of up to 9000 bytes and any additional overhead, such as 802.1Q or VLAN tags. On the access ports, jumbo frame support is automatic: it is enabled by default, requires no manual configuration, and cannot be manually disabled. However, on the uplink ports, the default MTU is 1500 bytes, though this may be configured in the uplink profiles.

The IBM DS 5000V software supports 802.1Q VLAN tagging, providing standards-based VLAN support for Ethernet systems.

Tagging places the VLAN identifier in the frame header of a packet, allowing each port to belong to multiple VLANs. When you add a port to multiple VLANs, you must enable tagging on that port. Since tagging fundamentally changes the format of frames transmitted on a tagged port, you must carefully plan network designs to prevent tagged frames from being transmitted to devices that do not support 802.1Q VLAN tags or devices where tagging is not enabled.

Layer 2 Switches and Isolation Techniques

Layer 2, meaning Ethernet switches, might be a topic that most people do not consider very much or very long in terms of security. But some attacks can take advantage of weaknesses at Layer 2. For example, consider the popular Ettercap tool (http://ettercap.sourceforge.net), which fundamentally relies on attacks such as ARP spoofing or filling a switch forwarding table full of fake MAC addresses to enable password sniffing. (See www.securitypronews.com/securitypronews-24-20030623EtterCapARPSpoofingandBeyond.html for more discussion of Ettercap-based attacks.)

We need to define a few terms before we go on:

Broadcast domain Essentially, a broadcast domain on Ethernet is the set of systems reachable by an ARP broadcast. If one host sends an Ethernet broadcast, all the other hosts that receive the broadcast packet are in the broadcast domain. These days a broadcast domain can be a virtual as well as a physical idea. Ethernet switches are capable of using Virtual LANS (VLANS) so that ports (interfaces) on more than one switch can be “glued together” to make a virtual network. At least one and sometimes more IP subnets can exist in a broadcast domain.

Unicast segmentation This idea is an old Ethernet bridge notion carried over to modern Ethernet switches. Essentially, the switch tries to learn which MAC address is associated with which port. This process is called adaptive learning. The hoped-for result is called Unicast segmentation. For example, if two hosts in the broadcast domain are communicating via Unicast packets (say, A and B) and the switch for some reason does not know the port for host B, it will flood the packets for B out other ports (say C, D, and E). If it does know where B is to be found, then C will not see the packets. This keeps C's switch connection uncluttered in terms of bandwidth. It also means that C is not able to “sniff” A and B's conversation unless explicit techniques such as turning on port mirroring in the switch or implicit techniques such as a switch forwarding table attack (discussed later) are used.

ARP spoofing A host in a local subnet has decided to broadcast an ARP packet to attempt to overwrite ARP caches in other hosts. As a result, the spoofing host steals another host's IP address on the subnet. Thus the ARP cache entry for a benign host X that consists of X's IP, and Layer 2 MAC address are overwritten with evil host E's MAC address. Note that E is usurping X's IP address. Our evil host E is simply replacing X's MAC with E's MAC address in some third-party host Z's ARP cache. Now when Z tries to talk to X (good), the packets first go to E (evil). Typically but not always, E tries to replace the local router's MAC address with its own address. This allows it to see all the packets good hosts are trying to send to and from the Internet and enables an entire bag full of possible man-in-the-middle (MITM) attacks. This form of attack is sometimes called ARP poisoning as well.

Switch forwarding table overflow One common way to implicitly disable Unicast segmentation is to send out enough MAC addresses to cause the switch's adaptive learning table (which has many names, depending on the vendor, including CAM table, forwarding table, and the like) to fill up with useless cruft. As a result, Unicast segmentation may be turned off, and packets from A to B, as in our previous example, will be flooded to C. This sort of attack is, of course, not likely to be benign and is available via the Ettercap tool or other similar tools.

The next worst thing to having a malefactor standing physically next to a protected computer is to have the attacker within the same ARP broadcast range of a protected host. Until recently there has been little useful protection against some forms of attack in the same broadcast domain. One could also point out that ARP and DHCP as fundamental networking protocols lack authentication. Moreover, other protocols might assume that nearby hosts are “safe” and hence use plain-text passwords to contact those systems, or simply send in the clear data that's possibly useful for identity theft.

Some have called having only a border firewall and no other defenses “M&M security,” meaning that the border firewall represents a hard, crunchy shell that, once pierced, leads to a soft, chewy middle. In a recent blog entry (http://blogs.msdn.com/larryosterman/archive/2006/02/02/523259.aspx), Larry Osterman took a rather humorous slant on this in comparing a DMZ firewall to the French Maginot Line in World War II. The French built a great defense wall to keep the Germans out. Unfortunately, the Germans simply drove north around it. The lesson is that it is reasonable to consider defense in depth for hosts within a firewall enclave. These techniques can include host firewalls and cryptographic protocols. They can also include Layer 2 techniques as one more form of defense in depth. The good news about Layer 2 techniques is that they are not per host but can be centrally administered by a network engineer.

Malware spread via botnets or other means could choose to launch attacks, including:

ARP spoofing This is especially useful in the case where an attacking host on a local subnet chooses to masquerade as the router to allow it to view or change packets from the attacked host to the rest of the network.

Switch table flooding with the common goal of password sniffing Put another way, the defeat of traditional Unicast segmentation in an Ethernet switch means that the host running the packet sniffer might be able to see packets (especially plain-text passwords) that it might not otherwise be able to observe.

DHCP attacks For example, an attacking system might simply intercept DHCP requests and substitute itself as the local router. In addition to ARP spoofing, this could be another form of MITM attack.

This is not an exhaustive list of Layer 2 attacks, but we will confine ourselves to this list for the time being, since the first two scenarios are more common in our experience.

So, do the good guys have any tricks up their sleeves? Yes, a few. The tricks can be divided into two categories: switch configuration, which must rely on vendor features, and infrastructure tricks, which hopefully can be done by any network engineer with most hardware.

Cisco switches have long supported a port security feature in a number of variations. For example, a switch can be configured to statically lock down a MAC address, or it can be configured to dynamically learn the first MAC address it sees. This makes flooding the switch table unlikely. A number of the switch configuration features are relatively new in the world and can be found in recent Cisco Catalyst switches. See Charlie Schluting's excellent article, Configure Your Catalyst For a More Secure Layer 2, for more information: www.enterprisenetworkingplanet.com/netsecur/article.php/3462211. Schluting tells us that:

Cisco switches can track DHCP assignments. Therefore, they know which IP address is associated with which MAC address at which port. This feature is called DHCP snooping. DHCP snooping enables other features and helps protect against the possibility of a DHCP-based MITM attack because the switch ends up knowing where the real DHCP server lives.

A related feature called IP Source Guard means that a host cannot use another IP than the one assigned to it with DHCP.

In addition, the switches have an ARP spoofing feature called dynamic ARP inspection. This feature prevents the switch from allowing ARP spoofing attacks. The IP address and MAC address must match.

These new features, along with traditional port security, can help make the Layer 2 switched environment much safer.

From the infrastructure point of view, here are several techniques that could help security:

Limit the number of hosts in a VLAN (or broadcast domain) as much as possible. From a redundancy point of view, it has never been a good idea to have all hosts in an enterprise on one IP subnet, simply because a broadcast storm or Layer 2 loop can take out the subnet. But if you consider password-sniffing attacks (or even password-guessing attacks), it could be useful to limit the number of hosts in the subnet anyway. For example, knowledge of an ARP table on an exploited host gives the exploiter knowledge about possible fan-out attacks. If you reduce the possible size of the ARP table, the scope of the fan-out attack can be reduced. This design idea simply limits exposure to possible Layer 2 problems from both from the redundancy point of view and the “your neighbors might be dangerous” point of view.

The default ARP cache timeout value on Cisco routers is 4 hours. The default forwarding table timeout on switches is likely to be 5 minutes. Ironically, adaptive learning in Layer 2 switches is typically a side effect of an ARP broadcast. As a result, the switch learns where the sender lives and stops flooding Unicast packets to it in the direction of other hosts. If, however, the flooding is happening because the switch does not know where the host is to be found and a hacker installs a password sniffer on another host, the hacker could see Unicast packets you would very much like for them to not see. The hacker does not need to attack the switch with a forwarding table overflow attack. All he or she needs to do is wait, and, of course, programs are very good at waiting. You might set the switch forwarding table time to match the router or choose a compromise time with the forwarding table time set higher and the router time set lower. In any case, setting them to be the same to minimize Unicast segmentation failure seems a good idea.

It can be useful to combine VLANs on switches and router ACLs to simply make IP addresses assigned to network infrastructure devices such as wireless access points and Ethernet switches unreachable by ordinary hosts. For example, all the switch ports might be “fmdable” on private net 10/8 and made reachable by a VLAN (or two). As a result, we can hope that the local malware infection cannot launch an attack against infrastructure boxes.

One final point is that switches can have logging as well. Logging based on various Layer 2 isolation violations can thus alert you to a hacked system.

Understanding the LMHOSTS File

The LMHOSTS file is similar in purpose to the hosts file used for host name resolution. Both are text files that provide static mappings of names to IP addresses. However, the LMHOSTS file has added functionality that can be implemented with the use of special “tags” that can provide additional information. For example, you can use the #PRE tag (it is case-sensitive) to instruct the computer to always cache the record in the NetBIOS name cache. You can use the #DOM tag (it is also case-sensitive) to identify the computer as a domain controller.

LMHOSTS files are simple to create. They are created in the same folder where the hosts file is located. The complete path to the LMHOSTS file is %systemroot%\system32\drivers\etc\lmhosts, where %systemroot% is a variable used to identify the folder where the operating system is installed, such C:\Winnt or C:\Windows. When you open the %systemroot%\system32\drivers\etc folder, you will notice that a file named Lmhosts. SAM has been provided for you as a sample. This file contains instructions and sample records for creating an LMHOSTS file. You can modify this file for use as your LMHOSTS file, but it is important to remember that you must save the file without the. SAM extension in order for the file to work for NetBIOS resolution. As with the hosts file, the LMHOSTS file should have no extension.

LMHOSTS files are parsed from top to bottom, so you can optimize the operation of LMHOSTS files by placing any entries with the #PRE tag at the bottom of the file. These entries need to be read only once to be cached.

It is also possible to use a centrally located LMHOSTS file to provide name resolution for clients through the use of the #INCLUDE, #BEGIN_ALTERNATE, and #END_ALTERNATE tags in the LMHOSTS file. The #INCLUDE tag is used to indicate the NetBIOS UNC share name and path to the LMHOSTS file. Multiple #INCLUDE statements can be listed between the #BEGIN_ALTERNATE and #END_ALTERNATE statements.

In order for the client computers to be able to access the share specified in the #INCLUDE statement, the computers hosting the remote LMHOSTS files must have support for NullSessionShares enabled, which allows anonymous connections to the share. This is a weakening of file sharing security, so you need be careful when using LMHOSTS files in this way.

LMHOSTS files are a good solution in small environments that have a segmented network. In addition, they can be useful in situations where you want some computers to communicate with others across a WAN link, but you do not want to combine the NetBIOS namespace of the offices on either side of the link. However, in large environments, LMHOSTS files are difficult to maintain. An LMHOSTS file must be present on each computer that needs it for name resolution. You can create centralized LMHOSTS files, but the client computers must first have an LMHOSTS file to gain access to the centralized LMHOSTS files. Also, you must manually enter NetBIOS name-to-IP address mappings, increasing the possibility for error. Finally, the use of LMHOSTS files is not possible in an environment that uses DHCP to assigned TCP/IP address configurations to client computers.

To support NetBIOS name resolution in a segmented network or one that uses multiple broadcast domains, a better approach than LMHOSTS files is to use WINS. If a network has been using LMHOSTS files extensively, it is relatively easy to migrate to WINS by importing LMHOSTS files to the database to create static mappings. However, you need to exercise care to ensure that these mappings can be overwritten by WINS clients that use dynamic mappings. We discuss this issue in more detail later in the chapter.

EXAM WARNING

Planning NetBIOS name resolution by using LMHOSTS files is part of the objective domain for Exam 70-293. Therefore, you might encounter questions that require a knowledge of the LMHOSTS file.

Broadcast Domains

VLANs were envisioned to separate different kinds of traffic and that separation includes separating different broadcast domains. As we discussed in Chapter 13, a broadcast domain is the area that a broadcast will propagate out to. These broadcasts also need to flow from one switch to another through a VLAN that is connected by a trunk. A packet such as a Dynamic Host Configuration Protocol (DHCP) packet that is based on broadcasts needs the capability to flow through the VLAN to every machine even though they may be connected on different switches. This is not to say that DHCP packets flow between VLANs because the only way for traffic to flow between VLANs is via a router, and a router by default blocks broadcast packets.

EFP-to-EFP (E-MPB)

For EFP-based configuration, the bridge-domain <vlan-ID> defines the broadcast domain on which frames from this EFP must be available. This command alone will not add or modify any VLAN header in the packet because this operation, if desired, is solely performed by the rewrite ingress command. Internally the bridge domain VLAN is updated in the 7600 DBUS header VLAN field and the frame is left intact on ingress if no rewrite action is configured.

As shown in Figure 9.7, the resulting frame on the wire totally depends on the rewrite configuration. LAN tag rewrite is not mandatory for bridging between EFPs, since the original VLAN ID is preserved through the internal switching process.

Forced Forwarding Upstream

The purpose of forced forwarding is to protect each subscriber’s data from inadvertently getting to his neighbor. Forced forwarding accomplishes this by not letting data cross from one user to another in the PON system. To ensure the secure transmission of subscriber data from the ingress at the UNI port—through the access system and out through the egress at the SNI—the subscriber traffic is directed via L2 forced-forwarding through each part of the PON system, disallowing the ability to switch locally or peer-to-peer in a hair-pin along its forwarding path. Upstream from the UNI ingress point no local switching is allowed internal to the ONT UNI ports (assuming that there are multiple ports in the ONT device). This is often called switching isolation. This may be disabled by the operator, but in practice it is typically a default setting. In the multidwelling or multibusiness case, where several subscribers may be using the same ONT device for services, this is a critical function to isolate the traffic of each subscriber using the MDU (multidwelling unit—an ONT serving multiple apartments or businesses). When the subscriber traffic is in the shared medium PON link, it is protected within either a GEM (GPON encapsulation method) port in the GPON case or an LLID (link layer identification) in the EPON system. (Both a GEM port and an LLID are packet encapsulations that ensure that the packet is delivered only to the port for which it is intended.) In the PON link, this is typically implemented through the restricting switching between ONT stations, or peer-to-peer switching. When the data reach the OLT, and are switched upstream through the OLT system to the SNI egress point out of the PON system, the data are protected by their VLAN partitioning and the use of either MAC forced forwarding or switching protection available in the switching fabrics which make up the Ethernet switching implementation of the OLT system. In this case, the Ethernet frames are forced to proceed out certain ports in the direct path to the SNI ports and internally prohibited to either switch to another part of the OLT or back to the port on which they entered the switch. This is also sometimes referred to as split horizon. However, this is, strictly speaking, a routing term.

These switching constructs are alluded to in the GPON standard. Page 20 of ITU-T G.984.1 (03/2008),i in the description of the data functions, mentions that there are “several mainstream arrangements of VLANs; these are specified in [b-DSL TR-101] .”ii The handling of traffic in a split horizon methodology (i.e., traffic forced upstream—not allowed to switch on the ONT or OLT, but rather forced to be forwarded from the UNI to the SNI) is covered for GPON in TR-156.iii TR-156 specifies the usage of GPON access in the context of TR-101 (which defines Ethernet access networking architectures and guidelines), and TR-200,iv which specifies the usage of EPON access in the context of TR-101.

The protection of subscriber data via the separation of L2 data flows in this way is an important aspect of access systems and PON systems in particular. The VLAN architecture determines how many subscribers and devices (or alternatively L2 endpoints or MAC addresses) are included in each VLAN. In the event that the OLT is architected as a multibladed, distributed Ethernet switch, the VLANs can cross Ethernet switch ports and be allocated across switching domains. For example, one VLAN may contain only a single ONT or even UNI—or one VLAN may contain a number of ONTs or UNIs—either way the enforced separation of those data flows is key to subscriber security. Whether the VLAN is allocated across the entire OLT, on a single OLT line card, or a single PON port within the OLT, the network operator needs to understand and sometimes force how the frames will be switched—based on the equipment vendor implementation and the control points that the solution provides.

The VLAN allocation will determine the number of included MAC address endpoints and the resulting size of the broadcast domain. Since all the devices in an individual broadcast domain “see” each other, i.e., will receive broadcast messages originated in that broadcast domain, in general the number of devices should be limited in size to reduce the number of endpoints which generate and receive broadcast traffic together. Lastly, in an access system the best practice is to prohibit Ethernet frames from egress on the same port on which they are received (i.e., the port on which their MAC address is learned). In summary the primary operational aspects of L2 forced forwarding are:

ONT UNI port isolation;

Prohibiting peer-to-peer local switching between ONT stations on the PON link. A notable exception to this rule is sometimes allowing ONT stations to receive peer-to-peer VoIP traffic on the voice service VLAN. Another exception is to support business connection between ONTs on the same PON.

The usage of switching protection or isolation based upon logical or physical interfaces; or MAC forced forwarding in the upstream internal to the OLT system.

Virtual LAN (VLAN)

A single LAN, interconnected with a layer 2 network switch may be partitioned in Virtual LANs (VLANs) so that they create multiple distinct broadcast domains. In such a configuration, data packets can only pass between them via one or more routers.

Grouping CCTV elements (hosts) like IP cameras, NVRs or DVRs, with a common set of requirements regardless of their physical location by VLAN can greatly simplify network design. The advantages of VLANs important for some CCTV projects are creating more bandwidth by segmentation of broadcast domains, additional security and flexibility.

A VLAN has the same attributes as a physical local area network (LAN), but it allows for end stations to be grouped together more easily even if they are not on the same network switch. Switch ports configured as a member of one VLAN belong to a different broadcast domain, as compared to switch ports configured as members of a different VLAN. If a switch supports multiple VLANs, broadcast within one VLAN never appear in another VLAN. VLAN membership can be configured through software instead of physically relocating devices or connections. Most enterprise-level networks today use the concept of virtual LANs. Without VLANs, a switch considers all interfaces on the switch to be in the same broadcast domain.

Creating VLANs enables administrators to build broadcast domains with fewer users in each broadcast domain. This increases the bandwidth available to users because fewer users will contend for the bandwidth. Traffic can pass from one VLAN to another only through a router. VLANs enable a network administrator to assign users to broadcast domains based upon the user’s job need. This provides a high level of deployment flexibility for a network administrator.