The Hitchhiker's Guide to Networking: January 2016

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

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

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

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

The Hitchhiker's Guide to Networking

Friday, January 29, 2016

Sparse Mode Multicast across a Layer 3 Core

About Me

Blog Archive