Configuring Multicasting with Juniper EX switches (Part 1)

Configuring multicast routing using Protocol Independent Multicast in a all Juniper environment is as simple as the Cisco environment, but when I searched, I dint find good articles or KB’s explaining this, so I decided to write one.

I am fairly certain that if you have searched and arrived at this post, you know the basics of multicasting and IGMP, but yet, for the benefit of all readers, I will in brief describe the need for multicast. Please note, that this is just the IPv4 version of the story presented in a understandable manner and not all aspects of multicast are covered, but only the ones needed for this post.

What is Multicast ?

In IPv4 we have 3 kinds of packets,

• Unicast – One Source, One Destination
• Broadcast – One source and all destinations
• Multicast – One source and many destinations

Now, all of us are familiar with the first one, we use it almost every minute we are on a network connected equipment.

To, explain all this, lets choose different examples

1. Phone call : One person calls the other person, now this is unicast communication, one source one destination, most of the communication on the network is unicast

2. Shouting in a classroom : Broadcast, basically within the walls of the classroom all the people can hear you, this is basically a broad cast form of communication. In the network world, the wall of the classroom is basically the Layer 2 boundary as we all know that the moment broadcast hits a layer 3 device like a router or a firewall it is stopped.

3. Holding a meeting: Now this is MULTICAST, there are 2 restrictions, in this if you see, only people invited to the meeting will hear your conversations, as well as the conversations will be not heard beyond the wall of the meeting room (or the Layer 2 boundary)

Also, please think about which would you spend the least energy talking, Unicast is the least, followed by multicast and the highest energy is taken in broadcast. You can also see, that if you broadcasted the message which many people are not interested into, you are wasting their time (i.e) resources, so to alleviate the problem, multicast was created.

Why IGMP and Multicast Routing?

Though this blog doesn’t deal with a whole lot of multicast routing concepts, we will see, why do we need it. You know that in olden times, having a meeting in a room was more than enough, but as the business grow large and having multiple offices, you now know that the meeting needs to go out of the walls in a controlled manner, may be via a passcode authenticated bridge or a WebEx (or similar) or screen share , right ? it’s the same with Multicast, because multicast is used by multiple media applications, you may need to get out of the boundary of a layer 2 (VLAN) or even across the subnets across the internet to some other office, in this case, you will need a protocol to do that.

Applications of Multicast?

Multicast is normally used in media applications or video conferences. It’s a good idea to multicast them because they consume a lot of network bandwidth and if we broadcasted them it will create unnecessary havoc in the network

How present day switches treat multicast?

Present day switches use some thing called as IGMP-Snooping. Which is nothing else but listening to the IGMP messages being sent from a host. The IGMP messages contain the detail which mentions which multicast stream are they listening to, and with that info, it does ahead and forwards that particular stream to the host, else it prunes all other multicast traffic.

IGMP and its Snooping

IGMP (Internet Group Management Protocol) is basically a protocol, which sends messages about being interested or disinterested in a stream, they are normally sent between applications which support multicast (example VLC player) and the Multicast router on your network

The different messages are

• Membership Query
• Membership report
• Leave Group

So, its just 3 types of messages. The query is sent by the multicast router, in order to figure out if there is anyone who is interested in any multicast group , the report is sent by the client mentioning the groups that it is interested in and leave group message is the message sent by hosts to tell the router that it is no longer interested in a particular group.

Please note that IGMP and snooping by itself just works “inside the room” meaning inside the layer 2 boundary, if you have to take this to the layer 3 level, you will need a multicast protocol

PIM (Protocol Independent Multicast)

The PIM is a protocol, which is by far the most used protocol for multicast traffic across the Layer 3. There are 2 basic modes in which this protocol works

• Dense Mode
• Sparse Mode

There are combination of this, called sparse-dense mode, but we will not digress into those.

To explain dense mode, I would quote the example of you going into a room full of people and start speaking about some topic. You also mention that the people not interested can leave the room, this is exactly how the dense mode works. The multicast starts happening as a broadcast and then the people send out “Leave group” messages if they are not interested in the stream, so the pruning happens after the hosts respond.

