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
image
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

image



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

Comments

  1. Most precise way of describing such things.but i had some query with a case that multicast traffic was sometimes receiving n sometimes not in layer 2 ckts.so what things we should check???

    ReplyDelete
    Replies
    1. Multiple rreasons

      1. Plain old connectivity problems , flaky/bad cables, etc, where the source is flaky (You could check if all the clients stop recieving traffic in the same time)
      2. It could be with the IGMP snooping - Use MVR and see if it works, disable snooping effectively broad casting ,if that works, in that case, you may need a code upgrade, follow up with JTAC or some thing

      If you have more info, do let me know and I can help in troubleshooting ... sorry about the late reply though ...


      Thanks

      Delete
  2. Hi, thanks for the explanation, however I would like to find out in the above diagram with 3 core switches, how many multicast groups generated in Core Switch 1 if Client 1 (VLAN 20) and Client 2 (VLAN 30) requested the same stream from streaming server? Assuming PIM-SM is used here.

    Thank you.

    ReplyDelete
    Replies
    1. In the config above, I have not done things ideally, I have created a single multicast group of the entire multicast address range, which means, the core1 will be the RP for all the streams that are sent and all the people will have to be coming to core1 for the stream.

      Hopefully, I understood the question right ... Thanks

      Delete
  3. I have a question about multicast groups and VLANs - can a trunk be setup to carry the multicast traffic?

    ReplyDelete
    Replies
    1. Hi Kevin,

      Sorry for the delay, do you mean you want to setup a single physical cable/trunk to carry the multicast traffic ?

      Delete
  4. I found your article very helpful for configuring MVR. I am now trying to configure PIM.

    My setup
    Source -> Access port VLAN 4000 -> EX 3200 -> Access port VLAN 4010 -> Edge device IP: 192.168.101.0/24

    how do I make "Ensure the loopback is reachable from other devices (by adding it into appropriate routing)"??
    Do I need routes from both VLAN's(4000,4010) back to the loopback device?

    Thanks

    ReplyDelete
    Replies
    1. Hi krobinson,

      If its a direct connection (through a L3 switch using RVI's across vlans ), all you need to do is create a Loop back interface in the Ex3200, bu default the swtch should be able to reach it,

      You will have to add it in OSPF or some thing if you need other subnets (or vlans) that are not having a RVI



      for example

      On ex 3200 (just sample config)

      [edit interface ge-0/0/0]
      unit 0 {
      family ethernet-switching {
      description "***** This is where the source connects ****"
      port mode access
      vlan members vlan_4000
      }
      }
      [edit interface ge-0/0/1]
      unit 0 {
      family ethernet-switching {
      description *** This is the client ****"
      port mode access
      vlan members vlan_4010
      }
      }

      set interface vlan.4000 family inet address 10.40.0.1/24
      set interface vlan.4010 family inet address 10.40.10.1/24

      [edit vlans]
      vlan_4000
      id 4000
      l3-interface vlan.4000
      vlan_4010
      id 4010
      l3-interface vlan.4010



      Then in that case, just create a loopback interface, this will already be the connected interface of the switch and doesnt need to be advertised.

      The PIM should then work

      I hope this is helpful


      Delete
  5. Hi ,

    This article is very well explained.

    I myself is struggling to configure EX4500 to allow multicast traffic across the VLANs. I have enabled PIM sparse mode and have the gateway of VLAN connected to the multicast source as RP. IGMP snooping is enabled on all the VLANs. However, I still do not see the multicast traffic across the VLANs. Could you help me with a sample configuration to do this, please?

    ReplyDelete
    Replies
    1. Could you post your network diagram and relavent config, we could try and help then

      Delete
    2. Hey, Thanks for your response and apologies for a delayed response. I was able to resolve the issue myself. Was a configuration issue.
      Do you have experience of setting up multicast traffic between Cisco and Juniper EX series switches?

      Delete
  6. Thanks for the easy to read article.

    How would I go about figuring out my Multicast group for my server when setting up MVR? My multicast server (IP camera) has a multicast IP of 239.192.0.200 which looks like a host address instead of a network address as shown in your CLI command "set vlan vlan10 data-forwarding source groups 225.10.0.0/16". Any thoughts?

    ReplyDelete
    Replies
    1. 239.192.0.200/32 should do it ... (Or you can use a subnet that includes this IP) Let me know how it goes

      Delete
  7. Thank for the useful artical!
    I still wonder about " 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"
    From my opinion, the MVR has to send 2 streams as well (1 for client sw1 and the other for client sw2)
    Could you help clarify!

    ReplyDelete
    Replies
    1. Hi,

      What I meant was the following

      Say the connections are as follow

      Client 1 <-> Switch 1 <-> switch2 <-> Server
      Client 2 <-> Switch 1 <-> switch2 <-> Server

      So, both the client 1 and 2 are connected to the switch 1. If you use PIM, the switch 2 will send 2 streams to switch 1, but with MVR, switch 2 to switch 1 will be a single stream, which will then be forwarded to both the clients

      Delete
  8. Hi All,

    I´m try to install MVR but I have doubts. First one, the server stream will accept trunk? I did see in Juniper Forum that MVR only perform with Trunk on source side. Is it True? I´m use IRD Cisco D9824.

    ReplyDelete

Post a Comment

Popular posts from this blog

Juniper Aggregate Interfaces (LACP/No LACP)

HA Proxy for Exchange 2010 Deployment & SMTP Restriction