Advanced Multicast Resiliency Webinar

© 2013 Cisco and/or its affiliates. All rights reserved. 1

Cisco TechAdvantage Webinars Advanced Multicast Resiliency

Follow us @GetYourBuildOn

Rabiul Hasan

Ujjwal Vinod

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

Panelists Speakers

Ujjwal Vinod Technical Engineer [email protected]

Rabiul Hasan Product Manager

[email protected]

Toerless Eckert Principal Engineer [email protected]

Andy Kessler Technical Leader

[email protected]


•  Submit questions in Q&A panel and send to “All Panelists” Avoid CHAT window for better access to panelists

•  Please complete the post-event survey

•  For WebEx audio, select COMMUNICATE > Join Audio Broadcast

•  Where can I get the presentation? Or send email to: [email protected]

•  Join us for upcoming TechAdvantage Webinars: www.cisco.com/go/techadvantage

•  For WebEx call back, click ALLOW phone button at the bottom of participants side panel


•  Multicast Overview and Business Drivers

•  TI MoFRR

•  Anycast RP using PIM

•  PIM HSRP

•  PIM BFD

•  MVR

Cisco Confidential 5 © 2011 Cisco and/or its affiliates. All rights reserved.


Host

Router

Unicast

Host

Router Multicast

Today we think only of distribution trees when thinking of multicast. But this is not how it started…


By 2014 10% of all Internet video content will be live


•  Audio/Video •  Push Media •  Distribution •  Announcement •  Monitoring

•  Conferencing •  Sharing Resources •  Games •  Others

•  Resource Discovery •  Data Collection •  Others

One to Many Many to Many Many to One

Multicast Applications


  Finance (Trading, Market Data, Financial SP)   Tibco, Hoot-n-Holler, Data Systems

  Enterprise Video and collaborative environments   Cisco TelePresence®, DMS, MP/WebEx

  Video Conferencing, Video Surveillance

  Broadband (Entertainment)   Includes Cable, DSL, ETTH, LRE, Wireless

  Broadcast TV / IP/TV, VOD, Connected Home

  Service Provider (Transit Services)   Native v4 and v6

  Label Switched Multicast (LSM)

  Multicast VPNs (IP and MPLS-based)


“Resilience is the ability or power to return the original form, position, etc., after being bent, compressed or stretched”   Why Multicast Resiliency

  Multicast applications are mission critical and packet loss is not acceptable

  Packet Loss is inevitable and hard to eliminate

  Drop packet is better than delayed packets

  Delayed packet is as good as drop packets

  Resiliency in Multicast   Network Based Solution

- Redundant source, Fast Reroute and Convergence, Path Diversity

  Application Awareness



•  TI MoFRR


•  PIM HSRP

•  PIM BFD

•  MVR


IP/MPLS CORE

EDGE

DISTRIBUTION

ACCESS

EDGE

DISTRIBUTION

ACCESS

Sx2

DR DR

S1 S2

S11 S12

IGMP_REPORT IGMP_REPORT

PIM_JOIN PIM_JOIN DISTR

IBU

TION

-AC

CESS

VRF/Global

VLAN

1

S11 S12

R11 R12

12.1.1.1/24

12.1.1.2/24

13.1.1.1/24

13.1.1.2/24

14.1.1.1/24

14.1.1.2/24

PIM_JOIN PIM_JOIN

RP_ADD: 1.1.1.1/32 RP_ADD: 1.1.1.1/32

PIM_JOIN PIM_JOIN

To reach 1.1.1.1/24 (2 ECMP paths) A) nexthop1: 12.1.1.1 B) nexthop2: 11.1.1.1 Choose 12.1.1.1, since nexthop1 > nexthop2

To reach 1.1.1.1/24 (2 ECMP paths) A) nexthop1: 14.1.1.1 B) nexthop2: 13.1.1.1 Choose 14.1.1.1, since nexthop1 > nexthop2

EDG

E-DISTR

IBU

TION

2

EDG

E-EDG

E

ANYCAST RP Using MSDP 3



•  TI MoFRR


•  PIM HSRP

•  PIM BFD

•  MVR



1)  MoFRR (Multicast Only Fast Re-Route) allows fast reroute for multicast traffic on a multicast router by sending PIM joins on two ECMP upstream interfaces towards the source over disjoint paths in the network.

