Multicast routing for IPTV
One very close person to me, a fan of Habr, wanted to contribute to the development of the Cisco blog. Being a fierce fan of what this corporation creates, he wanted to share his experience. =) Hope the stroke of the pen was a success.
Relatively recently, I was lucky enough to introduce and even see multicast routing for IPTV. Initially, I was completelyunfamiliar with this topic, and it made me vylakat neck from a vodka tank to dig up a huge amount of documentation to get up to date.
And that's bad luck. Usually in the documentation they post everything at once and for the person who first encountered this topic, it is not clear where to start. While reading pdf, I caught myself thinking that it would be nice to stumble somewhere on an article that could take a short way from theory to practice, in order to understand where to start and where to focus.
')
I could not find such an article. This prompted me to write this little article for those who, like me, will face the question of what kind of an IPTV beast it is and how to fight it.
This is my very first article (but not the last! There are many more animals), I will try to present everything as accessible as possible.
First of all, we will voice a few concepts in order to exclude further misunderstandings. There are three types of traffic:
Obviously, multicast is the most preferred channel for broadcasting channels.
Any TV channel that we want to broadcast to the network is characterized by a group address that is selected from the range reserved for this purpose: 224.0.0.0 - 239.255.255.255 .
IPTV requires a router that supports multicast (hereinafter MR). He will track the membership of a client in a particular group, i.e. constantly follow which client to send a TV-channel.
In order for the client to register with one of these groups and watch the TV channel, the Internet Group Management Protocol ( IGMP ) is used.
There is a server that is included in the MR router. This server broadcasts several TV-cartoons, for example:
The client turns on the News channel, thus, unwittingly, he sends a request for MR to connect to the group 224.12.0.1. From the point of view of the IGMP protocol, this is the “ JOIN 224.12.0.1 ” request.
If a user switches to another channel, then he first sends an MR notice that he is shutting down the News channel or leaving this group. For IGMP this is “ LEAVE 224.12.0.1 ”. And then repeats a similar JOIN query for the desired channel.
MR sometimes asks everyone: “and to which group who is connected?” In order to disconnect those customers with whom the connection was broken and they did not have time to send a LEAVE notification. To do this, MR uses the QUERY query.
The subscriber’s response to this request is the MEMBERSHIP REPORT , which contains a list of all the groups the client is in.
Suppose that clients of the same group are watching the same cartoon, but they are in different network segments (network A and network B). In order for them to get their cartoon and invented multicast routing.
An example of setting up the routers MR1 ​​and MR2.
The " ip multicast-routing " command includes the appropriate routing, but if it is turned off, the router does not forward multicast packets, i.e. they will not reach the bewildered spectator cartoons.
Let's stop a little more in detail on the command " ip pim sparse-mode ".
PIM (Protocol Independent Multicast) is a multicast routing protocol. It populates its multicast routing table based on the normal routing table. These tables can be viewed using the “ sh ip mroute ” and “ sh ip route ” commands, respectively. The goal of the PIM protocol is to build a route tree for sending multicast messages.
The PIM protocol has two main modes: sparse mode and dense mode . The multicast routing table for them looks a little different. Sometimes these modes are considered as separate protocols - PIM-SM and PIM-DM.
In our configuration on the interfaces, we specified the " ip pim sparse-mode " mode .
(config-if) # ip pim?
dense-mode Enable PIM dense-mode operation
sparse-dense-mode enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
PIM-DM uses a flood and prune mechanism. In other words. The MR router sends all multicast streams registered to it. If the client does not need any of these channels, then he refuses it. If all clients hanging on the router refused the channel, the router sends “thank you, don't need it” to the upstream router.
PIM-SM does not initially broadcast TV channels registered on it. Distribution will start only when a request comes from the client.
Those. in PIM-DM, MR sends to everyone, and then removes the unnecessary, and in PIM-SM, MR starts broadcasting only on request.
If group members are scattered across multiple network segments, which is typical of IPTV, PIM-DM will use most of the bandwidth. And this can lead to poor performance. In this case, it is better to use PIM-SM.
There are more differences between PIM-DM and PIM-SM.
PIM-DM builds a tree separately for each source of a specific multicast group, i.e. The multicast route will be characterized by the source address and the group address. In the multicast routing table there will be records of the form (S, G), where S is the source, G is a group.
PIM-SM has some peculiarity. This mode requires a rendezvous point ( RP - rendezvous point ) at which sources of multicast streams will be registered and create a route from source S (self) to group G: (S, G).
Thus, the traffic goes from the source to the RP along the route (S, G), and then to the customers, according to the common for the sources of a specific group, the tree, which is characterized by the route (*, G) - “*” symbolizes “any source”. Those. the sources registered to the RP, and then the clients already receive the stream from the RP and for them it does not matter who the original source was. The root of this common tree is RP.
The rendezvous point is one of the multicast routers, but all other routers should know “who is the RP point here” and be able to reach it.
An example of a static definition of RP (MR1). Announce to all multicast routers that the rendezvous point is 10.0.0.1 (MR1):
All other routers should know the route to RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
There are also other ways to determine RP, this is auto-RP and bootstarp router, but this is a topic for a separate article ( if anyone would be interested, please )?
We are still considering the scheme with the routers MR1 ​​(RP) and MR2. As soon as we turn on the link between the routers MR1 ​​and MR2, then they should see messages in the logs
For MR1:
% PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
For MR2:
% PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
This suggests that routers have established a PIM neighborhood relationship with each other. You can also check this with the command:
MR1 # sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable
As a test server, it was convenient for me to use the VLC player. However, as it turned out later, even if you set up a sufficient TTL via the GUI, it still (I hope only in the version I used) persistently sent multicast packets with TTL = 1. I had to run stubborn with the option "vlc.exe –ttl 3" because we have two routers on our way, each of which reduces the TTL packet by one.
How can I still find a problem with TTL? One of the methods. Let the server broadcast the channel 224.12.0.3 with TTL = 2, then the packets on the MR1 router pass normally, and the clients will not be able to watch their cartoon for the MR2 router.
This is detected by the “sh ip traffic” command on MR2. We look at the “bad hop count” field - this is the number of packets that “died”, as they measure, according to TTL = 0.
MR2 # sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
If this counter is increasing rapidly, then the problem is in TTL.
After switching on the broadcasting of three channels on the server in the multicast routing table, we observe the following:
MR1 # sh ip mroute
(*, 224.12.0.1), 00: 03: 51 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.1), 00: 03: 52/00: 02: 50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.2), 00: 00: 45 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00: 00: 45/00: 02: 50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00: 00: 09 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00: 00: 09/00: 02: 59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
We see that routes of the form (S, G) have appeared, for example (10.0.0.2, 224.12.0.3), i.e. registered source 10.0.0.2, which broadcasts to the group 224.12.0.3. As well as routes from RP to the client: (*, G), for example (*, 224.12.0.3) - which they will use, the so-called common to all tree.
As soon as the request for channel 1 arrives on the MR1 (RP) interface, the following changes occur in the multicast routing table:
MR1 # sh ip mroute
…………………
(*, 224.12.0.1), 00: 33: 16/00: 02: 54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward / Sparse, 00: 02: 37/00: 02: 53
(10.0.0.2, 224.12.0.1), 00: 33: 17/00: 03: 25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward / Sparse, 00: 02: 37/00: 02: 53
It became clear that requests for this group come from the Ethernet3 port.
It is possible that the router receives a multicast stream on two interfaces. Which of these two interfaces will the router consider as the source?
To do this, it performs an RPF (Reverse Path Forwarding) check — checks the route to the source using the usual unicast routing table and selects the interface through which the route goes to this source. This check is necessary in order to avoid looping.
You can track how the source passes the RPF check using the command:
MR2 # sh ip rpf?
Hostname or ABCD IP name or address of multicast source
MR2 # sh ip rpf 10.0.0.2
RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route / mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables
Well, that article appeared that I would love to find at the initial stage of studying multicast routing for IPTV. I am not a magician, I just learn ... Therefore, I will be happy to hear all the wishes, comments and advice. And also, I really hope that for someone it will be useful. =)
UPD: Allow me to submit it. Elena Sakhno - lena_sakhno
Relatively recently, I was lucky enough to introduce and even see multicast routing for IPTV. Initially, I was completely
And that's bad luck. Usually in the documentation they post everything at once and for the person who first encountered this topic, it is not clear where to start. While reading pdf, I caught myself thinking that it would be nice to stumble somewhere on an article that could take a short way from theory to practice, in order to understand where to start and where to focus.
')
I could not find such an article. This prompted me to write this little article for those who, like me, will face the question of what kind of an IPTV beast it is and how to fight it.
Introduction
This is my very first article (but not the last! There are many more animals), I will try to present everything as accessible as possible.
First of all, we will voice a few concepts in order to exclude further misunderstandings. There are three types of traffic:
- unicast - unicast, one source of stream one receiver
- broadcast - broadcast, single source, recipients all clients on the network
- multicast - multicast, one sender, recipients, some group of clients
What kind of traffic to use for IPTV?
| - | unicast | broadcast | multicast |
| Features applied to IPTV | we get traffic duplication, a stream is created for each subscriber | client equipment is forced to process the entire stream of channels, which may not be quite a few kilobits | the subscriber receives only the stream that requests |
Obviously, multicast is the most preferred channel for broadcasting channels.
Any TV channel that we want to broadcast to the network is characterized by a group address that is selected from the range reserved for this purpose: 224.0.0.0 - 239.255.255.255 .
IPTV requires a router that supports multicast (hereinafter MR). He will track the membership of a client in a particular group, i.e. constantly follow which client to send a TV-channel.
In order for the client to register with one of these groups and watch the TV channel, the Internet Group Management Protocol ( IGMP ) is used.
A little bit about how IGMP works.
There is a server that is included in the MR router. This server broadcasts several TV-cartoons, for example:
| 224.12.0.1 | channel 1 | News |
| 224.12.0.2 | channel 2 | History |
| 224.12.0.3 | channel 3 | Animals |
The client turns on the News channel, thus, unwittingly, he sends a request for MR to connect to the group 224.12.0.1. From the point of view of the IGMP protocol, this is the “ JOIN 224.12.0.1 ” request.
If a user switches to another channel, then he first sends an MR notice that he is shutting down the News channel or leaving this group. For IGMP this is “ LEAVE 224.12.0.1 ”. And then repeats a similar JOIN query for the desired channel.
MR sometimes asks everyone: “and to which group who is connected?” In order to disconnect those customers with whom the connection was broken and they did not have time to send a LEAVE notification. To do this, MR uses the QUERY query.
The subscriber’s response to this request is the MEMBERSHIP REPORT , which contains a list of all the groups the client is in.
Configure multicast routing.
Suppose that clients of the same group are watching the same cartoon, but they are in different network segments (network A and network B). In order for them to get their cartoon and invented multicast routing.
An example of setting up the routers MR1 ​​and MR2.
| Network a | 10.1.0.0/24 |
| Network b | 10.2.0.0/24 |
| Network C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1 # sh run ip multicast-routing ! interface Ethernet 0 description Multicast Source ip address 10.0.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 1 description Network A ip address 10.1.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 2 description Network B ip address 10.2.0.1 255.255.255.0 ip pim sparse-mode ! interface Ethernet 3 description Link to MR2 ip address 10.10.10.1 255.255.255.0 ip pim sparse-mode ! ip pim rp-address 10.0.0.2 IPTV override ! ip access-list standard IPTV permit 224.11.0.0 0.0.0.3 | MR2 # sh run ip multicast-routing ! interface Ethernet 0 description Link to MR1 ip address 10.10.10.2 255.255.255.0 ip pim sparse-mode ! interface Ethernet 1 description Network C ip address 10.3.0.1 255.255.255.0 ip pim sparse-mode ! ip pim rp-address 10.0.0.2 IPTV override ! ip access-list standard IPTV permit 224.11.0.0 0.0.0.3 ! ip route 10.0.0.0 255.255.255.0 10.10.10.1 |
The " ip multicast-routing " command includes the appropriate routing, but if it is turned off, the router does not forward multicast packets, i.e. they will not reach the bewildered spectator cartoons.
Let's stop a little more in detail on the command " ip pim sparse-mode ".
About the PIM protocol modes and the protocol itself.
PIM (Protocol Independent Multicast) is a multicast routing protocol. It populates its multicast routing table based on the normal routing table. These tables can be viewed using the “ sh ip mroute ” and “ sh ip route ” commands, respectively. The goal of the PIM protocol is to build a route tree for sending multicast messages.
The PIM protocol has two main modes: sparse mode and dense mode . The multicast routing table for them looks a little different. Sometimes these modes are considered as separate protocols - PIM-SM and PIM-DM.
In our configuration on the interfaces, we specified the " ip pim sparse-mode " mode .
(config-if) # ip pim?
dense-mode Enable PIM dense-mode operation
sparse-dense-mode enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
What is the difference?
PIM-DM uses a flood and prune mechanism. In other words. The MR router sends all multicast streams registered to it. If the client does not need any of these channels, then he refuses it. If all clients hanging on the router refused the channel, the router sends “thank you, don't need it” to the upstream router.
PIM-SM does not initially broadcast TV channels registered on it. Distribution will start only when a request comes from the client.
Those. in PIM-DM, MR sends to everyone, and then removes the unnecessary, and in PIM-SM, MR starts broadcasting only on request.
If group members are scattered across multiple network segments, which is typical of IPTV, PIM-DM will use most of the bandwidth. And this can lead to poor performance. In this case, it is better to use PIM-SM.
There are more differences between PIM-DM and PIM-SM.
PIM-DM builds a tree separately for each source of a specific multicast group, i.e. The multicast route will be characterized by the source address and the group address. In the multicast routing table there will be records of the form (S, G), where S is the source, G is a group.
PIM-SM has some peculiarity. This mode requires a rendezvous point ( RP - rendezvous point ) at which sources of multicast streams will be registered and create a route from source S (self) to group G: (S, G).
Thus, the traffic goes from the source to the RP along the route (S, G), and then to the customers, according to the common for the sources of a specific group, the tree, which is characterized by the route (*, G) - “*” symbolizes “any source”. Those. the sources registered to the RP, and then the clients already receive the stream from the RP and for them it does not matter who the original source was. The root of this common tree is RP.
The rendezvous point is one of the multicast routers, but all other routers should know “who is the RP point here” and be able to reach it.
An example of a static definition of RP (MR1). Announce to all multicast routers that the rendezvous point is 10.0.0.1 (MR1):
| ip pim rp-address 10.0.0.1 IPTV override | specify the address of the RP and the access-list IPTV access-list determines which groups |
| ip access-list standard IPTV | register at this rendezvous point |
| permit 224.11.0.0 0.0.0.3 |
All other routers should know the route to RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
There are also other ways to determine RP, this is auto-RP and bootstarp router, but this is a topic for a separate article ( if anyone would be interested, please )?
Let's see what will happen after setting up the routers.
We are still considering the scheme with the routers MR1 ​​(RP) and MR2. As soon as we turn on the link between the routers MR1 ​​and MR2, then they should see messages in the logs
For MR1:
% PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
For MR2:
% PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
This suggests that routers have established a PIM neighborhood relationship with each other. You can also check this with the command:
MR1 # sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable
| Neighbor Address | Interface | Uptime / Expires | Ver | DR Prio / Mode |
| 10.10.10.2 | Ethernet3 | 00: 03: 05/00: 01: 37 | v2 | 1 / DR S |
Do not forget about the TTL.
As a test server, it was convenient for me to use the VLC player. However, as it turned out later, even if you set up a sufficient TTL via the GUI, it still (I hope only in the version I used) persistently sent multicast packets with TTL = 1. I had to run stubborn with the option "vlc.exe –ttl 3" because we have two routers on our way, each of which reduces the TTL packet by one.
How can I still find a problem with TTL? One of the methods. Let the server broadcast the channel 224.12.0.3 with TTL = 2, then the packets on the MR1 router pass normally, and the clients will not be able to watch their cartoon for the MR2 router.
This is detected by the “sh ip traffic” command on MR2. We look at the “bad hop count” field - this is the number of packets that “died”, as they measure, according to TTL = 0.
MR2 # sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
If this counter is increasing rapidly, then the problem is in TTL.
Show ip mroute
After switching on the broadcasting of three channels on the server in the multicast routing table, we observe the following:
MR1 # sh ip mroute
(*, 224.12.0.1), 00: 03: 51 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.1), 00: 03: 52/00: 02: 50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.2), 00: 00: 45 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00: 00: 45/00: 02: 50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00: 00: 09 / stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00: 00: 09/00: 02: 59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
We see that routes of the form (S, G) have appeared, for example (10.0.0.2, 224.12.0.3), i.e. registered source 10.0.0.2, which broadcasts to the group 224.12.0.3. As well as routes from RP to the client: (*, G), for example (*, 224.12.0.3) - which they will use, the so-called common to all tree.
As soon as the request for channel 1 arrives on the MR1 (RP) interface, the following changes occur in the multicast routing table:
MR1 # sh ip mroute
…………………
(*, 224.12.0.1), 00: 33: 16/00: 02: 54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward / Sparse, 00: 02: 37/00: 02: 53
(10.0.0.2, 224.12.0.1), 00: 33: 17/00: 03: 25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward / Sparse, 00: 02: 37/00: 02: 53
It became clear that requests for this group come from the Ethernet3 port.
RPF check
It is possible that the router receives a multicast stream on two interfaces. Which of these two interfaces will the router consider as the source?
To do this, it performs an RPF (Reverse Path Forwarding) check — checks the route to the source using the usual unicast routing table and selects the interface through which the route goes to this source. This check is necessary in order to avoid looping.
You can track how the source passes the RPF check using the command:
MR2 # sh ip rpf?
Hostname or ABCD IP name or address of multicast source
MR2 # sh ip rpf 10.0.0.2
RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route / mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables
Well, that article appeared that I would love to find at the initial stage of studying multicast routing for IPTV. I am not a magician, I just learn ... Therefore, I will be happy to hear all the wishes, comments and advice. And also, I really hope that for someone it will be useful. =)
UPD: Allow me to submit it. Elena Sakhno - lena_sakhno
Source: https://habr.com/ru/post/61466/
All Articles