Saleh,
Do we really need the frame-relay map broadcast on the hub !? Assume for a
moment that the hub is using physical interface for frame-relay connection,
then that supports broadcast by default (see output below), but
irrespective we have psuedo-broadcast capability -
Pooky#show frame-relay map
Serial0/0 (up): ip 192.168.234.2 dlci 402(0x192,0x6420), dynamic,
* broadcast,*
CISCO, status defined, active
Serial0/0 (up): ip 192.168.234.3 dlci 403(0x193,0x6430), dynamic,
* broadcast,*
CISCO, status defined, active
What I noted was that in my debugs from the hub (see below), my pings work.
Then my spoke 192.168.234.2 sets the RPT so going into share tree mode. So
hub prunes my PIM NBMA interface to my spoke. Then everything stops.
*Mar 1 02:31:40.291: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0)
id=227, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:40.299: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1
(FastEthernet1/0) id=227, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:40.311: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0)
id=227, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:40.319: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1
(FastEthernet1/0) id=227, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:40.327: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=227, ttl=254, prot=1, len=104(100), mroute olist null
*Mar 1 02:31:40.327: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=227, ttl=254, prot=1, len=104(100), mroute olist null
*Mar 1 02:31:40.359: PIM(0): Received v2 Join/Prune on Serial0/0 from
192.168.234.2, to us
**Mar 1 02:31:40.363: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1) RPT-bit
set
*Mar 1 02:31:40.367: PIM(0):* *Prune Serial0/0/192.168.234.2 from (
3.3.3.3/32, 224.1.1.1) - deleted*
**Mar 1 02:31:40.383: PIM(0): Received v2 Join/Prune on Serial0/0 from
192.168.234.2, to us
*Mar 1 02:31:40.383: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1) RPT-bit
set*
**Mar 1 02:31:42.299: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=228, ttl=254, prot=1, len=104(100), mroute olist null
*Mar 1 02:31:42.311: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=228, ttl=254, prot=1, len=104(100), mroute olist null*
*Mar 1 02:31:42.319: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1
(FastEthernet1/0) id=228, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:42.323: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1
(FastEthernet1/0) id=228, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:31:42.931: PIM(0): Received v2 Join/Prune on FastEthernet1/0
from 192.168.45.5, to us
*Mar 1 02:31:42.935: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1)
*Mar 1 02:31:42.939: PIM(0): Prune FastEthernet1/0/224.1.1.1 from (
3.3.3.3/32, 224.1.1.1)
*Mar 1 02:31:42.943: PIM(0): Insert (3.3.3.3,224.1.1.1) prune in nbr
192.168.234.3's queue - deleted
*Mar 1 02:31:42.947: PIM(0): Building Join/Prune packet for nbr
192.168.234.3
*Mar 1 02:31:42.951: PIM(0): Adding v2 (3.3.3.3/32, 224.1.1.1), S-bit Prune
*Mar 1 02:31:42.951: PIM(0): Send v2 join/prune to 192.168.234.3
(Serial0/0)
Pooky#
Pooky#
*Mar 1 02:31:44.315: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=229, ttl=254, prot=1, len=104(100), mroute olist null
*Mar 1 02:31:44.323: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1
id=229, ttl=254, prot=1, len=104(100), mroute olist null
Pooky#
If I add back in the static mroute everything works again.
*Mar 1 02:47:34.855: PIM(0): Received v2 Join/Prune on Serial0/0 from
192.168.234.2, to us
*Mar 1 02:47:34.859: PIM(0): Join-list: (3.3.3.3/32, 224.1.1.1), S-bit set
*Mar 1 02:47:34.863: PIM(0): Add Serial0/0/192.168.234.2 to (3.3.3.3,
224.1.1.1), Forward state, by PIM SG Join
*Mar 1 02:47:34.867: PIM(0): Insert (3.3.3.3,224.1.1.1) join in nbr
192.168.234.3's queue
*Mar 1 02:47:34.871: PIM(0): Received v2 Join/Prune on Serial0/0 from
192.168.234.2, to us
*Mar 1 02:47:34.875: PIM(0): Join-list: (3.3.3.3/32, 224.1.1.1), S-bit set
*Mar 1 02:47:34.879: PIM(0): Update Serial0/0/192.168.234.2 to (3.3.3.3,
224.1.1.1), Forward state, by PIM SG Join
Pooky#
*Mar 1 02:47:34.883: PIM(0): Building Join/Prune packet for nbr
192.168.234.3
*Mar 1 02:47:34.887: PIM(0): Adding v2 (3.3.3.3/32, 224.1.1.1), S-bit Join
*Mar 1 02:47:34.891: PIM(0): Send v2 join/prune to 192.168.234.3
(Serial0/0)
*Mar 1 02:47:35.751: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0)
id=244, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:47:35.759: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0)
id=244, ttl=253, prot=1, len=100(100), mforward
Now in this situation everything is going through the hub, so the prunes
and joins are going in and out of the same sub interface, so to override
the prune I guess we need to force a join via the Hub, using the static
mroute.
Alternative methods are point-to-mupoint or point to point, or a GRE tunnel
from spoke to spoke. I dont think Unicast communication between spokes is
enough. Would like to hear thoughts more on this.
B
On Thu, Jan 3, 2013 at 10:38 AM, Saleh Batouq <[email protected]> wrote:
> ---------- Forwarded message ----------
> From: Saleh Batouq <[email protected]>
> Date: Thu, Jan 3, 2013 at 3:36 AM
> Subject: Re: [OSL | CCIE_RS] pim nbma mode
> To: Maureen Maina <[email protected]>
>
>
> Hi Maureen,
>
> I don't think so. The broadcast keyword is needed only once per each dlci.
> so if you add it in the map statement to the hub its enough. Why its needed
> for SPOKE-to-SPOKE is because the multicast ping is sourced from that spoke
> ip-address so a map is needed for it in order to be replied to. Plus as you
> mention RIP and OSPF (NBMA) does not change the next-hop address so spoke
> to spoke reachability is required and the only way is to have FR-MAPS to
> each other.
>
> Are you using GNS or real Racks. Sometimes GNS has some issues with
> multicasts. Try to repeat the ping several times you should get a response.
>
> Good luck mate.
>
>
> On Wed, Jan 2, 2013 at 4:49 PM, Maureen Maina <[email protected]> wrote:
>
> > Hi Saleh,
> > The frame-relay mappings were present though not with the "broadcast"
> > keyword as this is spoke to spoke.All spoke to hub mappings had the
> > broadcast keyword.
> > Maybe thats why it can be used to forward multicast traffic?
> >
> >
> > Regards,
> > Mo
> >
> > On Mon, Dec 31, 2012 at 9:07 PM, Saleh Batouq <[email protected]
> >wrote:
> >
> >> Hi Naureen,
> >>
> >> I replicated your topology using OSPF NMBA mode instead of RIP. It works
> >> fine.
> >> And from your output of the show routes it looks that both shared &
> >> source trees are built.
> >>
> >> *For pings to be replied the spokes need frame-relay maps to each other
> >> (SPOKE-to-SPOKE). I assume you are missing this.*
> >>
> >> My outputs are similar to yours and ping works fine.
> >>
> >> SPOKE R1
> >> ----
> >>
> >> (*, 239.1.1.1), 00:10:29/stopped, RP 10.1.1.2, flags: SJCLF
> >> Incoming interface: Serial0/0, RPF nbr 172.16.0.2
> >> Outgoing interface list:
> >> Loopback0, Forward/Sparse, 00:10:29/00:02:12
> >> !
> >> (10.1.1.3, 239.1.1.1), 00:00:58/00:02:07, flags: LJT
> >> Incoming interface: Serial0/0, RPF nbr 172.16.0.3
> >> Outgoing interface list:
> >> Loopback0, Forward/Sparse, 00:00:58/00:02:12
> >> !
> >>
> >>
> >> SPOKE R3
> >> -----
> >>
> >> (*, 239.3.3.3), 00:10:35/stopped, RP 10.1.1.2, flags: SJCLF
> >> Incoming interface: Serial0/0, RPF nbr 172.16.0.2
> >> Outgoing interface list:
> >> Loopback0, Forward/Sparse, 00:10:35/00:02:43
> >>
> >> (10.1.1.1, 239.3.3.3), 00:01:06/00:01:56, flags: LJT
> >> Incoming interface: Serial0/0, RPF nbr 172.16.0.1
> >> Outgoing interface list:
> >> Loopback0, Forward/Sparse, 00:01:06/00:02:43
> >>
> >> On Mon, Dec 31, 2012 at 7:18 PM, Maureen Maina <[email protected]>
> wrote:
> >>
> >>> Hi,
> >>> I have a simple scenario of hub and spoke frame-relay. R1-R2-R3. I opt
> to
> >>> use pim nbma with sparse mode under the R2 interface to allow multicast
> >>> traffic from R1 to flow to R3.
> >>> However due to the fact I was using rip , the next hop remains
> unchanged
> >>> for all routes propagated from spoke to spoke. The RP is connected to
> the
> >>> hub R2. the source x.x.x.x is connected to R1 . A show ip mroute on R3
> is
> >>> as follows..
> >>>
> >>> *NO STATIC RPF workaround needed.*
> >>
> >> regards,
> >>
> >>
> >>
> >>> (*, 232.2.2.2), 04:40:25/stopped, RP 172.16.200.13, flags: SJCL
> >>> Incoming interface: Serial0/0/0:0, RPF nbr <R2 address>
> >>> Outgoing interface list:
> >>> Loopback102, Forward/Sparse, 04:40:25/00:02:24
> >>>
> >>> (x.x.x.x, 232.2.2.2), 00:06:07/00:00:43, flags: LJT
> >>> Incoming interface: Serial0/0/0:0, RPF nbr <R1 address>
> >>> Outgoing interface list:
> >>> Loopback102, Forward/Sparse, 00:06:07/00:02:24
> >>>
> >>> So on the shared tree, all is well but when it switches to the source
> >>> based
> >>> tree , the pings dont go through.
> >>> When I apply an mroute x.x.x.x 255.255.255.255 <R2 address> it works!
> >>> Is this a rule of pim nbma that the hub must be seen as rpf neighbor?
> >>>
> >>> Regards,
> >>> Maureen
> >>> _______________________________________________
> >>> For more information regarding industry leading CCIE Lab training,
> >>> please visit www.ipexpert.com
> >>>
> >>> Are you a CCNP or CCIE and looking for a job? Check out
> >>> www.PlatinumPlacement.com
> >>>
> >>> http://onlinestudylist.com/mailman/listinfo/ccie_rs
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >>
> >> Saleh Hassan Batouq
> >> [email protected]
> >> Tel: +968 99365607
> >> Fax: +968 2469690
> >> P.O.Box:1083- Postal Code:112
> >> Muscat-Sultanate Of Oman
> >>
> >
> >
>
>
> --
> Best Regards,
>
> Saleh Hassan Batouq
> [email protected]
> Tel: +968 99365607
> Fax: +968 2469690
> P.O.Box:1083- Postal Code:112
> Muscat-Sultanate Of Oman
>
>
>
> --
> Best Regards,
>
> Saleh Hassan Batouq
> [email protected]
> Tel: +968 99365607
> Fax: +968 2469690
> P.O.Box:1083- Postal Code:112
> Muscat-Sultanate Of Oman
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
> Are you a CCNP or CCIE and looking for a job? Check out
> www.PlatinumPlacement.com
>
> http://onlinestudylist.com/mailman/listinfo/ccie_rs
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
http://onlinestudylist.com/mailman/listinfo/ccie_rs
