From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Wed Feb 09 2005 - 13:24:16 GMT-3
Lab it up and you will see...
For the dense-mode group, the static mroute is about the originating
source of the (S,G) mroute. So it will apply to the static mroute
source (that's why its 1.1.1.1 for the group 255.5.5.5) for ALL groups
G.
The static mroute overrides the IGP as the source for an RPF.
Lab it up and see.
HTH,
Andy
-----Original Message-----
From: eDu [mailto:eeduuu@hotmail.com]
Sent: Wednesday, February 09, 2005 2:55 AM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: Re: multicast question
Firstly, thanks for your explanation. It's quite clear.
Just one thing.
If you have a mcast source with ip 1.1.1.1 sending traffic to mcast
group 255.5.5.5, you say I should configure the following static route:
Ip mroute 1.1.1.1 255.255.255.255 static 2.2.2.2 (where 2.2.2.2 is the
unicast next-hop toward the RPF neighbor). But this route doesn't talk
about the group. So, this route would be valid for every mcast group .
Am I wrong? Is not possible to have different mcast static routes for
different groups?
----- Original Message -----
From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
To: "eDu" <eeduuu@hotmail.com>; <ccielab@groupstudy.com>
Sent: Tuesday, February 08, 2005 6:26 PM
Subject: RE: multicast question
> Depends upon what you are trying to do exactly, but a combination of
> mroutes and tunnels would be required for the hub to continue the RPF
> towards a downstream spoke receiver.
>
> One way:
>
> Build a tunnel towards the source of the DM group. Do NOT enable pim
> dense-mode on the source for the DM groups serial interface. Only
> enable pim dense-mode on the tunnel between the source and the hub
> tunnel interfaces.
>
> Now, enable pim dense mode on the hub frame interface and the
> receiving spoke frame interface.
>
> If you do this, then you don't need mroutes because the source of the
> DM group is through the tunnel and traffic would be arriving on the
> tunnel thereby passing the RPF. As long as the hub frame interface is
> in the OIL for the parent (*,G) then it will forward along the
> downstream path towards the receiving spoke.
>
> Another way:
>
> Build a tunnel between the receiving spoke and the hub. Enable pim
> dense-mode on all frame interfaces and on the tunnel between the hub
> and receiving spoke router. On the receiving spoke use a static
> mroute that points towards the source of the DM traffic such that the
> next hop is the other end of the tunnel interface. This will pass the
> RPF for the spoke receiver.
>
> And to answer your final question, the RPF is done towards the source
> for dense-mode traffic and towards the RP for sparse-mode (excluding
> the RP-Prune).
>
> So, if the question was to source dense mode traffic from 1.1.1.1
> towards the 255.5.5.5 group, the mroute would be a (1.1.1.1,
> 255.5.5.5) entry. And, if the next hop up the RPF was 2.2.2.2, you
> would have a static mroute such as:
>
> Ip mroute 1.1.1.1 255.255.255.255 static 2.2.2.2
>
> Then a show ip mroute will indicate that the (1.1.1.1,255.5.5.5) as
> MROUTE. <- indicates static mroute.
>
> Just remember that when it comes to multicast, static mroutes and
> tunnels are your friends.
>
> HTH,
>
> Andy
>
> -----Original Message-----
> From: eDu [mailto:eeduuu@hotmail.com]
> Sent: Tuesday, February 08, 2005 12:18 AM
> To: ccielab@groupstudy.com
> Subject: multicast question
>
>
> Hello everybody.
> I passed the beta written exam (it was pretty difficult) and now I'm
> starting up with the lab. I've got a question for you. If I have 3
> routers connected in a multipoint frame-relay, in a hub-and-spoke
> manner, and I configure PIM DM between them, I have a problem. The
> problem is that the hub router receive the traffic from one of the
> spokes, but it doesn't send it to the other. I think it's not possible
> to add the same interface to both incoming and outgoing interface
> list. The first solution I guess is the use of gre tunnels. The second
> one is to configure static mroutes, but I don't know what routes.
>
> Sure you've seen this scenario before. Any idea?
>
> R1
> |
> __________|__________
> | |
> R2 R3
> |
> |
> Multicast
> source
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Mar 03 2005 - 08:51:18 GMT-3