2)  Thereby receiving two copies of the multicast traffic on two different interfaces

3)  Pick the primary traffic stream to forward downstream and discard the backup stream

4)  A mechanism to detect the failure in the primary stream and switching to the backup stream

5)  MoFRR is a edge functionality and does not require any functionality change in the rest of the network

IP/MPLS CLOUD

Source

Receiver IGMP REPORT

PIM JOIN

STREAM

1

2

3


TOPOLOGIES:

1)  MoFRR was originally proposed for ECMP dual-plane topologies where the node implementing MoFRR has at least two ECMP paths towards the source of the multicast traffic

2)  New enhancements describe how MoFRR can be supported on in non-ECMP or ring topologies

TRIGGERS:

1)  IGP/RIB Based (Routing Protocol Convergence)

2)  Flow Based (Per flow failure detection)

3)  Vidmon http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_serv/configuration/xe-3s/Multicast_only_Fast_Re-Route.html#GUID-96378D82-19DE-4A9B-A7C2-425F61133160

http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/multicast/configuration/guide/mc39mcst.html For Your Reference


1)  Overcomes the ECMP limitation

2)  Simple deployable solution

3)  100% Path Diversity (i.e. TE-like ERO)

4)  Works in any ECMP or Non-ECMP topologies such as mesh, ring, hub-spoke, star, etc.

5)  Consistent and predictable: sub 50 msec solution

6)  No loops or micro-loops in the Network

7)  Present support only for IPv4, with native PIM in global context.

XR 4.3.0

HW dependency: ASR9K platform, with second-generation LC (Typhoon NP) http://www.cisco.com/en/US/products/ps9853/index.html

For Your Reference


HEAD-NODE TAIL-NODE

MID-NODE MID-NODE

MID-NODE MID-NODE

Source Receiver SOURCES & RECEIVERS directly connected to

HEAD-NODE & TAIL-NODE respectively directly


HEAD-NODE TAIL-NODE

MID-NODE MID-NODE

MID-NODE MID-NODE

Source Receiver SOURCES & RECEIVERS indirectly connected to

HEAD-NODE & TAIL-NODE respectively indirectly


HEAD-NODE TAIL-NODE

MID-NODE MID-NODE

MID-NODE MID-NODE

Source Receiver MID-NODEs need not be MoFRR aware


For Your Reference

PIM VER TYPE RESERVED CHECKSUM

UPSTREAM NEIGHBOR ADDRESS (Encoded-Unicast format)

RESVERED # OF GROUPS HOLD TIME

MULTICAST GROUP ADDRESS #1 (Encoded-Group format)

# OF JOINED SOURCES # OF PRUNED SOURCES

JOINED SOURCE ADDRESS #1 (Encoded-Source format)

JOINED SOURCE ADDRESS #N (Encoded-Source format)

PRUNED SOURCE ADDRESS #1 (Encoded-Source format)

PRUNED SOURCE ADDRESS #M (Encoded-Source format)

MULTICAST GROUP ADDRESS #P (Encoded-Group format)

ADDR FAMILY [1/2] ENCODING TYPE [0] RESV B Z MASK LEN

GROUP MULTICAST ADDRESS

ADDR FAMILY [1/2] ENCODING TYPE [0]

……… UNICAST ADDRESS

UNICAST ADDRESS ……

ADDR FAMILY [1/2] ENCODING TYPE [0] RESV S W MASK LEN R

SOURCE ADDRESS

ADDR FAMILY [1/2] ENCODING TYPE [1] RESV S W MASK LEN R

SOURCE ADDRESS

F E ATTR TYPE LENGTH VALUE

F E ATTR TYPE LENGTH VALUE

RFC-4601, 5384, 5496, draft-asghar-pim-explicit-rpf-vector-01

EPV TLV:: There can multiple EPV (Explicit Path Vector) TLV on single encoding

PIM JOIN/PRUNE MESSAGE


1)  Bringing Path-Diversity to Multicast   It’s like RSVP-TE ERO   It allows explicit-routing of PIM Joins  No loops or micro-loops

2)  Explicit Path Vector TLV Encoding: (Example1)

Multicast Source IP: S = 10.0.0.1

