Multicast routing: a step by step… Part 1

In the above test lab, Servers send multicast trafic to both clients.

In IPv4, multicasting servers uses class D range of addresses: 224.0.0.0-239.255.255.255. Some addresses are well known and others for specific use…

In our example, Server2 sends trafic (ping) to group ip @ 226.0.0.1. There’s no need on a cisco router to configure multicast routing on a router to send a packet to a mcast destination. It sends the trafic through the all configured ip address interfaces…

To see the packets being sent by the server, we disable cef on the ip enabled interfaces (Fastethernet0/0 and loopback0) and activate a debug ip packets, so packet are switch processed…

Server1 sends trafic to destination 226.0.0.1 using local interface addresses: 1.1.1.1 and 123.1.1.254

IP @226.0.0.1 represents a group of receivers…

This is an optimization in comparison with unicast trafic. In such case, one flow of the same trafic is needed for each receiver. For each flow the server maintains a different per receiver session.

In our example, Client1 (a cisco router) starts accepting and processing trafic to 225.0.0.1 (Server1) destination as soon as IGMP is enabled on the receiving interface and joined the group

Because Client1 and Server1 are located in the same subnet, Client1 responds to Server1 pings to ip @225.0.0.1.

In Wireshark capture, Server1 uses the mac @01:00:5e:00:00:01 (in wireshark) but should’ve used the Ethernet MAC address range 01:00:5e:00:00:00–01:00:5e:7f:ff:ff (with an OUI owned by the IANA).

This range has 23 bits of available address space. The first octet (01) includes the broadcast/multicast bit. The lower 23 bits of the 28-bit multicast IP address are mapped into the 23 bits of available Ethernet address space.

If two hosts on the same subnet each subscribe to a different multicast group whose address differs only in the first 5 bits, Ethernet packets for both multicast groups will be delivered to both hosts, requiring the network software in the hosts to discard the unrequired packets.

Server2 is not on the same subnet: routing is needed.

By definition each router interface is a broadcast domain and the same broacast (multicast) could not natively cross router interfaces…

Server2 sends multicast trafic to ip @226.0.0.1

R1 should accept this trafic and forward it down to Client1

Using debug ip packets and deactivating ip cef on the interface facing the Server2 we check that R1 receives server flow

The mroute (mutlicasting routing) table indicates the multicast forwarding is not activated

To accept (and process) multicast trafic (from outside the router) we should enable PIM protocol on the interface on which the server trafic is received

PIM is enabled on the interface facing the server in dense mode

We check that the source is added to the mroute table

The mroute table entry (S,G) indicates the source and multicast group address. It indicates also the incoming interface and that the RPF neighbor is the router itself. Notice that the outgoing interface list is NULL which means that the router has no idea on where to forward the received packets.

The (Source, Group) or (S,G) entry is flagged as PT: Pruned and SPT-bit set to indicate that the flow flows over the shortest path tree from the source (server) to the destination (receivers)

The router accepts the flow from the server. To fowarded it to the subnet where our clients (receivers) reside, we add a static membership on R1. This static membership is an alternative to clients joining dynamically (using IGMP) the group at R1.

A capture in clients subnet shows that the multicast forwarded by R1 is received

Client1 could’ve indicated its willingness to receive Server2 multicast to router R1, using IGMP, so there’s no need to configure R1 statically

For ping to succeed, a routing back from the client to the server is needed…

We check that server receives replies from the the client

We check also that the client has active memeberships and on which interface

In R1 we get more details on forwarding mcast trafic in the mfib table

We check that the router is no more configured with a static igmp entry (that represnts all the clients on subnet 123.1.1.0/24)

We check that the (*,G) is present and indicates the correct incoming and outgoing interfaces.

Using IGMP, R1 fill in with the correct information the outgoing interface list that points to “Reporter” 123.1.1.1 which is our Client1…

To be continued….

atlink'admin

Learn More →

Leave a Reply

Translate »