Secara teori multicast dapat berjalan dalam LAN yang sama. Misal satu switch ada sender multicast ada receiver multicast. Maka receiver akan bisa menerima paket-paket dari sender (multicast server).
Satu switch umumnya akan secara default aktif IGMP Snoop (snoop = mencium/mengintai). Gunanya IGMP Snoop ini, agar packet multicast tidak perlu di banjirkan ke semua port. Cukup yang meminta saja yaitu receiver yang meminta meggunakan IGMP report (join) message.
Nah, ada kalanya muncul masalah spt berikut.
Receiver 1, bisa menerima multicast. Tetapi, Receiver 2 tidak bisa menerima multicast.
Padahal kedua switch dan kedua Receiver dan Source berada pada satu VLAN yang sama. Apa pasal?
Teori Switch Melewatkan Multicast
Sebuah switch dalam menghadapi multicast perlu mengidentifikasi mana mrouter port.
Dalam konteks Switch1, karena Source selalu menyemburkan paket multicast, dia tahu bahwa mrouter port nya adalah Gig2/47.
Selanjutnya apabila ada Receiver yang mengirrimkan IGMP report (join), yaitu Receiver1 port Gig2/48, maka Switch1 tinggal banjiri port tsb. Secara berkala Switch1 akan bertanya ke Receiver1 apakah masih perlu (menggunakan IGMP query), akan di jawab Receiver1 dengan "iya" via IGMP report.
Begitu seterusnya.
Masalah di Switch2
Nah, masalah timbul pada Switch2.
Saat Receiver2 mengirimkan paket IGMP report (join) pada Fa1/0/47 di Switch2, maka Switch2 akan "menelan" paket ini. Kenapa?
Karena Switch2 tidak tahu dimana mrouter port dia.
Solusi
Salah satu solusinya adalah: kita harus beritahu Switch2 bahwa mrouter port dia adalah Fa1/0/33.
Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33
Dan kita cek:
Switch2#show ip igmp snooping mrouter
Vlan ports
−−−− −−−−−
1 Fa1/0/33(static)
Nah sekarang Switch2 sudah punya mrouter port (secara static).
Selanjutnya apabila ada paket IGMP report (join) dari receiver manapun, maka paket tsb akan di keluarkan (akan di relay) keluar port Fa1/0/33.
Switch1 akan menerima paket tsb di port Gig2/46, dan akan membanjiri port Gig2/46 dengan paket streaming multicast yang diminta.
Problem solved!
Solusi lain
Ada beberapa solusi lain diantaranya:
Solusi 2. Akfitkan PIM (jika menggunakan L3)
Apabila Switch1 dan Switch2 adalan L3 Switch, maka bisa diaktifkan PIM. Biasanya PIM dipasang di L3 Router bukan di L2 Switch. Karena diatas menggunakan Catalyst L3, maka bisa di pasang di port yang menghubungkan ke dua switch PIM sparse mode.
Switch1#show run interface vlan 1
!
interface Vlan1
ip address 1.1.1.1 255.255.255.0
ip pim sparse−dense−mode
end
Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port.
Switch1#show ip igmp snooping mrouter vlan ports
−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
1 Router
Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that port as its Mrouter port.
Switch2#show ip igmp snooping mrouter
Vlan ports
−−−− −−−−−
1 Fa1/0/33(dynamic)
Solusi 3. Aktifkan IGMP Snoop Querier (Jika menggunakan L2)
Apabila Switch punya kemampuan L3 bisa digunakan PIM. Akan tetapi jika murni L2, maka opsi lain dari Cisco adalah mengaktifkan fitur IGMP Snoop Querier.
Jalankan di Switch2.
Switch2(config)#ip igmp snooping querier
Switch2#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
1 1.1.1.2 v2 Switch
Switch 1 now sees port Gig 2/46 linking to Switch 2 as an mrouter port.
Switch1#show ip igmp snooping mrouter vlan ports
−−−−−−−−−−−−−−
1 Gi2/46
When the source on Switch 1 starts to stream multicast traffic, Switch 1 forwards the multicast traffic to the Receiver 1 found via IGMP snooping (i.e., out port Gig 2/48) and to the mrouter port (i.e., out port Gig 2/46).
Solusi 4: Matikan IGMP Snoop di Switch2 (sangat tidak di rekomendasikan).
Solusi 5: Opsi lain:
ip igmp join-group 232.1.1.1 source 10.1.3.3 --> CPU Intensiveip igmp static-group 232.1.1.1 source 10.1.3.3 --> CPU LightStatically Join the IGMP Group
If the router has the ip igmp join-group command on any of the interfaces, the router itself becomes a receiver for the multicast stream. This command is used in order to move multicast traffic to this router without a real directly-connected receiver or without a Protocol Independent Multicast (PIM) neighbor downstream that sends PIM Join requests for the multicast flow. However, because this router joins the multicast stream, all of the multicast packets are punted to the CPU. This can cause high CPU, or it can cause the rate-limiters (if any) or the Control Plane Protection (CoPP) to be hit.
A better alternative that you can use in order to attract the multicast stream for this router is to configure the ip igmp static-group interface command. With this command, the router can still attract the multicast stream and forward it out on the interface, but the router itself does not become a receiver for the stream.
Both the ip igmp join-group interface command and the ip igmp static-group command cause the PIM to send Join requests upstream towards the source or towards the Rendezvous Point (RP), but this only occurs if the router with this command is the PIM Designated Router (DR) on that interface. In order to ensure that the command takes effect and attracts the multicast traffic, use the command on the router that is the DR for that particular network. Alternatively, you can make the router that uses the command the PIM DR. In order to do this, configure the ip pim dr-priority command on the interface and ensure that it has the highest PIM DR priority value of any PIM router on that network.
Here is an example:
In this example, there is a source with IP address 10.1.3.3 and a receiver for the group 232.1.1.1.
Receiver is Active
Here is the multicast forwarding entry on the router R1:
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 01:54:48/00:02:54, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 01:54:48/00:02:54
As shown in the output, the interface Ethernet0/0 is in the Outgoing Interface List (OIL), and the (10.1.3.3, 232.1.1.1) multicast traffic is forwarded to the interface Ethernet0/0.
This can also be observed in the Multicast Forwarding Information Base (MFIB) entry:
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F NS
Pkts: 0/0
IGMP Join Command
If the router R1 does not receive a PIM Join request for the multicast stream from the router R4 (for any reason), then the multicast stream does not flow. One possible reason is that the PIM is not allowed to form a neighborship between the routers R1 and R4 because the routers belong to a different administrative domain. A solution is to forward the traffic from the router R1 towards the router R4 in a static fashion.
The ip igmp join-group command is used on interface Ethernet0/0 on the router R1. This allows the router R1 to send a PIM Join request upstream (to the source or RP) and attract the multicast stream (10.1.3.3, 232.1.1.1). This traffic is then forwarded to the interface Ethernet0/0, as this interface is in the OIL. However, the traffic is also punted to the CPU.
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:09:30/00:02:19, flags: sLTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:00:40/00:02:19
The L flag means that the multicast traffic is punted. The interface Ethernet0/0 is in the OIL, so the traffic is punted to the CPU and forwarded to the interface Ethernet0/0.
The MFIB entry shows the Internal Copy (IC) flag. This means that the packets for this flow are punted to the CPU.
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F IC NS
Pkts: 0/0
Because all of the traffic for this multicast stream is punted, it can cause unwanted side effects, as previously described.
IGMP Static Command
The ip igmp static-group command is used as a solution in order to forward the traffic from the router R1 towards the router R4 in a static fashion. In this scenario, the router R1 sends a PIM Join request upstream (to the source or RP) and attracts the multicast stream (10.1.3.3, 232.1.1.1). This traffic is then forwarded to the interface Ethernet0/0, as this interface is in the OIL, but the traffic is not punted to the CPU.
R1#show running-config interface Ethernet 0/0
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp static-group 232.1.1.1 source 10.1.3.3
end
R1#show ip mroute 232.1.1.1 10.1.3.3
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.3.3, 232.1.1.1), 00:07:41/stopped, flags: sTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.2.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:05:06/00:00:53
The L flag no longer appears. The traffic is not punted on this router, but it is forwarded to the interfaces in the OIL.
Similarly, the MFB entry does not show the IC flag:
R1#show ip mfib 232.1.1.1 10.1.3.3
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(10.1.3.3,232.1.1.1) Flags:
SW Forwarding: 0/0/0/0, Other: 0/0/0
Ethernet1/0 Flags: A
Ethernet0/0 Flags: F NS
Pkts: 0/0
No comments:
Post a Comment