: 11.0.0.1

: 12.0.0.1 : 13.0.0.1

: 14.0.0.1

Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

123

41234

PIM JOIN


3)  Explicit Path Vector TLV Encoding: (Example2)   R3: Explicit-Path Vector unaware


: 11.0.0.1

: 13.0.0.1 : 14.0.0.1

Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

12

3123


IGMP/PIM (S,G) JOIN TI-MoFRR

1)  JOIN CLONING: Original (S,G) Join is cloned to (S1,G) and (S2,G) PIM Join   Explicit Path Vector TLV used for PIM-Tree explicit routing   Cloned (S1,G) PIM Join used to build primary PIM tree   Cloned (S2,G) PIM Join is used to build backup PIM tree

2)  TRAFFIC DE-CLONING/TRANSLATION: 3)  P/PE ROLE: 4)  MONITORING & SWITCHING:

(S1,G) PIM JOIN

(S2,G) PIM JOIN


TI-MoFRR

1)  JOIN DE-CLONING: Original (S,G) Join is cloned to (S1,G) and (S2,G) PIM Join   Converts (S1, G) and (S2, G) PIM JOINs to (S, G) PIM JOIN.   Transmit (S,G) PIM JOIN towards upstream neighbor.

2)  TRAFFIC REPLICATION/CLONING:

(S1,G) PIM JOIN

(S2,G) PIM JOIN

(S,G) PIM JOIN


(S,G) Traffic

(S,G) Traffic

(S,G) Traffic

(S1,G) Traffic

(S2,G) Traffic

Head-Node TI-MoFRR Functions: 1. Clone (S1,G) 2. Primary: Re-write S to S1 => (S1,G) 3. Backup: Re-write S to S2 => (S2,G)

Tail-Node TI-MoFRR Functions: 1. Perform MoFRR 2. Specify S1/S2 prefixes in MoFRR 3. Re-write S1 and S2 to S => (S,G)


S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2


S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2

(S1,G) PIM JOIN


S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2

(S1,G) PIM JOIN

(S1,G) IIF: E0 OIF: MoFRR1

(S1,G) IIF: E0 OIF: E1

(S1,G) IIF: MoFRR1 OIF: E1









S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2

(S1,G) PIM JOIN












S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2

(S1,G) PIM JOIN




(S2,G) IIF: E1 OIF: E0 MoFRR1







(S1,G) IIF: E0 OIF: MoFRR1 E1


S: Source

Receiver1

E0

E0

E0 E0

E1

E1 E1

E1 E0 E1

E0 E1

E0 E1

E0 E1

E2

E2

Receiver2 E2

(S1,G) PIM JOIN




(S2,G) IIF: E1 OIF: E0 MoFRR1







(S1,G) IIF: E0 OIF: MoFRR1 E1


CMTS and QAM aggregation

(S,G) Traffic

(S,G) Traffic

(S,G) Traffic

(S1,G) Traffic

(S1,G) Traffic

CMTS1

CMTSn

QAM1

QAMm



: 11.0.0.1

: 12.0.0.1 : 13.0.0.1

: 14.0.0.1

: 15.0.0.1

: 16.0.0.1

: 17.0.0.1 : 18.0.0.1

Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

123

41234

Using Strict ERO (Explicit-hop-by-hop routing, config needed only on last hop)

router pim

rpf-vector process

explicit-rpf-vector inject 10.10.10.1 masklen 24 11.0.0.1 12.0.0.1 13.0.0.1 14.0.0.1


For Your Reference

PIM JOIN

567

8

5678



: 11.0.0.1

: 13.0.0.1 : 14.0.0.1

: 15.0.0.1 : 17.0.0.1

: 18.0.0.1

Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

12

3123

Using Loose ERO (using ERO with RIB lookup, config needed only on last hop)

router pim

rpf-vector process

rpf-vector inject 2.2.2.1 masklen 24 11.0.0.1 13.0.0.1 14.0.0.1


For Your Reference

45

6

456



: 11.0.0.1

: 12.0.0.1 : 13.0.0.1

: 14.0.0.1

: 15.0.0.1

: 17.0.0.1

: 18.0.0.1

Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

123

41234

Using Strict ERO (Explicit-hop-by-hop routing, config needed only on last hop)

