Homework Assignment #1
1
Homework Assignment
• Part 1: LAN setup
– All nodes are hosts (including middle nodes)
– Each link is its own LAN, with its own IP subnet
– Can ARP and ping only to directly-connected hosts
H
H
H
H
H
H
H
H
2
Homework Assignment
• Part 2: Writing your own switch
– Middle nodes are switches and know nothing about IP
– Switches transit Ethernet frames between interfaces
– All hosts belong to a common IP subnet
H
H
H
H
S
S
H
H
3
Homework Assignment
• Part 3: Fun with OSPF
– All nodes are routers running Quagga
– Each link is its own (say, /30) subnet
– Each node has an OSPF adjacency with each neighbor
R
R
R
R
R
R
R
R
4
Homework Suggestions
• Automation with scripts
– Generate the host, Click, and OSPF configuration
– Faster, less error-prone, and saves your work
• Checking the host configuration
– ifconfig
– arp -a
• Passive monitoring
– Tcpdump on host interfaces
– ListenEther on switches
• Start simple
– E.g., two hosts connected to a single switch or router
5
Enterprise Configuration
Jennifer Rexford
Fall 2010 (TTh 1:30-2:50 in COS 302)
COS 561: Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall10/cos561/
Outline
• Enterprise network components
– Repeaters/hubs, bridges/switches, and routers
• Enterprise network design
– Hubs and switches, with DHCP server
– Ethernet subnets interconnected by routers
• Flexible connectivity
– Virtual Local Area Networks (VLANs)
– Multi-homing to multiple ISPs
– Interconnecting multiple enterprise locations
• Discussion of papers
– VLAN survey and SEATTLE architecture
7
Enterprise Network Components
8
Physical Layer: Repeaters
• Distance limitation in local-area networks
– Electrical signal becomes weaker as it travels
– Imposes a limit on the length of a LAN
• Repeaters join LANs together
– Analog electronic device
– Continuously monitors electrical signals on each LAN
– Transmits an amplified copy
Repeater
9
Physical Layer: Hubs
• Joins multiple input lines electrically
– Do not necessarily amplify the signal
– Very similar to repeaters
• Disadvantages
– Limited aggregate throughput due to shared link
– Cannot support multiple rates or formats
hub
(e.g., 10 Mbps vs. 100 Mbps Ethernet)
– Limitations on maximum # of
nodes and physical distance
hub
hub
10
Link Layer: Bridges
• Connects two or more LANs at the link layer
– Extracts destination address from the frame
– Looks up the destination in a table
– Forwards the frame to the appropriate LAN segment
• Each segment can carry its own traffic
host
host
host
host
host
host
host
host
Bridge
host
host
host
host
11
Link Layer: Switches
• Typically connects individual computers
– A switch is essentially the same as a bridge
– Supports concurrent communication
• Cut-through switching
– Start forwarding a frame while it is still arriving
switch/bridge
segment
hub
segment
segment
hub
hub
12
Hubs, Switches, and Routers
Hub/
Bridge/
Router
Protocol layer
Repeater
physical
Switch
link
Traffic isolation
no
yes
yes
Plug and play
yes
yes
no
Efficient routing
no
no
yes
Cut through
yes
yes
no
networ
k
13
Enterprise Network Design
14
Simple Enterprise Design
• A single layer-two subnet
– Hubs and switches
– Gateway router connecting to the Internet
– ISP announces the address block into BGP
• Local services: DHCP and DNS
S
1.2.3.1
S
DHCP server
1.2.3.0/24
Internet
G
1.2.3.76
0.0.0.0/0
S
1.2.3.5
1.2.3.150
S
DNS server
15
Scalability Limitations
• Spanning tree
– Paths that are longer than necessary
– Heavy load on the root bridge
– Bandwidth wasted for links not in the tree
• Forwarding tables
– Bridge tables grow with number of hosts
• Broadcast traffic
– ARP and DHCP
– Applications that broadcast (e.g., iTunes)
• Flooding
– Frames sent to unknown destinations
16
Hybrid of Switches and Routers
• Layer-two subnets interconnected by routers
– No plug-and-play and mobility between layer-2 subnets
– Need consistent configuration of IP routing and DHCP
1.2.3.0/26
Ethernet Bridging
- Flat addressing
- Self-learning
- Flooding
- Forwarding along a tree
R
R
IP Routing
- Hierarchical addressing
- Subnet configuration
- Host configuration
- Forwarding along shortest paths
1.2.3.192/26
R
Internet
R
1.2.3.128/26
R
1.2.3.64/26
17
Virtual Local Area Networks
(VLANs)
18
Evolution Toward Virtual LANs
• In the olden days…
– Thick cables snaked through cable ducts in buildings
– Every computer they passed was plugged in
– All people in adjacent offices were put on the same LAN
– Independent of whether they belonged together or not
• More recently…
– Hubs and switches changed all that
– Every office connected to central wiring closets
– Often multiple LANs (k hubs) connected by switches
– Flexibility in mapping offices to different LANs
Group users based on organizational structure,
rather than the physical layout of the building.
19
Why Group by Organizational Structure?
• Privacy
– Ethernet is a shared media
– Any interface card can be put into “promiscuous” mode
– … and get a copy of any flooded/broadcast traffic
– So, isolating traffic on separate LANs improves privacy
• Load
– Some LAN segments are more heavily used than others
– E.g., researchers running experiments get out of hand
– … can saturate their own segment and not the others
– Plus, there may be natural locality of communication
– E.g., traffic between people in the same research group
20
People Move, and Roles Change
• Organizational changes are frequent
– E.g., faculty office becomes a grad-student office
– E.g., graduate student becomes a faculty member
• Physical rewiring is a major pain
– Requires unplugging the cable from one port
– … and plugging it into another
– … and hoping the cable is long enough to reach
– … and hoping you don’t make a mistake
• Would like to “rewire” the building in software
– The resulting concept is a Virtual LAN (VLAN)
21
Example: Two Virtual LANs
R
O
O
R
O
O
R
R
O
RO
O
R
R
O
R
O
R
Red VLAN and Orange VLAN
Switches forward traffic as needed
22
Making VLANs Work
• Changing the Ethernet header
– Adding a field for a VLAN tag
– Implemented on the bridges/switches
– … but can still interoperate with old Ethernet cards
• Bridges/switches trunk links
– Saying which VLANs are accessible via which interfaces
• Approaches to mapping access links to VLANs
– Each interface has a VLAN color
 Only works if all hosts on same segment belong to same VLAN
