Home > Uncategorized > pim routing with a Fortigate

pim routing with a Fortigate

There are some grammar errors contained herein. I also need to review a few things (related to DRs and RPs).
Here is a very valuable serverfault thread I’ve started with the conclusion that pim-dm should actually always be used, unless there is a need for low latency of packet arrival times 100% of the times.

Deciding on sparse mode or dense mode:

Dense: Consider this PASSIVE subscriber based (is given, asks for it to stop). It can be refered to as “push mode.”
When you are expecting to route multicast through few layer 3 devices. Dense mode uses a broadcast poller that fires a broadcast of “HEY WHO NEEDS THIS MULTICAST TRAFFIC?!” for which the other dense mode pim routers reply “I STILL HAVE CLIENTS! KEEP IT COMING!”

Sparse: Consider this ACTIVE subscriber based (isn’t given, asks for it). It can be refered to as “pull mode.”
When you are expecting to route multicast through many layer 3 devices to reduce the amount of traffic. Sparse mode is subscriber based, and fires requests up the tree (to a single router that keeps a database of all senders and receiving routers), multicast down the tree to ONLY _requesting_ routers.

Why would you ever want to use dense mode? It’s easy to configure. It also provides very fast ramp up time (what I’ll call time-to-first-packet-receipt) from the time a requester joins to when they receive packets.

Dense mode has much potential to suck terribly (at least in large deployments); and if sparse mode is implemented correctly, it may be just as efficient at lowering time-to-first-packet-receipt.

Understanding your design:

It’s important to understand your design.

When I opened a ticket with Fortigate, and I had a single router (a Fortigate) between my sender and receiver, they recommended I configure multicast bridging.
I was dissatisfied with this, since I had seen pim sparse mode while reading, and it appeared to be able to allow the Fortigate interface facing the multicast sender to dynamically subscribe to the multicast group.

I will describe two configurations below, one which is simple and involved a single router hop:

Sending topology:

[multicast sender] -> [fortigate internal1]<>[fortigate internal4] -> [multicast receiver]

Subscription IGMP flow:

[fortigate internal4] <- [multicast receiver]

One which is less simple and involves many hops:
Sending topology:

[multicast sender] -> [fortigateA internal1]<>[fortigateA internal4] -> [fortigateB dmz]<>[fortigateB internal1] -> [fortigateC internal2]<>[fortigateC internal3] ->[multicast receiver]

Subscription IGMP flow:

[fortigateC internal3] <- [multicast receiver]

In this case, we will use BSR to have the routers elect a RP, and of course the DR will keep the MRIB database of multicast senders, our RPs and their status.

What is up with all the acronyms, kid?
It’s one thing that annoys me is acronym usage. It happens a lot in all of IT, if not in all of business.

Take a look at the definitions section of RFC4601 for assistance in understanding the acronyms, but I’ll try to explain them in plain English here.

RP is that kid I knew in high school right? Nah. It’s rendezvous point.
1) The service that sees IGMP JOIN messages for a specific multicast group sent by nodes.
2) It replies with the multicast group info to the requesting node.

DR is disaster recovery right? Of course not! It’s designated router.
1) Within a broadcast domain, a DR is elected and is the dude who holds info on the pim sparse mode configuration.

BSR is that Where I go Salmon fishing in the Fall? Nope. It’s bootstrap router.
BSR is an open standard for RP discovery.
See https://tools.ietf.org/html/rfc4601#section-3.7 and have you head explode.
1) Collects RP info
2) Figures out which RP represents a multicast address
3) Sends out this thined list of RPs out to all DRs.

MRIB is Mel’s BBQ Ribs down on the corner, right? Incorrect. MRIB is the multicast routing information base.
1) this is a routing table (aka database), like any other.
2) contains entries that include next hop routers in a multicast capable path.
– multicast capable paths are defined as routers who speak pim and are likely running the RP service.

Okay, so how does it work?

The sub-section covered here is RFC4601 section 3.

MRIBs hold the routing table in reverse to access the SOURCE (versus what we’re used to a routing table containing, a DESTINATION)

Receivers:

1) A receiver sends an IGMP JOIN to a multicast group (239.100.100.99).
2) A DR is elected from all participating routers that are configured for pim on the receiver’s subnet/broadcast domain.
The DR listens for IGMP JOINs for the given multicast group (239.100.100.99)
3) The DR for 239.100.100.99 sends a pim JOIN to the RP for the multicast group. The message doesn’t care who is sending, of course, since the receiver doesn’t know this; so the contents of the pim JOIN say “join 239.100.100.99. any sender is fine;”. You will see this expressed sas (*, 239.100.100.99) (where 239.100.100.99 is replaced by `G` when reading theory, `G` just means a multicast group address) ### how is an RP elected/designated?
4) This DR sent pim JOIN is sent through all participating routers to the designated RP for multicast group 239.100.100.99; or a router with an RP role who is already joined to the multicast group 239.100.100.99.
I hate the term “tree,” and prefer hmm… multipath route? Maybe that has another meaning, but it makes more sense to me.

multicast sender node----239.100.100.99 --- routerA: designated RP for 239.100.100.99 --------------------------------------- routerB: DR with clients that are JOINed
										\							\
										 \------- routerC: DR with no clients that are JOINed	 \---routerF: DR with clients that are JOINed -- multicast receiver node
										  \
 									           \------ routerD: DR with clients that are JOINed -- multicast receiver node
													\
													 \----- routerE: DR with clients that are JOINed -- multicast receiver node											 