The sparse mode is quite the opposite, wherein you actually tell people, please come into the room only if you are interested and then start talking, so people who are interested will start sending the “membership report” to join the group and only then the multicast stream will be forwarded to them

In most places only the sparse mode is used (and some time sparse-dense), but I haven’t seen dense mode be used so often, as a lot of older computers, they don’t send out a prune message to stop the stream.

Now, having understood the PIM, there is another term, I want you guys to understand and its perhaps the most important point. The Rendezvous point (RP in short), this point is basically the meeting point of the sender of the streams and the hosts interested in that stream.

Equipped with all the above information, lets take into account the Juniper EX switch configuration.

Multicast on Juniper

There are 2 ways you can do inter-vlan multicast on the EX switches

• PIM
• Multicast VLAN registration

The Multicast VLAN registration is the way to do it on the distribution layers only, which means, VLANS hosted in the same switch. So, it really cannot go over a WAN and do it at another site, but PIM on the other hand can do both.

Depending on your needs, just select one of the 2 methods

In the above diagram, if you only want to have the multicast within the clients of datacenter 1, then you can use either of the 2 methods, but if you want the multicast to travel across the layer 3 link to the data centre 2 , then you can only use PIM.

Configuring MVR on Juniper EX Switches

Considering the fact that the server switches and the Client switches are acting only on layer 2 mode, and the Inter vlan routing is happing on the core switches using RVI’s (which is the mostly the case), this configuration needs to go on the switches.

In the diagram, you can see the VLAN 10 as the server VLAN , where the streaming server sits and the VLAN 20 and 30 as the client VLANs (Again, please note the VLAN 40 and 50 will not get this traffic as we are using MVR)

Since I have said, so much, you should also be wondering, why bother with MVR, if the same can be done with the PIM. The answer is, MVR reduces the number of streams, assume that one client on vlan 20 and one client on VLAN 30 requests the stream, the switch will actually send 2 streams (one per vlan) if you use PIM, but in MVR, it only sends one stream there by making efficient use of the bandwidth available and again, you can use a igmp-proxy mode or a transparent mode.

[edit protocols igmp-snooping]
set vlan vlan10 data-forwarding source groups 225.10.0.0/16
set vlan vlan20 data-forwarding receiver source-vlans vlan10
set vlan vlan20 data-forwarding receiver install
set vlan vlan30 data-forwarding receiver source-vlans vlan10
set vlan vlan30 data-forwarding receiver install

So, you can see that in the transparent mode, you just configure this on all the switches, when you go to the igmp-proxy mode, you will have to use one extra line

[edit protocols igmp-snooping]
set vlan vlan10 proxy source-address 10.1.1.1

So, you are done. I have to confess, I don’t really use this mode.

PIM on EX switches

This is my favorite way to do multicast. I prefer the sparse mode and will show you how to configure it on Juniper EX switches

Steps

• Select a router to be the RP
• Set a loopback IP on that router (or L3 EX switch)
• Configure a RP protocol – I will use static here, but there are some options and variety of ways to use it. Static is the simplest to configure but it has the single point of failure issues
• Configure the RP
• Configure the layer 2 switches

In most cases, we will have redundant routers, so I am changing the topology a little bit

As you can see, I put in 2 core switches and made redundant connections on all the switches. Now, please note that you will need to configure Spanning tree protocol or its flavours to ensure a loop free network, that is not covered under this blog and we will assume that all of that is been taken care of

We have decided on the following

• RP : Core Switch 1
• Multicast Group : 225.0.30.0/24

Configuration on all the Layer 2 switches

The only configuration needed on the Layer 2 switches are that IGMP-snooping should be on

root@ServerSwitch01> show configuration protocols
igmp-snooping {
    vlan all;
}

The same configuration should be on all the Server and Client Switches (especially the client switch)

On the RP

• Create a Loopback
• Ensure the loopback is reachable from other devices (by adding it into appropriate routing)
• Configure PIM

root@COR01> show configuration interfaces lo0
unit 0 {
    family inet {
        address 10.0.0.200/32;
    }
}

{master:0}
root@COR01>
root@COR01> show configuration protocols ospf
area 0.0.0.0 {
    interface lo0.0 {
        passive;
    }
}
root@COR01>
root@COR01> show configuration protocols pim
rp {
    local {
        address 10.0.0.200;
    }
}
interface all {
    mode sparse;
}