– Each MAC address has a VLAN color
 Useful when hosts on same segment belong to different VLANs
 Useful when hosts move from one physical location to another
23
Multi-Homing
24
Motivation for Multi-Homing
• Benefits of multi-homing
– Extra reliability, e.g., survive single ISP failure
– Financial leverage through competition
– Better performance by selecting better path
– Gaming the 95th-percentile billing model
ISP 1
ISP 2
1.2.3.0/24
25
Multi-Homing Without BGP
Inbound Traffic
• Ask each ISP to originate
the IP prefix
Outbound Traffic
• One ISP as a primary, the
other as a backup
• … to rest of the Internet
• Or simple load balancing
of all traffic
ISP 1
ISP 2
1.2.3.0/24
26
Multi-Homing With BGP
• Inbound traffic
– Originate the prefix to both providers
– Do not allow traffic from one ISP to another
• Outbound traffic
– Select the “best” route for each remote prefix
– Define BGP policies based on load, performance, cost
ISP 1
ISP 2
BGP sessions
1.2.3.0/24
“Intelligent route
control” or “multihomed traffic
engineering”.
27
Interconnecting Multiple
Enterprise Sites
28
Challenges
• Challenges of interconnecting multiple sites
– Performance
– Reliability
– Security
– Privacy
• Solutions
– Connecting via the Internet using secure tunnels
– Virtual Private Network (VPN) service
– Dedicated backbone between sites
29
Connecting Via the Internet
• Each site connects to the Internet
– Encrypted tunnel between each pair of sites
– Packet filtering to block unwanted traffic
– But, no performance or reliability guarantees
Site 1
Internet
Site 2
Site 3
30
Virtual Private Network (VPN)
• Each site connects to a common VPN provider
– Provider allows each site to announce IP prefixes
– Separate routing/forwarding table for each customer
– Performance guarantees by overprovisioning resources
Site 1
VPN Provider
Site 2
Site 3
31
Conclusions
• Simple enterprise network is (mostly) plug and
play
– Ethernet with MAC learning and spanning tree
– DHCP server to assign IP addresses from single subnet
– Gateway router with default route to the Internet
• Quickly starts to require configuration
– Choosing the root bridge in the spanning tree
– Consistent configuration of DHCP and IP routers
– VLAN access and trunk link configuration
– Access control for traffic between VLANs
– BGP sessions and routing policy
• Discussion of the two papers
32
Discussion
• Flat vs. hierarchical addressing?
• Roles of the end host vs. the network?
• How to best support flexible policies?
• Alternatives or extensions to VLANs?
33
Backup Slides on VLAN Survey
34
Uses of VLANs
• Scoping broadcast traffic
• Simplifying access control policies
• Decentralizing network management
• Enabling host mobility
35
Problem: Limited Granularity
• Limited number of VLANs
– Placing multiple groups in the same VLAN
– Reusing limited VLAN
• Limited number of hosts per VLAN
– Divide a large group into multiple VLANs
• One VLAN per access port
– Supporting VLANs on the end host
– Supporting multiple groups at the router
36
Problem: Complex Configuration
• Host address assignment
– Wasting IP addresses
– Complex host address assignment
• Spanning tree computation
– Limitation of automated trunk configuration
– Enabling extra links to survive failures
– Distributing load over the root bridges
37
Backup Slides on SEATTLE
38
Avoiding Flooding
• Bridging uses flooding as a routing scheme
– Unicast frames to unknown destinations are flooded
“Don’t know where destination
is.”
“Send it everywhere!
At least, they’ll learn
where the source is.”
– Does not scale to a large network
• Objective #1: Unicast unicast traffic
– Need a control-plane mechanism to discover and
disseminate hosts’ location information
Restraining Broadcasting
• Liberal use of broadcasting for bootstrapping
(DHCP and ARP)
– Broadcasting is a vestige of
shared-medium Ethernet
– Very serious overhead in
switched networks
• Objective #2: Support unicast-based bootstrapping
– Need a directory service
• Sub-objective #2.1: Yet, support general broadcast
– Nonetheless, handling broadcast should be more scalable
Keeping Forwarding Tables Small
• Flooding and self-learning lead to unnecessarily
large forwarding tables
– Large tables are not only inefficient, but also dangerous
• Objective #3: Install hosts’ location information
only when and where it is needed
– Need a reactive resolution scheme
– Enterprise traffic patterns are better-suited to reactive
resolution
Ensuring Optimal Forwarding Paths
• Spanning tree avoids broadcast storms.
But, forwarding along a single tree is inefficient.
– Poor load balancing and longer paths
– Multiple spanning trees are insufficient
and expensive
• Objective #4: Utilize shortest paths
– Need a routing protocol
• Sub-objective #4.1: Prevent broadcast storms
– Need an alternative measure to prevent broadcast
storms
Backwards Compatibility
• Objective #5: Do not modify end-hosts
– From end-hosts’ view, network must work the same way
– End hosts should
 Use the same protocol stacks and applications
 Not be forced to run an additional protocol
