in this article i

5
8/6/2019 In This Article I http://slidepdf.com/reader/full/in-this-article-i 1/5

Upload: shaluprak

Post on 08-Apr-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: In This Article I

8/6/2019 In This Article I

http://slidepdf.com/reader/full/in-this-article-i 1/5

Page 2: In This Article I

8/6/2019 In This Article I

http://slidepdf.com/reader/full/in-this-article-i 2/5

 

RouterA receives a packet a on Fa0/1, from HostC. RouterA takes the source IP and then does aroute lookup on how to get back to HostC. If the route points out Fa0/1, then the RPF check 

 passes. If for some reason, it pointed out another interface, then the RPF check would fail.

There are other methods to ensure the RPF check passes, such as tweaking unicast routing,

utilizing static mroutes, or mBGP, but those are outside the scope of this discussion. I highlyrecommend Marko Milivojevic's series of blogs over at IPExpert that discuss overcoming RPF

Check failures if you want to dive further into this topic.

IGMP 

IGMP allows hosts to communicate with network entities such as routers, to make known their 

desire to receive multicast traffic on specific groups. IGMPv1, IGMPv2, and IGMPv3 all exist,and support various features between them; IGMPv2 is the popularly deployed revision right

now. IGMPv3 requires a lot of application support to operate effectively, which hasn't really been seen so far.

There are some mechanisms in place that allow routers and switches to optimize the process of further refining the forwarding path of multicast traffic. One is Cisco¶s CGMP ± Cisco Group

Management Protocol ± which defines a method for switches and routers to communicate withone another so that way the switches can maintain a host table for who has joined a group. The

other is IGMP snooping, which allows switches to peek into IGMP join messages and then builds a host table based on the information it gleans. This allows switches to forward multicast

feeds only on ports it knows interested hosts are connected to.

Short and sweet: IGMP lets hosts join the group to receive traffic. Routers will take IGMP

requests and tranlsate those into PIM-JOIN messages...which brings us to our next topic -Protocol Independant Multicast.

PIM 

Page 3: In This Article I

8/6/2019 In This Article I

http://slidepdf.com/reader/full/in-this-article-i 3/5

PIM is a protocol that communicates multicast source and destination information betweenrouters within a network, allowing them to forward or not forward traffic, based on that

information. How they accomplish that depends on the mode of operation, which can be one of three modes: Sparse Mode, Dense Mode, or Sparse-Dense Mode. Each mode has it's own

 benefits and drawbacks, which I'll discuss next. PIM operates in such a way that it is agnostic to

which unicast routing protocol you are running, so long as reachability is provided and theunicast routing table is made available for RPF checks. This avoids the need to deploy a newrouting protocol in your network just to support multicast, easing the implementation and

adoption. This is simply another service that takes advantage of your core connectivity.

SparseMode 

Sparse Mode is the best-case scenario in many ways, it looks to forward traffic only when

requested. Sparse mode initially leverages the Shared Tree in distributing multicast feeds to hosts

that elect to receive them. This implies that something must keep track of each group andwhether it has been requested - this role falls to the Rendezvous Point, aka the RP. The RP isadministratively designated, and is often placed in a centralized position within the network to

ensure it has the best opportunity to control traffic. The RP will receive source advertisements(which is actually a leaf PIM router saying they have an active source) and will record that info.

If the RP knows of a destination - which in this case would be another PIM-enabled router - thatwishes to receive that traffic, it will forward the traffic from the source on to that destination,

forming what is known as the shared tree. This "shared tree" keeps the RP in the path and allowsit to distribute the traffic only out interfaces which it has received a PIM-JOIN message from.

Each PIM router in the path between the RP and the destination will have already seen the PIM-Join and will know to forward the traffic. With this design, traffic will not be replicated and

forwarded unless someone requests it, which keeps bandwidth utilization down to a minimum.

DenseMode 

There are cases when Sparse Mode may not be the best choice - albeit those times are rare these

days. If you have lots of receivers across your network, and only a few people wish not toreceive it, then Sparse Mode may seem like an awful lot of work just to save the bandwidth on

those few links. If you want to push data to everyone in a given network, dense mode may beyour ticket. Dense mode assumes from the beginning that EVERYONE wants this data, and

 pushes it to every leaf node out every interface. Eventually PIM prunes these nodes which haveno interested destinations, but for a time the traffic will be replicated until that process

completes. I've not seen dense mode used often, quite frankly, and even in the few cases whereit was deployed, Sparse-Dense mode could have been used.

Sparse-DenseMode 

Page 4: In This Article I

8/6/2019 In This Article I

http://slidepdf.com/reader/full/in-this-article-i 4/5

This brings us to the hybrid - Sparse-Dense mode. Sparse-Dense mode operates in both modes -on a per-group basis. If an RP exists for a given group, it will operate in Sparse Mode. If no RP

is set for a group, then it operates in Dense Mode, for that group. Pretty simple, right? Right.

The main caveat to multicast which makes this mode of operation useful is Auto-RP. Auto-RP isa method of dynamically advertising the RP for a given group within sparse mode, so that you do

not have to configure every PIM router in the environment each time you deploy a new group.Auto-RP speaks on 224.0.1.39, and 224.0.1.40, and does so in a dense fashion - talking to every

PIM router in the domain as it is an advertisement. There is indeed a work-around to this whichyou can implement in Sparse Mode, but that requires making a change on each PIM router, albeit

only once. By deploying PIM in a sparse-dense mode from the beginning, not only will Auto-RPwork without a workaround, but you will support sparse mode operation and also allowing

groups to fall back into dense mode if necessary.

 Now that we¶ve discussed IGMP, PIM, RPF checks, you should be better prepared to tackle

multicast! As I said at the beginning of the article, this was merely an introduction ± a brief oneat that ± and should just whet your appetite! Here are a few links and books you can take a look 

at to further your understanding of what is a really elegant solution to intelligently multiplexingtraffic.

Cisco DocCD for 12.4T IOS Train ::

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/12_4t/imc_12_4t_book.html 

Cisco IP Multicast Home ::

http://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html 

Page 5: In This Article I

8/6/2019 In This Article I

http://slidepdf.com/reader/full/in-this-article-i 5/5

Cisco Press Interdomain Multicast Solutions Guide ::http://www.ciscopress.com/bookstore/product.asp?isbn=1587050838