{master:0}

You can see that in this case, we have not mentioned a multicast range, so the whole 224.0.0.0/4 range will be used

On the other routers (Layer 3), we will use a static rp configuration, they don’t need a loopback, but they should be able to reach the loopback of this RP

root@COR02> show configuration protocols pim
rp {
    static {
        address 10.0.0.200;
    }
}
interface all {
    mode sparse;
}

{master:0}

The similar configuration is enough in the other devices. The multicast traffic should now be able to traverse between different vlans and even different datacentre



Here are a few commands to check and verify

On the Layer 2 switch

“show igmp-snooping membership detail”

This will show you that the IGMP snooping is working and see which client has requested for which group

root@clientSwitch1> show igmp-snooping membership detail
VLAN: Client_DATA Tag: 20 (Index: 2)
    Router interfaces:
        xe-0/1/0.0 dynamic Uptime: 4d 17:23 timeout: 235
   Group: 239.192.83.80
     ge-0/0/30.0 timeout: 240 Last reporter: 10.0.14.17 Receiver count: 1, Flags: <V2-hosts>
     ge-0/0/23.0 timeout: 242 Last reporter: 10.0.14.61 Receiver count: 1, Flags: <V2-hosts>
     ge-0/0/7.0 timeout: 246 Last reporter: 10.0.14.26 Receiver count: 1, Flags: <V2-hosts>
     ge-1/0/38.0 timeout: 248 Last reporter: 10.0.14.148 Receiver count: 1, Flags: <V2-hosts>
     ge-1/0/32.0 timeout: 248 Last reporter: 10.0.14.30 Receiver count: 1, Flags: <V2-hosts>
     ge-2/0/43.0 timeout: 244 Last reporter: 10.0.14.56 Receiver count: 1, Flags: <V2-hosts>
     ge-4/0/3.0 timeout: 243 Last reporter: 10.0.14.174 Receiver count: 1, Flags: <V2-hosts>
     ge-1/0/18.0 timeout: 242 Last reporter: 10.0.14.22 Receiver count: 1, Flags: <V2-hosts>
     ge-1/0/3.0 timeout: 242 Last reporter: 10.0.14.130 Receiver count: 1, Flags: <V2-hosts>
     ge-1/0/37.0 timeout: 244 Last reporter: 10.0.14.36 Receiver count: 1, Flags: <V2-hosts>

Here you can see which are the clients requesting for the group



On the Layer 3 devices

show pim interfaces – This command will show the interfaces on which PIM is running and the neighbors and the designated router

show pim join extensive – This command will show the different vlans where the streams are being forwarded

Group: 225.0.30.253
    Source: 10.0.10.252
    Flags: sparse,spt
    Upstream interface: vlan.10
    Upstream neighbor: Direct
    Upstream state: None, Local Source, Local RP
    Keepalive timeout: 332
    Uptime: 1d 18:25:48
    Downstream neighbors:
        Interface: ge-0/0/37.0 (pruned)
            10.0.70.11 State: Prune Flags: SR Timeout: 208
            Uptime: 1d 17:28:31 Time since last Prune: 00:00:02

Ensure the vlans are getting the traffic, this will happen only if the IGMP-snooping and the IGMP join messages reach the RP

show pim rps extensive

This is a very important command to check the status of RP and all the multicast groups associated with the RP

root@PDX-SWIT-COR01> show pim rps extensive
Instance: PIM.master
Address family INET

RP: 10.0.0.200
Learned via: static configuration
Time Active: 4d 16:00:43
Holdtime: 0
Device Index: 26
Subunit: 32769
Interface: pimd.32769
Static RP Override: Off
Group Ranges:
        224.0.0.0/4
Register State for RP:
Group           Source          FirstHop        RP Address      State    Timeout
225.0.30.253    10.0.10.252     10.0.0.201     10.0.0.200     Receive        0
228.1.2.1       10.0.30.83       10.0.0.201     10.0.0.200     Receive      180

I hope this blog helped you get started on multicast on Juniper devices . please let me know if you have questions or comments. I will write on some advanced configuration in the future parts