The designated RP for the multicast group 239.100.100.99 produces a database that contains the distribution tree (this DB is called RP tree).

5) JOINs are occasionally sent up towards the designated RP for 239.100.100.99 (routerA) by DRs with clients that are JOINed.
– Some times relying on the RP is inefficient and another method called shortest-path is used. This allows a DR to send a pim JOIN up the routers for the specific multicast source/group towards the source and, if a shorter path is determined, the DR drops from the RP distribution with a pim PRUNE.
– clients may designate a specific source address for a multicast group only in IGMPv3. If there are no other hosts on the subnet requesting just the multicast group, the DR for the subnet will perform the source specific multicast pim JOIN only.
[If you use IGMPv3 nodes only, and want to use source specific JOINs, you SHOULD packets to a multicast address within 232.0.0.0/8. pim routers who receive pim JOINs with non-specific sender addresses do not allow them to join a group within this range.]

If you have a pim JOIN for a multicast group without a specific address, you are relying on RP. If you have a pim JOIN with a multicast group with a specific address, you are relying on source-specific.
From this idea, you could not have an RP for a multicast group, require IGMPv3, and have pim routers that facilitate source-specific joins in order to JOIN any multicast group.

6) When all clients attached to or below a router with the DR service leave, the DR service sends a pim PRUNE up to the RP for the group. No more pim JOINs refreshes from a DR? It times out.

Senders:
1) a sender sends an multicast traffic.
2) pim-member routers with interfaces configured on the subnet of the sender have a DR designated.
3) an RP election is held and one pim-member becomes the RP for the multicsat group.
4) The RP then awaits pim JOINs from other RPs to route to.
5) If a DR hears a pim JOIN from one of the nodes on in it’s subnet/broadcast domain, and already is receiving the packets of the requested multicast group, then it provides (the path to) the packets.

There are some extra ways the “trees” reconcile themselves and stop looping that I won’t cover, because they are part of the protocol, and the purpose of this write up is more operational than theorhetical.

Propagating info on the RPs to each DR:

The sub-section covered here is RFC4601 4.7.

You guessed it, RPs are super important for non-source specific JOINs (which is any other client than IGMPv3).
If a pim router doesn’t have knowledge of the RP associated with a given group address, and isn’t provided the specific source, then it can’t figure out where to send it’s pim JOIN request.

RPs do not get elected, the role is configured on a pim router.
pim routers gain knowledge of the RP router for each qualifying multicast group without a specific-source through the RP tree.
In each pim router, you can configure a RP statically or dynamically. Since being dynamic is nice, we’ll use BSR to figure it out and provide each pim router with the info.

Configured routers with the RP service send an annoucement containing the following info to the BSR:
– addressing info (for accessibility)
– the multicast group it represents
– the priority for which it’s been configure the RP for the multicast group it represents

The BSR compiles this info, then sends it off to participating pim routers (DR).
The DRs then decide on which RP to use by using an algorithm I won’t explain (most specific mask wins, same mask? highest priorty wins), to decide which RP represents that source and multicast group.
The DRs also perform decisions using the same algorithm when receiving IGMP JOINs, and other pim membership change messages.

Okay, great… I’m royally confused… what does this all mean?!

1) You want to configure the interface on the subnet where the multicast sender lives to be an RP. The address of the RP must be accessible to all DRs where you expect multicast receiving nodes to live.

2) You want to configure DRs on each participating router subnet interface.

3) If you need to worry about RP convergence and many hop networks, you want to configure BSR to bring together all your RPs then send them to all the DRs. Otherwise, configure static RP entries on all the routers.

Configuring multicast packet delivery through a single Fortigate:

There are two conditions in which a client will receive packets:
BAD:
1) multicast-forwarding is enabled on the system, a multicast firewall policy is in place, the internal1 interface pim-sm routing is enabled, and join-group is configured.
– all multicast packets arrive at internal1 all of the time
– all multicast packets are flooded towards the host/switch
– switch regulation can be put in place that stops a broadcast (for instance a “drop multicast packets for unknown groups” global rule)

GOOD:
1) a multicast firewall policy is in place, the internal1 interface pim-sm routing is enabled, the internal1 interface join-group is configured.
– all multicast packets arrive at internal1 all of the time
– all multicast packets are NOT flooded towards the host/switch
– only subscribing hosts receive traffic

In the latter case (“GOOD”), the Fortigate internal1 advertises itself as a router for ALL multicast groups (current or future). I’d really like to work out a method so that it can dynamically become a router for groups only when an IGMP JOIN is heard on the receiver’s interface. I’m just not sure that’s possible.

External reference:

Advertisements
  1. Bdf
    October 18, 2013 at 7:26 am

    Thanks for sharing this!!!

    It is not my first time reading this blog… But know something draw my attention… You are linking my blog!!! It is awesome!!! Could you send me your logo to put it in my partner section in my blog?

    • October 18, 2013 at 3:35 pm

      Hello Javier,

      I have no logo, and am not quite as “branded” as you :D

      You can simply link the root of this blog (https://mbrownnyc.wordpress.com) as you wish.

      I came across a few articles on your blog that I liked, so I figured I’d like you on the right side.

      Thanks!

      Matt

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: