Notes - Columbia University
Download
Report
Transcript Notes - Columbia University
W4140 Network Laboratory
Lecture 10
Nov 30 - Fall 2006
Shlomo Hershkop
Columbia University
Announcements
Phase I due today
Thanksgiving
I will get you feedback over the week
Start to plan for phase II
No lab scheduled
Lab 7 report due on Monday after break
Please do reading
Any issues ?
Overview
Next :
We will be running short labs on specific network devices
This week:
Next week
Plan Phase II once you get feedback
Review CISCO IOS docs
Next week I will give you an in depth overview of CISCO routers
from the ground up
Cisco router lab
Following week:
Man in the middle attacks
Cisco Lab Overview
A) Select one router and one PC from a rack (PC1 &
Router1 etc).
B) Connect one of the PC cards with the router and
setup the interfaces appropriately.
C) Connect the one of the PC cards to a Hub and the
Hub to the CS network. Make sure that the other teams
working on the same rack use the same hub
D) Get a DHCP address from the CS-network
E) Setup the vty's of the router to have a password that you know.
F) After setting up the PC and the router try to connect to the router's
VTY using ssh to the PC and then telnet to the IP address of the
router.
G) Now that you have access to the router do the following:
a) Setup a tftp server on the PC
b) Save the startup router configuration to the tftp server
c) Save the running configuration to the tftp server
d) Upgrade the router's flash (ask me where to get the file).
H) Modify the running-configuration to have a new enable password.
Save the running configuration to a file. What do you notice about
the password?
I) Load from the tftp server the running configuration that
you had saved in step g.c to the running configuration of
the server.
J) Find the commands that display the router's memory
and CPU utilization.
- How do we find out if an interface is working properly?
- How do we restrict access to the tftp server?
One of the reasons we are doing all this will be to get a
feel for current technology and explore future tech
Example: unicast vs multicast
Anycast: BGP (another time)
If you want to reach a single machine from anywhere
Ping is your friend
What happens ???
Internet2
Multicast Workshop
Columbia University, New York, NY
December 2005
Engineering Workshops
9
Acknowledgements
Greg Shepherd
Beau Williamson
Marshall Eubanks
Bill Nickless
Caren Litvanyi
Patrick Dorn
Leonard Giuliano
Alan Crosswell
Debbie Fligor
Mitch Kutzko
Matt Davy
Yul Pyun
Stig Venaas
University of Oregon
Columbia University
NYSERNet
Cisco Systems
Juniper Networks
Engineering Workshops
10
Contents
• Overview
• Multicast on the LAN
• Source-Specific Multicast (SSM)
• Any-Source Multicast (ASM)
– Intra-domain ASM
– Inter-domain ASM
• Troubleshooting Methodology
• Best Current Practices; Future of Multicast
Engineering Workshops
11
Overview
Engineering Workshops
12
The Basic Idea
Instead of sending a separate copy
of the data for each recipient, the source
sends the data only once, and routers
along the way to the destinations
make copies as needed.
Unicast does mass mailings;
multicast does chain letters.
Engineering Workshops
13
Unicast vs. Multicast
Unicast
Multicast
Engineering Workshops
14
The MBone
• The original multicast network was called the MBone. It used
a simple routing protocol called DVMRP (Distance Vector
Multicast Routing Protocol).
• As there were only isolated subnetworks that wanted to deal
with DVMRP, the old MBone used tunnels to get multicast
traffic between DVMRP subnetworks.
– i.e., the multicast traffic was hidden and sent between the
subnetworks via unicast.
• This mechanism was simple, but required manual
administration and absolutely could not scale to the entire
Internet.
• Worse, DVMRP requires substantial routing traffic behind
the scenes and this grew with the size of the MBone.
– Thus, the legend grew that multicast was a
bandwidth hog.
Engineering Workshops
Multicast Grows Up
• Starting about 1997, the building blocks for a multicast-enabled
Internet were put into place.
–An efficient modern multicast routing protocol, Protocol
Independent Multicast - Sparse Mode (PIM-SM), was
deployed. (PIM also has Dense and Sparse-Dense modes, but
these are not widely used.)
–The mechanisms for multicast peering were established, using
an extension to BGP called Multiprotocol BGP (MBGP), and
peering became routine.
–The service model was split into:
• a one-to-many (or “broadcast”) part:
a many-to-many part (e.g., for videoconferencing):
Any-Source Multicast (ASM), and
• Source-Specific Multicast (SSM).
• By 2001, these had completely replaced the old MBone.
Engineering Workshops
15
What capabilities does
IP Multicast provide ?
• Cost-efficient distribution of data
• Timely distribution of data
• Robust distribution of data
“Data” here could be
– Files
– Streamed Audio or Video
Engineering Workshops
16
17
Cost Efficient Data Distribution
• This is the core of the streaming case.
– Unicast streaming is just too expensive.
– This is true either on the commodity Internet
or on the Intranet.
– Multicast is especially compelling for video.
Engineering Workshops
18
Timely Distribution of Data
• This is the argument for multicast in
financial services.
• In unicast, it takes time to send packets
separately to each receiver.
– Even if cost is not a problem, time may be.
– Example: A DS3 would take 2 days to
distribute a 100 megabyte file to 10,000
desktops. With multicast, this would take 18
seconds.
– Multicasting is compelling here if timely
distribution is important.
Engineering Workshops
19
Robust Distribution of Data
• In some streaming or data distribution cases,
the problem is handling sudden large increases
in load.
• Multicast was designed to handle sudden large
increases in load.
Engineering Workshops
20
Case Study: 9/11/2001
Internet News “Melt-down”:
Web Site Performance 9:00 AM to 10:00 AM
Site % Users able to access
ABCNews.com
0%
CNN.com
0%
NYTimes.com
0%
USAToday.com
18 %
MSNBC.com
22 %
(source: Keynote’s Business Performance / Interactive Week 9/17/2001)
Engineering Workshops
21
Internet News Performance on 9/11/2001
• Of course, the “melt-down” was caused by the
incredible demand for news after the attacks.
• Unicast streaming web sites suffered similar
problems, at least from anecdotal evidence
• By contrast, multicast performed well
– Large increase in traffic
– Roughly 1 Gigabit per second saved at peak
– Over time, the multicast peering mesh degraded,
but this was NOT due to increased
traffic
Engineering
Workshops
22
Eyewitness Accounts
We had a large plasma screen in the iLabs [at Networld+Interop] intended to demonstrate
high rate HDTV over I2. We came in Tuesday morning and were preparing for the first day
of the show when word came in about the initial plane crash into the towers. Our I2 Lead,
Roy Hockett was able to switch the stream to a CNN broadcast from UMich. We began
attracting exhibitors to the display even before the showfloor opened. Once the attendees
were on the floor, the crowd had grown to well over a hundred.
By this point, three things had happened. The crowds around the one display had grown so
large as to constitute a fire hazard, all the major news web sites had completely melted
down, and CNN was being multicast from several sources. We then started loading
multicast tools on every PC in the NOC, from the one driving the large video wall to people's
individual laptops. By 10:30 (about half an hour after the floor opened) we had at least 3
large displays as well as a number of normal monitors turned out towards the plexiglass
walls.
Soon after, we had a good number of exhibitors come and ask how to get "the CNN viewer
software.”
— Jim Martin, <[email protected]>
More than 1,000 copies of StreamPlayerII, our multicast MPEG viewer, were downloaded or
handed out on disk between 9/11 and 9/12. We normally average 20 to 100 per day.
Engineering Workshops
— Rich Mavrogeanes <[email protected]>
23
Viewership
Sudden increase in Multicast
traffic of at least 1000 group
members
– Mostly viewing VBrick’s
television broadcast
– Measured viewership >830
– But each measured point
could have many individual
viewers since they multicast
locally
BANDWIDTH SAVED: in
excess of 1 Gbps vs. unicast
Crowds viewing the 9/11 multicasts at Networld+Interop
Engineering Workshops
24
How is Multicast Being Used Today?
•Network Video!
•Netcast Events, TV over IP,
Distance Learning, Collaboration
•See https://mail.internet2.edu/wws/arc/bigvideo/
•Other applications
•Some examples follow...
Engineering Workshops
25
Video: Netcast Events
• Technical events
– IETF, NANOG: see videolab.uoregon.edu
– Joint Techs:
http://jointtechs.es.net/vancouver2005/netcast.html
• Scientific events
– Undersea exploration with Robert Ballard:
www.explorethesea.com
• Performance events
– Digital Video Transport Service
(http://apps.internet2.edu/dvts.html) provides
relatively cheap & painless high-quality network
video, and is increasingly popular
for a wide variety of uses.
Engineering Workshops
– DVTS over multicast is ideal for netcasting
26
Video: TV over IP
• DV Guide: http://db.arts.usf.edu/dvguide/
• ResearchChannel:
www.researchchannel.org/projects/i2wg/prj_multi.a
sp
• Northwestern University
– Cable TV via campus networks:
http://www.tss.northwestern.edu/nutv/helpguide/
– C-SPAN over Abilene:
http://www.i2-multicast.northwestern.edu/
• Several other campuses (Cornell, Columbia,
Duke...) have TV-over-IP projects, or are
considering them
• Open Student Television Network
Engineering Workshops
– www.ostn.tv
27
Video: TV over IP
• Set-top boxes are available from several
vendors, e.g.:
– www.vbrick.com/products/EtherneTV-stb.asp
– www.aminocom.com
– www.i3micro.com
– www.2wire.com
– www.bastinc.com
• Some corporations, particularly in the financial
sector, pay big bucks to have cable news
multicast on their intranets. Engineering Workshops
28
Video: Distance Learning
• University of Hawaii uses multicast in its
Hawaii Interactive Television Service
– http://www.hawaii.edu/dl/general/
– Two-way interactive video and audio to all UH
campuses and education centers
– Each classroom can view and converse with at
least two other sites, and listen to additional sites
– Each campus can receive and transmit multiple
classes simultaneously
Engineering Workshops
29
Video: Distance Learning
U. of Hawaii
Interactive
TV Locations
and Staff
Sites
Engineering Workshops
30
Video: Collaboration
Access Grid:
• www.accessgrid.org: "The Access Grid® is an
ensemble of resources...used to support groupto-group interactions across the Grid."
• survey of AG multicast issues:
www.andrewpatrick.ca/multicast-survey/
• Access Grid via VRVS:
http://www.vrvs.org/Documentation/VAG/
Engineering Workshops
31
Other Applications
• While it seems clear that the killer app for
multicast will involve video, there are other
things you can do with it...
– radio: www.onthei.com, www.kexp.org
– file distribution (a popular intranet ASM application)
– NNTP
• Please keep us informed about your current and
planned applications!
– See https://mail.internet2.edu/wws/arc/wg-multicast
Engineering Workshops
Essential Multicast Terminology
IP source = IP unicast addr
Ethernet source = MAC addr
source
IP destination = IP multicast addr
Ethernet dest = MAC addr
32
receivers
e.g., video server
Multicast stream
source = origin of multicast stream
multicast address = an IP address in the Class D range (224.0.0.0 – 239.255.255.255), used to
refer to multiple recipients. A multicast address is also called a multicast group
or channel.
multicast stream = stream of IP packets with multicast address for IP destination address. All
multicast uses UDP packets.
receiver(s) = recipient(s) of multicast stream
tree = the path taken by multicast data. Routing loops are not allowed, so there is always a
unique series of branches between the root of the tree and the receivers.
Engineering Workshops
33
(S,G) notation
• For every multicast source there must be
two pieces of information: the source IP
address, S, and the group address, G.
– These correspond to the sender and receiver
addresses in unicast.
– This is generally expressed as (S,G).
– Also commonly used is (*,G) - every source
for a particular group.
Engineering Workshops
34
Multicast Building Blocks
• The SENDERS send without worrying about
receivers
– Packets are sent to a multicast address (RFC 1700)
– This is in the class D range
(224.0.0.0 - 239.255.255.255)
• The RECEIVERS inform the routers what they
want to receive
– done via Internet Group Management Protocol
(IGMP), version 2 (RFC 2236) or later
• The routers make sure the STREAMS make it
Engineering Workshops
to the correct receiving networks.
35
Multicast Protocol Summary
• Essential Protocols
– PIM-SM - Protocol Independent Multicast - Sparse Mode
is used to propagate forwarding state between routers.
– IGMP - Internet Group Management Protocol is used by
hosts and routers to tell each other about group
membership.
• Other Protocols (much more on these later in
the workshop)
– MBGP - Multiprotocol Border Gateway Protocol is used
to exchange routing information for inter-domain
reverse-path forwarding (RPF) checking.
– MSDP - Multicast Source Discovery Protocol is used to
exchange active-source information.
Engineering Workshops
36
Multicast Addressing
• IPv4 Multicast Group Addresses
– 224.0.0.0–239.255.255.255
– Class D Address Space
• High order bits of 1st Octet = “1110”
– Source sends to group address
– Receivers receive traffic sent to group address
Engineering Workshops
37
CIDR Address Notation
• The multicast address block is 224.0.0.0 to
239.255.255.255
• It is cumbersome to refer to address blocks in the
above fashion. Address blocks are usually
described using
“CIDR notation”
– This specifies the start of a block, and the number of bits
THAT ARE FIXED.
• In this shorthand, the multicast address space can be described
as 224.0.0.0/4 or, even more simply, as 224/4. The fixed part of
the address is referred to as the prefix, and this block would be
pronounced "two twenty four slash four."
– Note that the LARGER the number after the slash, the
LONGER the prefix and the SMALLER the address block.
Engineering Workshops
38
Multicast Addressing
• RFC 3171
• http://www.iana.org/assignments/multicast-addresses
• Examples:
– 224.0.0.0 - 224.0.0.255 (224.0.0/24) - reserved &
not forwarded
• 224.0.0.1 - All local hosts
• 224.0.0.2 - All local routers
• 224.0.0.4 - DVMRP
• 224.0.0.5 - OSPF
• 224.0.0.6 - Designated Router OSPF
• 224.0.0.9 - RIP2
• 224.0.0.13 - PIM
• 224.0.0.18 - VRRP
• 224.0.0.22 – IGMP
– 232.0.0.0 - 232.255.255.255 (232/8) - SSM
Engineering Workshops
– 239.0.0.0 - 239.255.255.255 (239/8) -
39
Scoping
• TTL value defines scope and limits distribution
– IP multicast packet must have TTL > interface
TTL or it is discarded
– No longer recommended as a reliable scoping
mechanism
• Administratively Scoped Addresses – RFC 2365
– 239.0.0.0–239.255.255.255
– Private address space
• Similar to RFC 1918 unicast addresses
• Not used for global Internet traffic
• Used to limit “scope” of multicast traffic
• Same addresses may be in used in different sub-networks
for different multicast sessions
– Examples
• Site-local scope: 239.253.0.0/16
• Organization-local scope: 239.192.0.0/14
Engineering Workshops
40
Multicast Address Allocation
• For a long time, this was a sore spot. There
was no way to claim or register a Multicast
Class D address like unicast address blocks
can be registered.
– For temporary teleconferences, this is not such a
problem, but it does not fit well into a broadcast model.
• Now, there are two solutions:
– For SSM, addresses don’t matter, as the broadcast
address is really unique as long as the (S,G) pair is
unique.
– For ASM, there is “GLOP”.
Engineering Workshops
41
Multicast Addressing
GLOP addresses
– Provides globally available private Class D
space
– 233.x.x/24 per AS number
– RFC 2770
How?
– Insert the 16-bit AS number into the
middle two octets of the 233/8
– Online GLOP calculator:
www.shepfarm.com/multicast/glop.html
– If you have an AS, you have multicast
addresses.
Engineering Workshops
Expanding Multicast
Address Assignment
• GLOP based address assignment has
worked well.
– Every organization gets the same amount of
space, a /24.
• What if you need more?
– There is an (as yet unused) mechanism for
requesting more GLOP space: RFC 3138.
– Is this unused because of lack of demand, or
because the mechanism is not fully
implemented?
Engineering Workshops
42
43
Prefix-based Multicast
Address Assignment
• Dave Thaler of Microsoft has proposed prefix-based
assignment.
– draft-ietf-mboned-ipv4-uni-based-mcast02.txt
• The idea is that every unicast address assignment you have
is mapped into a multicast address range.
– Take one of the unused multicast /8's
– For a /N unicast assignment, the multicast
address block becomes
• [/8] [/N][24 - N bits of available addresses]
Engineering
Workshops
– So, a /24 provides a /32; a /16
provides
a /24;