router pim

rpf-vector process



For Your Reference

PIM JOIN

56

7

567


Source 10.0.0.1

Receiver

R1

R2 R3 R4

R5

R8 R7 R6

IGMP REPORT

PIM JOIN

router pim

address-family ipv4

mofrr

flow mofrr-acl

clone source 10.0.0.1 to 20.0.0.1 and 21.0.0.1 masklen 32

For Your Reference

PIM JOIN



1)  Anycast-RP in simplistic terms, is a mechanism that ISP-based backbones use to get fast convergence when a PIM Rendezvous Point (RP) router fails.

2)  To achieve this we should have multiple RPs in particular domain. Receivers and sources should initiate communication via closest RP. But to have consistent information across RPs, the packets from a source needs to get to all RPs to find interested receivers.

3)  This notion of receivers finding sources is the fundamental problem of source discovery that MSDP [RFCs 3618, 3446, 4611] was intended to solve.

4)  However, if one would like to retain the Anycast-RP benefits with less protocol machinery and for IPv6 space, there is another option available [RFC 4610].

R1

R2

R3

r1

r2

Data stream for (S1,G1)

IGMPv2 (*,G1) Report

IGMPv2 (*,G1) Report

RP

RP

1 1

1 2

5


1)  R1, R2, R3, R4 are configured with same IP address which is used as the Anycast-RP address (Rx). Let’s assume Rx is configured on interface loopback-0 of all these boxes.

2)  R1, R2, R3, R4 are configured with addresses RP1, RP2, RP3, RP4 respectively which are used by Anycast-RP routers to communicate among each other. Let’s assume these addresses are configured on interface loopback-1 of all these boxes.

3)  All these addresses Rx, RP1, RP2, RP3, and RP4 are injected into the unicast routing database of this complete domain.

4)  Each router in the Anycast-RP set is configured with the addresses of all other routers in the Anycast-RP set. This must be consistently configured in all RPs in the set.

R1

R2

R3

R4

r1

r4

r3

r2

r11

Anycast-RP addr: RPx Loopback addr: RP1 RP-set: {RP1, RP2, RP3, RP4}





1) Src1 starts sending packets

R1

R2

R3

R4

r1

r4

r3

r2

r11

Data stream for (S1,G1) IG

MPv

2 (*

,G1)

IGM

Pv2 (*,G1)

Src1

Src2

Rx1

Rx2

Rx3

Rx4

2) r1 [DR] creates (S1,G1) states and sends a register to R1.

3) Upon receiving the register, R1 performs normal PIM-SM RP functionality.

4) R1 also sends the register (which may encapsulate the data packets) to R2, R3 and R4.

5) R2, R3 and R4 don’t further forward the register to each other.

6) R2, R3 and R4 perform normal PIM-SM RP functionality, and if there are interested receivers, forward the packets on downstream tree built till leaf node.


R1

R2

R3

R4

r1

r4

r3

r2

r11

Src1

Src2

Rx1

Rx2

Rx3

Rx4

IOS Configuration: ipv6 pim rp-address 2001:ABC::1:1 ! interface Loopback0 ipv6 address 2001:ABC::1:1/128 ! interface Loopback1 ipv6 address 2001:111::1:1/128 ! ipv6 pim anycast-rp 2001:111::1:1 2001:111::2:2 2001:111::3:3 2001:111::4:4




1)  No inherent redundancy capability for PIM. 2)  Completely independent of Hot Standby Redundancy Protocol (HSRP) group states. 3)  IP multicast traffic is forwarded not necessarily by the same router elected by HSRP. 4)  Need to provide consistent IP multicast forwarding in redundant network with Virtual Router

Group (VRG) enabled. 5)  Goal is to make HSRP Active Router (AR) interoperable with PIM Designated Router (DR)

and IGMP Querier.

CORE

R1 R2

S1

Gi1/0 Gi1/1

CORE

R1 R2

S1

Gi1/0 Gi1/1

r1

2 PIM neighbors 3 PIM neighbors


6)  Downstream device has static unicast route configuration to VIP (Virtual IP) only.

7)  Allows all PIM Join/Prune to reach the HSRP group VIP. This minimizes changes and configurations at the downstream device side. They need to know just the VIP.

