From: eDu (eeduuu@hotmail.com)
Date: Wed Feb 09 2005 - 07:55:22 GMT-3
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