Catalyst Multicast VLAN Registration

Salaam,

I continue I am posting again a new Feature that i have just learned it .  (Because I reserve this Blog to post just the new features i learn in order to help me memorizing them, and also, in order to explain them as very simple than other docs..)

Today, i'm explaining the MVR : Multicast Vlan Registration !!  (this name don't make for me any sense with what the feature really do !! :-)  )

When you have an Access Layer Metro, and each Access Router has different Vlan for Multicast, thus in the aggregation layer of that Metro, it will be heavy to send multicast on every access vlan.

As a solution (without change all vlan to one vlan like 50 in IAM Metro), we can use one aggregation vlan for Multicast , and then, for every access router, configure MVR feature.

In fact, MVR feature will do the traduction between the local multicast vlan and the aggregation multicast vlan.  In fact, when the access router receive a join from his receivers (in the local vlan) , so the router transfer the Join to the Aggregation Multicast vlan.

 And also after this, it transfer the Multicast Feed from the Aggregation Vlan to the local multicast vlan…

Notes:  
+ It’s me who name it as “aggregation” vlan
+ We should mandatory disable ip multicast-routing on switch, in order to let MVR work..

Configuration

All the configuration is done on the Access Router, w e should configure following items:

> Configure MVR globally

> Configure which is the Agg Multicast VLAN

> Configure the dynamic mode of mvr (not compatible which is default one)

> Source Interface of Aggregation Multicast VLAN

> Receiver Interface toward the Receiver VLAN

!
no  ip  multicast-routing  distribution

mvr

mvr vlan 146

mvr group dynamic

!

interface  fastethernet 0/1

  mvr  type  source

interface  fastethernet 0/5

  mvr  type  receiver

!

in this case, in f0/1 we receive the Multicast on vlan 146, and in 0/5 there is receivers on vlan58, thus,  joins received in 0/5 will be transferred to 0/1, and also multicast feed received on 0/1 will be translated to 0/5.. !!

Multicast BGP

 Salaaaam, 

Today, i'm explaining "Tough" MulticastBGP, because several Network Engineers complain that they don't get what the motivation for MBGP and what's the benefit from using Multicfast BGP instead of normal BGP in a Multicast Environnement between several AS.

Multicast BGP Extension is used to control the Multicast Path between 2 AS. 

In fact, the control of Multicast Path is like this:

Normally, RPF check is the method used to establish the Path that multicast flow will follow, for example, Join are sent from downstream routers to Source according to the RPF interface, thus establishing the RPT or SPT..   We should notice that , the RPF check is based on Unicast Routing Table,

The process below lead that if we have several Paths between 2 AS, so multicast path will be similar to other Unicast flows paths, thus it’s difficult to control the multicast differently.

One solution to this issue, is using MulticastBGP, in fact MulticastBGP is like MPBGP, in fact it fill a speciall BGP table , called the “multicast address family” table, filling that table is like filling with MBGP a table of a VPN (VRF)..   so the Benefit is that, when you are using the address family multicast,  So , When RPF find the Mutlticast BGP address family , so it use this table instead of Unicast Routing Table!!!

So by this table, we can control multicast path, independly from unicast traffic..!!

CONFIGURATION

+ Configuration of PIM, RP, AutoRP, BSR ,… all is normal

+ Configuration of MulticastBGP part:

à Configure BGP with 2 parts: the ipv4 family part, and the multicast family part

Example:

       

Before configuration, Just Normal BGP:

!

router bgp 100

 neighbor 150.1.7.7 remote-as 100

 neighbor 150.1.7.7 update-source Loopback0

 neighbor 150.1.7.7 next-hop-self

 neighbor 155.1.146.4 remote-as 200

 redistribute ospf 1

!

Configuration Changes with MulticastBGP (delete the general neighbor relation, and configure 2 independants families : unicast family and multicast family)

router bgp 100

 bgp log-neighbor-changes

 neighbor 150.1.7.7 remote-as 100

 neighbor 150.1.7.7 update-source Loopback0

 neighbor 155.1.146.4 remote-as 200

 !

 address-family ipv4

  redistribute ospf 1

  neighbor 150.1.7.7 activate

  neighbor 150.1.7.7 next-hop-self

  neighbor 155.1.146.4 activate

  no auto-summary

  no synchronization

 exit-address-family

 !

 address-family ipv4 multicast

  redistribute ospf 1

  neighbor 150.1.7.7 activate

  neighbor 150.1.7.7 next-hop-self

  neighbor 155.1.146.4 activate

  no auto-summary

  no synchronization

 exit-address-family

Generate UDP Broadcast using DNS

Today i will show a small hint for how to generate a UDP broadcast using DNS , Note that this feature can be important to test the Multicast Helper function:


1) we enable DNS domain lookup (enabled by default,  conf# ip domain lookup)
2) we issue   a dummay lookup :     router#koko

PIM SPARSE DENSE Mode

Salam Everyone,

Today , I want to explain IP PIM SPARSE DENSE MODE

One of the great concept i have just learn is the pim sparse dense mode, which is an hybrid mode of both Pim SM and DM, it's just amazing because you can let routers work in both modes..

you will say , how the router will now that for that group X use SM mode, and for that group Y, use DM mode.

in fact, when some triggering event happen and a router want to send a multicast packet , so the router will see if he has some RP mapping with that group, he look if he has some static mapping with that Group or Auto-RP or BootStrap (BSR). If he find an RP mapping for that group, so he start using the normal PIM SM process, for example if the router is near the source so he send Register toward RP, and ...

If he don't find any RP mapping, so he just proceed with the normal DM mode, so it means execute RPF test and then forward directly multicast till he receive or not some prune message from his downstream routers ..

note:  for configuration use: (IF) ip pim sparse-dense mode

IGMP Timers

Today i'm explaining the "hated" thousands of IGMP Timers :)

First, we should all remember, that in a LAN environnement, the Elected IGMP Querier is the lowest IP address.  (remember that this is reserved for IGMP2, IGMP1 has a PIM election procedure)

1)   (IF)  ip  igmp  query-interval <sec>

Time interval between each Sending the General Query Message by Router to check which Channels are seen by hosts

default = 60s

2)   (IF)  ip  igmp  query-max-response-time  <1/10th of sec>

this is MRT, this timer is sent within the General Query message. in fact, each host, when receiving the General Query, he set a   0.1<random timer<MRT  before he answer with a report the Router.

Note that, if a host already hear a Report for his Group from some other host, before that host reach his chosen random timer.  so that host will not send a Report to Router.

3)   (IF)  ip  igmp  last-member-query-interval  <sec>

After a Router receive a Leave Message for some Group, he wait for that amount of time before he send a Specific Query about that Group to see of there is some other hosts still using that Group.

default = 1s

4)   (IF)  ip  igmp  last-member-query-count <numb>

Note that, as we have seen in 3), when Router receive a Leave , he send a Specific Query for that Group, in fact, by default he do this twice in order to be sure, we can adjust how many time he send that Specif Query by this command.

default = 2 times

5)   (IF)  ip  igmp  querier-amount  <sec>

Backup Querier becomes an active one if it does not hear queries from the other router within this amount of time

default =  2 x Querier Interval   

Some final notes:

--> Note that a Router keep an IGMP ( * , G)  state before suppress by default to 3 x Query Interval