8)  PIM is responsible for adjusting DR priority based on the group state.

CORE

R1 R2

S1

Gi1/0 Gi1/1

r1

Why doesn't PIM Sparse Mode Work with a Static Route to an HSRP Address? http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094aab.shtml


9)  With HSRP Aware PIM enabled, PIM sends an additional PIM Hello message using the HSRP virtual IP addresses as the source address for each active HSRP group when a device becomes HSRP Active.

10) The PIM Hello will carry a new GenID in order to trigger other routers to respond to the failover.

11) The new GenID carried in the PIM Hello will trigger downstream routers to resend PIM Join messages towards the virtual address. Upstream routers will process PIM Join/Prunes (J/P) based on HSRP group state.

12) If the J/P destination matches the HSRP group virtual address and if the destination device is in HSRP active state, the new AR processes the PIM Join because it is now the acting PIM DR.

CORE

R1 R2

S1

Gi1/0 Gi1/1

r1

PIM HELLO

Existing active going down


1)  Stateful failover is not supported.

2)  During PIM stateless failover, the HSRP group's virtual IP address transfers over to the standby, but no mroute sate information is transferred to the standby.

3)  HSRP IPv6 is not supported.

4)  Not supported with VRRP, GLBP.

CORE

R1 R2

S1

Gi1/0 Gi1/1

r1

NO MROUTE STATE SYNC


  R3/R4 configure static route to Rx, always use Rx as nexthop when sending PIM J/P messages.

R1 R2

S1

Gi1/0 Gi1/1

S2

R3 R4 Gi1/2 Gi1/3

Rx

  PIM Hello got exchanged among R1, R2, R3, R4.

  R3/R4 receive PIM hello from R1, R2 and Rx, they have Rx as both RPF and PIM neighbor.

1

2   Say, R1 was acting as Active Router. PIM Hello is also sent

by R1 with Rx as source address. PIM Hello from Rx will carry a pre-configured PIM DR priority for HSRP, which ensures new active always becomes new DR for this subnet.

3

4

  From downstream, PIM J/P should be sent with nexthop as Rx. AR node should process this message.

IGMP REPORT


R1 R2

S1

Gi1/0 Gi1/1

S2

R3 R4 Gi1/2 Gi1/3

Rx   Upon failover (e.g., upstream interface down on S1), R2 (standby) became new active and sent additional PIM Hello by 1) using Rx as source address; 2) increases DR priority as configured.

4

5

  R3/R4 received Hello from Rx, added Rx as PIM neighbor and sent PIM Join messages for all (*, G) and (S, G) to Rx.

6

  R2 as HSRP AR and processed the PIM Join and immediately reestablished the states.

  Mroute states on R1 will expired eventually.


CORE

R1 R2

S1

Gi1/0 Gi1/1

r1

IOS Configuration: interface GigabitEthernet1/1 ip address 10.0.0.2 255.255.255.0 ip pim redundancy HSRP1 dr-priority 50 ip pim sparse-mode standby 1 ip 160.1.1.99 standby 1 timers 3 10 standby 1 priority 100 standby 1 preempt standby 1 name HSRP1 standby 1 track GigabitEthernet1/10

NOTE: There is no change on IGMP Querier election mechanism, which operates independently of HSRP. It is possible that IGMP querier and PIM DR are different routers.



1)  The minimum failure detection time in PIM will be 3 times of the PIM Query-Interval.

2)  PIM Query-Interval is sub-sec range.

3)  Lower time intervals considerable load on the Protocol, CPU. Not recommended!

CORE R1 R2

S1

NON-DR DR Gi1/0 Gi1/1

  Configured hello interval: 100 msec   R1: Gi1/0, elected as DR.   Node R1 powered down.   After approx. 300 sec, R2 will get to know

about neighbor down event.

POWER DOWN


  Bi-Directional Forwarding (BFD) is based on UDP and IP.   Session based.   Agnostic to the type of media.   For supporting BFD in PIM:

  PIM registers to the BFD as a client   Enables PIM to interface with BFD to initiate a session with an adjacent PIM node   Single PIM client registration will be done for both PIM v4 and PIM v6.

  The neighbor with which BFD session is established can either be a directly connected neighbor or a multi-hop neighbor.

R1