SEATTLE in a Slide
• Flat addressing of end-hosts
– Switches use hosts’ MAC addresses for routing
– Ensures zero-configuration and backwards-compatibility (Obj # 5)
• Automated host discovery at the edge
– Switches detect the arrival/departure of hosts
– Obviates flooding and ensures scalability (Obj #1, 5)
• Hash-based on-demand resolution
– Hash deterministically maps a host to a switch
– Switches resolve end-hosts’ location and address via hashing
– Ensures scalability (Obj #1, 2, 3)
• Shortest-path forwarding between switches
– Switches run link-state routing to maintain only switch-level topology
(i.e., do not disseminate end-host information)
– Ensures data-plane efficiency (Obj #4)
How does it work?
x
Deliver to x
Host discovery
or registration
C
Optimized forwarding
directly from D to A
y
Traffic to x
A
Hash
(F(x) = B)
Tunnel to
egress node, A
Entire enterprise
(A large single IP subnet)
Switches
End-hosts
Control flow
Data flow
Tunnel to
relay switch, B
LS core
Notifying
<x, A> to D
Store B
<x, A> at B
D
Hash
(F(x) = B)
E
Terminology
Dst
x
< x, A >
shortest-path
forwarding
A
y
Src
Ingress
Egress
D
< x, A >
Relay (for x)
B
< x, A >
Ingress applies
a cache eviction policy
to this entry
Responding to Topology Changes
• The quality of hashing matters!
h
h
A
E
h
F
h
h
B
Consistent Hash minimizes
re-registration overhead
h
h
h
D
h
h
C
47
Single Hop Look-up
y sends traffic to x
y
x
A
E
Every switch on a ring is
logically one hop away
B
F(x)
D
C
48
Responding to Host Mobility
Old Dst
x
< x, G >
< x, A >
when shortest-path
forwarding is used
A
y
Src
D
< x, A >
< x, G >
Relay (for x)
New Dst
G
B
< x, G >
< x, A >
< x, G >
49
Unicast-based Bootstrapping: ARP
• ARP
– Ethernet: Broadcast requests
– SEATTLE: Hash-based on-demand address resolution
4. Broadcast
ARP req
for a
Owner of
(IPa ,maca)
b
sb
a
1. Host
discovery
sa
2. Hashing
6. Unicast
ARP req
to ra
F(IPa) = ra
5. Hashing
F(IPa) = ra
7. Unicast ARP reply
(IPa , maca , sa)
to ingress
Switch
End-host
Control msgs
ARP msgs
ra
3. Storing
(IPa ,maca , sa)
Unicast Bootstrapping: DHCP
• DHCP
– Ethernet: Broadcast requests and replies
– SEATTLE: Utilize DHCP relay agent (RFC 2131)
 Proxy resolution by ingress switches via unicasting
4. Broadcast
DHCP discovery
DHCP server
(macd=0xDHCP)
d
6. DHCP msg to r
8. Deliver DHCP
msg to d
1. Host
discovery
sd
2. Hashing
End-host
Control msgs
DHCP msgs
sh
5. Hashing
7. DHCP msg
to sd
F(macd) = r
Switch
h
r
3. Storing
(macd , sd)
F(0xDHCP) = r
Prototype Implementation
• Link-state routing: eXtensible Open Router Platform
• Host information management and traffic forwarding: Click
XORP
Click
Interface
Networ
k
Map
OSPF
Daemon
User/Kernel Click
Routing
Table
Ring
Manager
Host Info
Manager
Link-state advertisements
from other switches
Host info. registration
and notification messages
SeattleSwitch
Data Frames
Data Frames