This is the first in a series of multicast discussions that I will be posting. The next series will discuss sparse-dense mode inside a JUNOS virtual-router (VR) and then dense mode inside a VR with trunked core instead of L3 core.
First, let's start with the diagram of the lab i'm working with. There are 5 ex2200-c's in a very simple configuration with two Acer laptops hanging off of each access switches. The laptops are running iperf on CentOS 6.6 (which is very easy to install and use).
Let's take a look at the lab: (*NOTE: All devices are running 14.1X53-D26.2)
As you can see this is a typical Core, Aggregation, Access design. I'll throw another switch in to create some spanning-tree later.
DISCUSSION:
You can read all of the nitty gritty technical details about PIM sparse mode from RFC 2362
PIM MODES:
There are three modes for Protocol Independent Multicast (PIM): Sparse, Sparse-Dense and Dense. This post will focus on sparse mode only.
IGMP:
Internet Group Management Protocol (IGMP). Any discussion about PIM needs to include an understanding of RFC 2236 and RFC 3376 which are IGMP version 2 and version 3 respectively.
•IGMP is the protocol used by
receivers to report group membership to the next hop neighbor or directly
attached gateway.
•Coincidently the Next hop
neighbor is the Last Hop (LH) router in the multicast tree.
•IGMP Group membership messages
express the desire to receive traffic destined for a group or
multiple groups.
•A
single receiver can subscribe to one or many groups
•Also
a receiver can specify which source they want to receive multicast traffic
from.
•IGMP is the protocol used between
Routers and Hosts.
IGMP-SNOOPING:
RFC 3376 has a section discussing report suppression.
Multicast flows from S to G:
•Multicast flows from a given
Source (S) to a Group of multicast receivers (G).
•The flow of multicast is most
typically modeled as an upside down tree with the source being the root
and the
groups being the leaves.
•Multicast traffic is distributed
to the leaves by routers at the branching points of the tree.
•Sources are the roots of the tree
and Groups are the leaves of the tree.
•There can be many source and
groups on a given network.
Multicast Packets:
•Have a UNICAST source address
•MULTICAST destination address
•Encompassed by 224/4
•224.0.0.1 – 239.255.255.255
•224.0.0.1 – 224.0.0.255 not routable
•These are used for signaling for OSPF
etc.
For this post I will be using the multicast address of 239.100.100.110 which as you can see from the
above that it falls into the routable/usable addresses.
NETWORK:
Let's now take a look at the IP addresses used in the lab.
Acer2 to AGG-1 vlan.100 172.16.100.0/30
Acer1 to AGG-2 vlan.200 172.16.200.0/30
ACCESS-1 ge-0/0/0 to AGG-1 ge-0/0/0 TRUNK
ACCESS-2 ge-0/1/0 to AGG-2 ge-0/1/0 TRUNK
AGG-1 ge-0/1/0 to CORE-1 ge-0/1/0 172.16.1.0/30
AGG-2 ge-0/1/1 to CORE-1 ge-0/1/1 172.16.1.4/30
VLAN CONFIGURATIONS:
AGG-1: (Gateway for 172.16.100.0/30)
set vlans V100 vlan-id 100
set vlans V100 l3-interface vlan.100
AGG-2: (Gateway for 172.16.200.0/30)
set vlans V200 vlan-id 200
set vlans V200 l3-interface vlan.200
ACCESS-1: (L2 VLAN to carry host to Aggregation gateway)
set vlans V100 vlan-id 100
ACCESS-2: (L2 VLAN to carry host to Aggregation gateway)
set vlans V200 vlan-id 200
INTERFACE CONFIGURATION:
CORE-1:
set interfaces ge-0/1/0 unit 0 family inet address 172.16.1.1/30
set interfaces ge-0/1/1 unit 0 family inet address 172.16.1.5/30
set interfaces lo0 unit 0 family inet address 10.0.0.1/32
set interfaces lo0 unit 0 family inet address 192.168.55.3/32 primary
AGG-1:
set interfaces ge-0/1/0 unit 0 family inet address 172.16.1.2/30
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members all
set interfaces vlan unit 100 family inet address 172.16.100.1/30
AGG-2:
set interfaces ge-0/1/1 unit 0 family inet address 172.16.1.6/30
set interfaces ge-0/1/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/0 unit 0 family ethernet-switching vlan members all
set interfaces vlan unit 200 family inet address 172.16.200.1/30
ACCESS-1:
set interfaces ge-0/0/8 unit 0 family ethernet-switching vlan members V100
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members all
ACCESS-2:
set interfaces ge-0/0/8 unit 0 family ethernet-switching vlan members V200
set interfaces ge-0/1/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/0 unit 0 family ethernet-switching vlan members all
OSPF:
AGG-1:
set protocols ospf export OSPF-DIRECT-STATIC-LOCAL
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface me0.0 disable
set protocols ospf area 0.0.0.0 interface vlan.100
AGG-2:
set protocols ospf export OSPF-DIRECT-STATIC-LOCAL
set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface me0.0 disable
set protocols ospf area 0.0.0.0 interface vlan.200
CORE-1:
set protocols ospf export OSPF-DIRECT-STATIC-LOCAL
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/1/0.0
set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
set protocols ospf area 0.0.0.0 interface me0.0 disable
OSPF EXPORT POLICY:
(*NOTE: You will notice the export policy OSPF-DIRECT-STATIC-LOCAL in the OSPF protocol
stanza. by default JUNOS will not export inet.0 routes by default so we need to export our direct
local and static routes so ospf will create the database)
This is just a simple export policy for the lab. JUNOS is so powerful that you can make this as
complicated as you want and I have seen some complicated policies. I like the KISS method for the
lab.
This same policy is applied to all core devices: CORE-1, AGG-1 and AGG-2. The L2 Access devices
will not be running any layer 3 or dynamic protocols.
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term NOOOB from interface me.0
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term NOOOB then reject
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term DIRECT from protocol direct
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term DIRECT then accept
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term LOCAL from protocol local
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term LOCAL then accept
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term STATIC from protocol static
set policy-options policy-statement OSPF-DIRECT-STATIC-LOCAL term STATIC then accept
Once the OSPF database converges I should be able to ping from the vlan.100 gateway to the iperf
client on 172.16.200.2.
run ping 172.16.200.2 source 172.16.100.1
PING 172.16.200.2 (172.16.200.2): 56 data bytes
64 bytes from 172.16.200.2: icmp_seq=0 ttl=62 time=3.075 ms
64 bytes from 172.16.200.2: icmp_seq=1 ttl=62 time=2.139 ms
64 bytes from 172.16.200.2: icmp_seq=2 ttl=62 time=2.107 ms
64 bytes from 172.16.200.2: icmp_seq=3 ttl=62 time=1.975 ms
^C
--- 172.16.200.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.975/2.324/3.075/0.438 ms
PROTOCOL INDEPENDENT MULTICAST (PIM):
CORE-1:
set protocols pim traceoptions file PIM-TRACE
set protocols pim traceoptions file size 1m
set protocols pim traceoptions file files 5
set protocols pim traceoptions flag all
set protocols pim rp local address 192.168.55.3
set protocols pim interface me0.0 disable
set protocols pim interface ge-0/1/0.0 family inet
set protocols pim interface ge-0/1/0.0 mode sparse
set protocols pim interface ge-0/1/0.0 version 2
set protocols pim interface ge-0/1/1.0 family inet
set protocols pim interface ge-0/1/1.0 mode sparse
set protocols pim interface ge-0/1/1.0 version 2
AGG-1:
set protocols pim traceoptions file PIM-TRACE
set protocols pim traceoptions file size 1m
set protocols pim traceoptions file files 5
set protocols pim traceoptions flag all
set protocols pim rp static address 192.168.55.3
set protocols pim interface me0.0 disable
set protocols pim interface ge-0/1/0.0 family inet
set protocols pim interface ge-0/1/0.0 mode sparse
set protocols pim interface ge-0/1/0.0 version 2
set protocols pim interface vlan.100 family inet
set protocols pim interface vlan.100 mode sparse
set protocols pim interface vlan.100 version 2
AGG-2:
set protocols pim traceoptions file PIM-TRACE
set protocols pim traceoptions file size 1m
set protocols pim traceoptions file files 5
set protocols pim traceoptions flag all
set protocols pim rp static address 192.168.55.3
set protocols pim interface me0.0 disable
set protocols pim interface ge-0/1/1.0 family inet
set protocols pim interface ge-0/1/1.0 mode sparse
set protocols pim interface ge-0/1/1.0 version 2
set protocols pim interface vlan.200 family inet
set protocols pim interface vlan.200 mode sparse
set protocols pim interface vlan.200 version 2
One thing to note is that with PIM sparse mode you will need to set a RP address. In the lab case I am using CORE-1 as the RP and have set a loopback of 192.168.55.3/32. The configuration on CORE-1 specifies the RP as local while the other Core devices AGG-1 and AGG-2 set the static keyword to tell PIM where the RP is.
IGMP:
ACCESS-1:
set protocols igmp interface ge-0/0/8.0
ACCESS-2:
set protocols igmp interface ge-0/0/8.0
AGG-1:
set protocols igmp traceoptions file IGMP-TRACE
set protocols igmp traceoptions file size 1m
set protocols igmp traceoptions file files 4
set protocols igmp traceoptions flag all
set protocols igmp interface vlan.100 accounting
set protocols igmp interface ge-0/0/0.0
AGG-2:
set protocols igmp traceoptions file IGMP-TRACE
set protocols igmp traceoptions file size 1m
set protocols igmp traceoptions file files 4
set protocols igmp traceoptions flag all
set protocols igmp accounting
set protocols igmp interface ge-0/1/0.0
set protocols igmp interface vlan.200
IGMP-SNOOPING:
(* The default for JUNOS is igmp-snooping vlan all)
ACCESS-1:
set protocols igmp-snooping vlan all
ACCESS-2:
set protocols igmp-snooping vlan all
AGG-1:
set protocols igmp-snooping vlan all
AGG-2:
set protocols igmp-snooping vlan all
CORE-1:
set protocols igmp-snooping vlan all
WOW WHAT A LOT OF WORK!
So now that we have all of the IP configuration, VLAN configuration, PIM and IGMP configuration in place CAN WE FINALLY PASS SOME MULTICAST TRAFFIC?!?!
Well hang on a second lets make sure it all is working first before we try to test multicast and it doesn't work. We need to check a few things.
#1 - Lets ping from the receiver to the source (in multicast terms) and vice verse.
SOURCE/SERVER
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 70:5A:B6:13:E5:E9
inet addr:172.16.100.2 Bcast:172.16.100.3 Mask:255.255.255.252
inet6 addr: fe80::725a:b6ff:fe13:e5e9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:64189 errors:0 dropped:0 overruns:0 frame:0
TX packets:5294 errors:0 dropped:0 overruns:0 carrier:7
collisions:0 txqueuelen:1000
RX bytes:88587511 (84.4 MiB) TX bytes:619379 (604.8 KiB)
[sreisinger@ACER2 ~]$ ping 172.16.200.2
PING 172.16.200.2 (172.16.200.2) 56(84) bytes of data.
64 bytes from 172.16.200.2: icmp_seq=1 ttl=61 time=0.363 ms
64 bytes from 172.16.200.2: icmp_seq=2 ttl=61 time=0.282 ms
64 bytes from 172.16.200.2: icmp_seq=3 ttl=61 time=0.206 ms
^C
--- 172.16.200.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2527ms
rtt min/avg/max/mdev = 0.206/0.283/0.363/0.066 ms
DUDE thats Awesome! What does mine say?
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:26:22:24:E7:24
inet addr:172.16.200.2 Bcast:172.16.200.3 Mask:255.255.255.252
inet6 addr: fe80::226:22ff:fe24:e724/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12812 errors:0 dropped:0 overruns:0 frame:0
TX packets:327970 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:948790 (926.5 KiB) TX bytes:482359204 (460.0 MiB)
[sreisinger@ACER1 ~]$ ping 172.16.100.2
PING 172.16.100.2 (172.16.100.2) 56(84) bytes of data.
64 bytes from 172.16.100.2: icmp_seq=1 ttl=61 time=0.326 ms
64 bytes from 172.16.100.2: icmp_seq=2 ttl=61 time=0.184 ms
64 bytes from 172.16.100.2: icmp_seq=3 ttl=61 time=0.196 ms
64 bytes from 172.16.100.2: icmp_seq=4 ttl=61 time=0.178 ms
^C
--- 172.16.100.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3299ms
rtt min/avg/max/mdev = 0.178/0.221/0.326/0.060 ms
SWEET! What does mine say?
IPERF TEST:
iperf is available from the CentOS repository. I wanted VLC but was having issues finding the repo so i decided to use iperf instead. IPERF excerpt: iperf is a great little command line utility used to measure tcp and udp performance from one node to another. It can be a great help in finding bottlenecks in network performance, troubleshooting wifi issues and more. It’s very simple to use, and is available in the EPEL repo for CentOS.
It really is an awesome tool, not just for my multicast testing, but checking tcp and udp performance and it is super easy to get up and running.
So first things first we need a source so lets start one up.
SOURCE:
[sreisinger@ACER2 ~]$ iperf -s -u -B 239.100.100.110 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 239.100.100.110
Joining multicast group 239.100.100.110
Receiving 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
Great i've launched my PIM Source advertising group 239.100.100.110 the -s specifies it as a server the -u specifies UDP and -B tell it to bing to the hosts interface of 172.16.100.1
EXCELLENT! Now if everything is configured and working properly starting the client should generate some multicast traffic.
CLIENT:
[sreisinger@ACER1 ~]$ iperf -c 239.100.100.110 -u -T 32 -t 5 -i 1
------------------------------------------------------------
Client connecting to 239.100.100.110, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 32
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.200.2 port 51839 connected with 239.100.100.110 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 129 KBytes 1.06 Mbits/sec
[ 3] 1.0- 2.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 4.0- 5.0 sec 128 KBytes 1.05 Mbits/sec
[ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec
[ 3] Sent 447 datagrams
and on the Server side we received those datagrams.
[sreisinger@ACER2 ~]$ iperf -s -u -B 239.100.100.110 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 239.100.100.110
Joining multicast group 239.100.100.110
Receiving 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 239.100.100.110 port 5001 connected with 172.16.200.2 port 46213
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 128 KBytes 1.05 Mbits/sec 0.015 ms 0/ 89 (0%)
[ 3] 1.0- 2.0 sec 128 KBytes 1.05 Mbits/sec 0.013 ms 0/ 89 (0%)
[ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec 0.018 ms 0/ 89 (0%)
[ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec 0.015 ms 0/ 89 (0%)
[ 3] 4.0- 5.0 sec 128 KBytes 1.05 Mbits/sec 0.014 ms 0/ 89 (0%)
[ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec 0.015 ms 0/ 447 (0%)
MULTICAST LIVES HERE!!!
So there you have it. PIM Sparse mode across Juniper EX2200-C's running 14.1X53-D26.2.
- We configured the layer 2 and layer 3 interfaces.
- We set up dynamic routing
- We configured PIM and IGMP where required
and VIOLA simple sweet and crisp!
CHECKING PIM
We can't be done just yet we need to see just what a working network supporting PIM looks like.
Let's check the pim join command on the core devices.
PIM JOIN:
CORE-1:
show pim join
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 239.100.100.110
Source: *
RP: 192.168.55.4
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/1/1.0
Group: 239.100.100.110
Source: 172.16.200.2
Flags: sparse,spt
Upstream interface: ge-0/1/1.0
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
AGG-1:
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 239.100.100.110
Source: *
RP: 192.168.55.4
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/1/0.0
Group: 239.100.100.110
Source: 172.16.200.2
Flags: sparse,spt
Upstream interface: ge-0/1/0.0
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
AGG-2:
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 239.100.100.110
Source: *
RP: 192.168.55.4
Flags: sparse,rptree,wildcard
Upstream interface: Local
Group: 239.100.100.110
Source: 172.16.200.2
Flags: sparse,spt
Upstream interface: vlan.200
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Everything you need to know about the PIM join.
We can also see our neighbors and interfaces.
AGG-2:
show pim neighbors
B = Bidirectional Capable, G = Generation Identifier
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority, T = Tracking Bit
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/1/1.0 4 2 HPLGT 22:46:30 172.16.1.5
show pim interfaces
Stat = Status, V = Version, NbrCnt = Neighbor Count,
S = Sparse, D = Dense, B = Bidirectional,
DR = Designated Router, P2P = Point-to-point link,
Active = Bidirectional is active, NotCap = Not Bidirectional Capable
Name Stat Mode IP V State NbrCnt JoinCnt(sg/*g) DR address
ge-0/1/1.0 Up S 4 2 DR,NotCap 1 0/0 172.16.1.6
pimd.32770 Up S 4 2 P2P,NotCap 0 0/0
vlan.200 Up S 4 2 DR,NotCap 0 1/0 172.16.200.1
AGG-1:
show pim interfaces
Stat = Status, V = Version, NbrCnt = Neighbor Count,
S = Sparse, D = Dense, B = Bidirectional,
DR = Designated Router, P2P = Point-to-point link,
Active = Bidirectional is active, NotCap = Not Bidirectional Capable
Name Stat Mode IP V State NbrCnt JoinCnt(sg/*g) DR address
ge-0/1/0.0 Up S 4 2 DR,NotCap 1 1/1 172.16.1.2
pime.32770 Up S 4 2 P2P,NotCap 0 0/0
vlan.100 Up S 4 2 DR,NotCap 0 0/0 172.16.100.1
NOTE the two highlighted interfaces AGG-1 show a pime.32770 and AGG-2 shows a pimd.32770 even though you didnt configure them! Don't freak out this is the encapsulation and decapsulation interfaces that let you know everything is working properly.
Lets look at some IGMP commands:
AGG-2:
show igmp group detail
Interface: local, Groups: 2
Group: 224.0.0.5
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
Group: 224.0.0.6
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
{master:0}[edit]
NOT MUCH THERE lets check AGG-1:
show igmp group detail
Interface: vlan.100, Groups: 1
Group: 239.100.100.110
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: 172.16.100.2
Group timeout: 151 Type: Dynamic
Output interface: vlan.100
Interface: local, Groups: 5
Group: 224.0.0.2
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
Group: 224.0.0.5
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
Group: 224.0.0.6
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
Group: 224.0.0.13
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
Group: 224.0.0.22
Group mode: Exclude
Source: 0.0.0.0
Source timeout: 0
Last reported by: Local
Group timeout: 0 Type: Dynamic
Output interface: none
{master:0}[edit]
There is our multicast group we are sending! We can also see the multicast route.
>show multicast route
Instance: master Family: INET
Group: 239.100.100.110
Source: 172.16.200.2/32
Upstream interface: ge-0/1/0.0
Downstream interface list:
vlan.100
Instance: master Family: INET6
MORE COMMANDS:
There is a plethora of troubleshooting commands and documentation on the Juniper Networks web site. This particular Knowledge Base article will come in handy when troubleshooting: KB21591
THATS ALL FOLKS!
Tune in later for Multicast in a Virtual Router (VR), referred to as VRF-Lite (pronounced verf lite) for you Cisco fanatics, and a lot more fun configuration using sparse-dense mode. Plus you get to learn how to create a Virtual-Router inside an actual device to segregate traffic and provide a different context for your network.
VERY helpful info!! Thanks for sharing!
ReplyDeleteYou are very welcome Gary!
ReplyDelete