BFD

PIM v4/6

R2

BFD

PIM v4/6 Hello / Discovery

PIM bootstraps BFD

R1 R2


Following configurations must be done to use this function: 1)  Relevant PIM configuration on the interested interface 2)  BFD to be enabled on the interested interface 3)  PIM BFD to be enabled on the interested interface NOTE:   This feature will not be supported for MVPN (over MDT tunnels)   Only supported on interfaces in which both PIM and BFD are supported   Supported for PIM-v4/6   Supported with vrf interfaces also

IOS Configuration: interface GigabitEthernet0/2.2 encapsulation dot1Q 2 vrf forwarding vpn_0 ip address 20.3.0.1 255.255.255.0 ip pim sparse-dense-mode ip pim bfd ip igmp version 3 bfd interval 50 min_rx 50 multiplier 3 no bfd echo

NXOS Configuration: interface Ethernet0/0 ip pim bfd instance


© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 56 56

VLAN 30 VLAN 10 VLAN 20 VLAN 30 VLAN 10 VLAN 20

R1

S1 S1

R1

Stream flow *without* MVR configuration at S1

VLAN 50

Stream flow *with* MVR configuration at S1

•  It allows a L2 switch to deliver multicast packet to multiple receivers reside in different VLANs without L3 replication

•  Traffic isolation and flooding domain between VLANs are maintained for other kinds of traffic, such as unknown unicast and broadcast traffic


VLAN 30 VLAN 10 VLAN 20

MVR VLAN: A designated VLAN where multicast traffic is received. Hosts can be member of MVR VLAN.

R1

S1

VLAN 50

(*,G1) IGMP report

MVR SOURCE PORT: IGMP joins and Multicast data are copied to MVR source port.

MVR RECEIVER PORT: Interfaces where mcast Receivers are connected to.

MVR GROUP: The IGMP group that participate the MVR. Same group can be used for non-MVR receiver port also.



IGMP join is processed by MVR when two conditions are met:   Interface on which the join is received has to be MVR

receiver port   The group has to be configured as MVR group

MVLAN: 50 MVR SOURCE PORT: #1 MVR RECEIVER PORT: #2, 4 NON-MVR PORT: #3 MVR GROUP: G1 BASIC DESIGN GUIDELINES:   MVR requires IGMP Snooping to function properly.   Same MVR VLANs and same MVR VLAN to MVR group

mapping on all switches in the network.

R1

S1

VLAN 50

(*,G1) IGMP report

(*,G2) IGMP report

#1

#2 #3 #4

(*,G1) IGMP report



R1

S1

VLAN 50

(*,G1) IGMP report

IOS Configuration: mvr -------------------------------- Enables MVR on device mvr vlan 200 ---------------------- MVR VLAN mvr max-groups 8000 ------------ Max# of MVR groups mvr group 227.1.1.1 4000 mvr group 227.1.16.161 3900 mvr group 227.1.32.55 100 interface GigabitEthernet2/0/0 switchport switchport access vlan 100 switchport mode access mvr type receiver ---------------------- MVR source port (Receiver

ports can only be access ports) interface GigabitEthernet2/0/1 switchport switchport trunk allowed vlan 100,101,200 switchport mode trunk mvr type source ---------------------- MVR receiver port (Source

ports can be either access or trunk ports)

-------- MVR group addresses



R1

S1

VLAN 50

(*,G1) IGMP report

NXOS Configuration: mvr-config mvr-vlan 1000 mvr-group 224.1.1.0/24 mvr-group 225.1.1.0/24 mvr-group 226.1.1.0/24 mvr-group 228.1.1.0/24 vlan 1002 -------- (Support one global MVR VLAN and up to 250 MVR VLANs in total) interface Ethernet1/34 switchport access vlan 101 mvr-group 226.1.1.1 count 10 vlan 1001 --------- (Interface level configuration takes precedence over global MVR configuration) mvr-type receiver interface Ethernet1/34 switchport mode trunk switchport trunk allow vlan 1000-1002 mvr-type source


•  Thank you! •  Please complete the post-event survey •  Join us for upcoming webinars:

Register: www.cisco.com/go/techadvantage Follow us @GetYourBuildOn

Technology

Advanced Multicast Resiliency Webinar