Sorry all,Long printout here. Bottom line: removal of "ip pim autorp listener"
did not fix the problem on R4. I start with R2 having this command enabled,
then remove it and clear the rp map table. After a while, R2 again learns of
the RP mapping table (this surprised me as I didn't think it would) however,
even with NMBA mode on R2, R4 still does not learn the mappings nor receive any
multicast whatsoever.
R2
interface Serial0/1/0
ip address 10.1.1.2
255.255.255.0
ip pim nbma-mode
ip pim sparse-mode
encapsulation
frame-relay
ip ospf network
point-to-multipoint
frame-relay map ip
10.1.1.5 205 broadcast
frame-relay map ip
10.1.1.4 204
frame-relay map ip
10.1.1.2 204 broadcast
no frame-relay
inverse-arp
R2#sh ip ospf nei
Neighbor ID
Pri State Dead Time Address Interface
4.4.4.4
0 FULL/ -
00:01:47 10.1.1.4 Serial0/1/0
5.5.5.5
0 FULL/ -
00:01:51 10.1.1.5 Serial0/1/0
R2#sh ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
DR Priority,
S - State
Refresh Capable
Neighbor
Interface
Uptime/Expires Ver DR
Address
Prio/Mode
10.1.1.4
Serial0/1/0
00:03:01/00:01:40 v2 1 / S P
10.1.1.5
Serial0/1/0
00:03:03/00:01:38 v2 1 / DR S P
R2#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 7.7.7.7 (?), v2v1
Info source:
7.7.7.7 (?), elected via Auto-RP
Uptime:
00:02:34, expires: 00:02:23
R4
--
interface Serial0/0/0
ip address 10.1.1.4
255.255.255.0
ip pim sparse-mode
encapsulation
frame-relay
ip ospf network
point-to-multipoint
frame-relay map ip
10.1.1.5 402
frame-relay map ip
10.1.1.2 402
frame-relay map ip
10.1.1.4 402 broadcast
no frame-relay
inverse-arp
R4#sh ip ospf nei
Neighbor ID
Pri State Dead Time Address Interface
2.2.2.2
0 FULL/ -
00:01:43 10.1.1.2 Serial0/0/0
R4#sh ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
DR Priority,
S - State
Refresh Capable
Neighbor
Interface
Uptime/Expires Ver DR
Address
Prio/Mode
10.1.1.2
Serial0/0/0
00:04:31/00:01:38 v2 1 / S P
R4#sh ip pim rp map
PIM Group-to-RP Mappings
****REMOVE AUTORPLISTENER FROM R2****
R2(config)#no ip pim autorp listener
R2(config)#do clear ip pim rp-map
R2(config)#end
R2#sh ip pim rp map
PIM Group-to-RP Mappings
R2#sh ip pim rp map
PIM Group-to-RP Mappings
***(went to put the kettle on here!)***
R2#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 7.7.7.7 (?), v2v1
Info source:
7.7.7.7 (?), elected via Auto-RP
Uptime:
00:00:46, expires: 00:02:12
R2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM
Group, C - Connected,
L - Local, P -
Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit
set, J - Join SPT, M - MSDP created entry,
X - Proxy Join
Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I -
Received Source Specific Host Report,
Z - Multicast
Tunnel, z - MDT-data group sender,
Y - Joined
MDT-data group, y - Sending to MDT-data group,
V - RD &
Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert
winner
Timers:
Uptime/Expires
Interface state:
Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:02:26/stopped, RP 0.0.0.0, flags: DP
Incoming interface:
Null, RPF nbr 0.0.0.0
Outgoing interface
list: Null
(7.7.7.7, 224.0.1.39), 00:02:26/00:00:33, flags: PT
Incoming interface:
Serial0/1/0, RPF nbr 10.1.1.5
Outgoing interface
list: Null
(*, 224.0.1.40), 00:04:50/stopped, RP 0.0.0.0, flags: DCL
Incoming interface:
Null, RPF nbr 0.0.0.0
Outgoing interface
list:
Loopback0,
Forward/Sparse, 00:04:51/00:02:28
(7.7.7.7, 224.0.1.40), 00:04:51/00:02:07, flags: LT
Incoming interface:
Serial0/1/0, RPF nbr 10.1.1.5
Outgoing interface
list:
Loopback0,
Forward/Sparse, 00:04:51/00:02:28
R4#sh ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
DR Priority,
S - State
Refresh Capable
Neighbor
Interface
Uptime/Expires Ver DR
Address
Prio/Mode
10.1.1.2
Serial0/0/0 00:15:28/00:01:29
v2 1 / S P
R4#sh ip pim rp map
PIM Group-to-RP Mappings
R4#debug ip mpacket
IP multicast packets debugging is on
R4#sh clock
*19:02:45.591 UTC Tue May 29 2012
R4#sh clock
*19:05:04.411 UTC Tue May 29 2012
Date: Tue, 29 May 2012 21:34:36 +0300
Subject: Re: [OSL | CCIE_RS] Multicast over NBMA Revisted and Retyped and typo
corrected!
From: [email protected]
To: [email protected]
CC: [email protected]
hello George Leslie, you may be partially correct , but the job of ip ospf
netwrok point to multipoint is to inject /32 host routes .
so you dont need " spoke to spoke " layer 3 to layer 2 mapping . you can use
it for self pinging but not for spoke to spoke mapping
secondly ..... if spoke see them selves as next hops ( ospf nbma network type)
, then we will run in issues . let say RP is on one spoke and another spoke
wants to send *,G request but lack a physical circuit and ends up in sending
it to hub ( hub and spoke & ospf nbma nework type , here spoke to spoke
connectivity is via a layer 3 to layer 2 mapping and not via /32 host routes) .
what is the TTL of (*,G) ...? ONE but to reach RP (on spoke ) , the
initaiator of (*,G) must have a direct physical circuit like the hub else TTL
of *, G packet expires and it will not be able to make it RP WHICH is a spoke .
i will be waiting for your obervation on this . thanks
On Tue, May 29, 2012 at 8:55 PM, George Leslie <[email protected]>
wrote:
Hi Imran,
It is a matter of debate if the additional frame maps are unwanted or not!! If
a lab is asking for "full IP connectivity", then that may include self-ping
from a router to its own IP addresses. They were put in for that purpose, so
the same TCL script could be run on all routers to check full IP connectivity
before starting the multicast testing.
They should have no detrimental effect on multicast whatsoever, the same way
that unneeded IP ARP entries pointing out an ethernet have no bearing on
multicast operation.
Am about to lab up again to see if your solution would have worked.....
Hope I get done before my session expires in 1h 45min!!
George.
Date: Tue, 29 May 2012 18:36:19 +0300
Subject: Re: [OSL | CCIE_RS] Multicast over NBMA Revisted and Retyped and typo
corrected!
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
you have added un wanted frame-relay map statments on spokes , as the topology
is ospf point to multipoint , no need arises to have spoke to spoke mapping .
Do a reload after removing the unwanted frame mappings , then give me the
result .
mean while i will run your topology and put a beauitful explanation here
On T ue, May 29, 2012 at 1:53 PM, George Leslie <[email protected]>
wrote:
Hi Imran,
Oh, you are getting closer....
The root cause is that "ip pim nbma-mode" only works for sparse-mode groups,
not dense mode (this is what I found out yesterday!)
On which router or routers are you proposing to remove "ip pim autorp
listener"? I assume R2 only?
Interesting idea. If you remove this from R2, then R2 will treat 224.0.1.39
and 224.0.1.40 as sparse mode groups. However, as it does not know the RP for
these groups, it does not know where to send the (*,G) PIm join to join them.
This is the class chicken and egg scenario that caused sparse-dense mode to be
invented.
R5 will still be chucking out traffic for these groups in dense mode, as it
still has autorp configured, so R2 should receive the traffic.
However, as R2 does not know the RP for 224.0.1.39 and 224.0.1.40, how does it
perform the RPF check, if it does not know which is its RPF interface???
I don't know, but I assume, that R2 will reject the traffic due to its
inability to know what it's RPF interface is. if I can, will lab up later today
and confirm this hypothesis....
So, I think there is more to the answer....
And I should state, this was set for me by a CCIE friend of mine. Other lab
conditions:
1. Autorp to be used, not BSR
2. ONLY R8 can be RP via autorp and only R7 as mapping agent for "ALL groups"
i.e including 224.0.1.39 and 224.0.1.40.
3. No static RP assignment permitted.
Regards, George.
Date: Tue, 29 May 2012 08:17:26 +0300
Subject: Re: [OSL | CCIE_RS] Multicast over NBMA Revisted and Retyped and typo
corrected!
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
guys , let me do a quick recap here. i have struggle a lot for this topic ip
pim listner command ====> this makes auto rp groups to be dense mode flooded .
if auto rp grops are dense mode flooded , then pim nbma mode will not work .
as it only works for sparse mode . remove this command and do the test again
....
On Tue, May 29, 2012 at 1:44 AM, Bal Birdy <[email protected]> wrote:
Hey guys. I'm nearly at the end of my studies for the written and one area
I'm very very weak on is frame-relay and NBMA networks. Can anyone point me
in teh right direction for some extra study material on this topic area?
I have the IPE written course, but there's nothing in it for frame-relay -
not of any depth. I guess I need some practice lab stuff to get my head
around it.
Thanks
Bal
On Tue, May 29, 2012 at 6:31 AM, George Leslie <[email protected]
> wrote:
>
>
>
> Hi all,
>
> I have the answer!
> Wow, just when you think you are starting to get comfortable with a
> technology, it turns around and bites you on the bum!! A lesson for us all!
>
>
>
> I’m going to leave this on the forum for a day or so, in
> case anyone else wants to have a crack at solving it.
>
> George.
>
>
> > From: [email protected]
> > To: [email protected]
> > Date: Mon, 28 May 2012 18:53:52 +0000
> > Subject: [OSL | CCIE_RS] Multicast over NBMA Revisted and Retyped and
> typo corrected!
> >
> >
> > Sorry, typo in frame maps below, now corrected. The config I put on the
> real routers were correct however.
> > > From: [email protected]
> > > To: [email protected]
> > > Date: Mon, 28 May 2012 14:44:52 +0000
> > > Subject: [OSL | CCIE_RS] Multicast over NBMA Revisted and Retyped!
> > >
> > >
> > >
> > >
> > >
> > > No idea what happened to the formating of the last Email, so here it
> is again, pasted from Word this time! Hope you can read it!
> > >
> > > Hello all,
> > >
> > >
> > >
> > > Ages ago, I posted a query regarding multicast and pim NBMA
> > > mode on frame. Well, finally today, I
> > > got back to doing another test on proctorlabs kit...and the suggested
> solution
> > > STILL did not work!
> > >
> > >
> > >
> > > Again, this was a homemade lab:
> > >
> > >
> > >
> > > TOPOLOGY
> > >
> > > -------------
> > >
> > >
> > >
> > > classic WB 2 topology of R2/R4/R5 being a frame hub and
> > > spoke, R2 hub. Pim set up on all routers
> > > and auto-rp RP and mapping agent live behing R5.
> > >
> > >
> > >
> > >
> > >
> > > R8 (RP) -> R7 (Mapping agent) -> R5 -> DLC502 ->
> > > R2 -> DLCI 204 -> R4.
> > >
> > >
> > >
> > > All interfaces set to PIM SM. All can see each other as neighbours.
> R2 set to be PIM DR on frame (suggestion from
> > > last time I tried this!). R2 set for pim
> > > NBMA mode on its frame interface.
> > >
> > >
> > >
> > >
> > >
> > > SYMPTOMS
> > >
> > > --------------
> > >
> > >
> > >
> > > R8 can see rp mapping, R7 can see RP mapping, R5 can see RP
> > > mapping, R2 can see RP mapping, R4 cannot.
> > >
> > >
> > >
> > > All these were configured:
> > >
> > >
> > >
> > > OSPF in point-to-multipoint mode on frame and broadcast on
> > > LANs. Full IP connectivity within this
> > > small cloud.
> > >
> > > PIM NBMA mode on R2 frame interface
> > >
> > > R2 PIM DR priority 0f 255, 0 on R4 and R5.
> > >
> > >
> > >
> > > Debug ip mpacket details and debug pim auto (forget exact
> > > syntax but it is the auto-rp debug)
> > >
> > >
> > >
> > > Results:
> > >
> > >
> > >
> > > R4 is not receiving ANY multicast whatsoever. R2 is receiving auto-rp
> info, but is not
> > > sending back out its frame interface again to R4.
> > >
> > >
> > >
> > > My solution was to configure a GRE tunnel from R2 to R4,
> > > move PIM onto that adjust static mroute accordingly. Yes I know,
> could have used PPPoFr but that
> > > was more typing!
> > >
> > >
> > >
> > > However, this to me seems like a frig. I thought the whole point of
> pim NBMA mode is
> > > that is...sort of...acted like "no ip split-horizon" does for
> > > routing, and R2 should advertise the RP and mapping agent
> advertisements back
> > > out its frame interface again. It just
> > > did not do this.....
> > >
> > >
> > >
> > > Is my understanding flawed here, or have a stumbled across
> > > one of those "a reload should fix that" things?
> > >
> > >
> > >
> > >
> > >
> > > Configs below:
> > >
> > >
> > >
> > >
> > >
> > > R2
> > >
> > > --
> > >
> > >
> > >
> > > ip multicast-routing
> > >
> > > ip pim autorp listener
> > >
> > >
> > >
> > > int ser0/1/0
> > >
> > > encap frame
> > >
> > > no frame inverse
> > >
> > > ip address 10.1.1.1 255.255.255.0
> > >
> > > frame map ip 10.1.1.1 204 broad
> > >
> > > frame map ip 10.1.1.4 204
> > >
> > > frame map ip 10.1.1.5 205 broad
> > >
> > > ip ospf net point-to-multipoint
> > >
> > > ip ospf 1 area 0
> > >
> > > ip pim sparse-mode
> > >
> > > ip pim nbma-mode
> > >
> > > ip pim dr-priority 255
> > >
> > >
> > >
> > > R4
> > >
> > > --
> > >
> > >
> > >
> > > ip multicast-routing
> > >
> > > ip pim autorp listener
> > >
> > >
> > >
> > > int ser0/0/0
> > >
> > > encap frame
> > >
> > > no frame inverse
> > >
> > > ip address 10.1.1.4 255.255.255.0
> > >
> > > frame map ip 10.1.1.1 402 broad
> > >
> > > frame map ip 10.1.1.2 402
> > >
> > > frame map ip 10.1.1.5 402
> > >
> > > ip ospf net point-to-multipoint
> > >
> > > ip ospf 1 area 0
> > >
> > > ip pim sparse-mode
> > >
> > > ip pim dr-pri 0
> > >
> > >
> > >
> > > int f0/0
> > >
> > > ip address 10.1.4.4 255.255.255.0
> > >
> > > ip pim sparse-mode
> > >
> > > ip ospf 1 area 0
> > >
> > >
> > >
> > >
> > >
> > > R5
> > >
> > > ---
> > >
> > >
> > >
> > > ip multicast-routing
> > >
> > > ip pim autorp listener
> > >
> > >
> > >
> > > int ser0/1/0
> > >
> > > encap frame
> > >
> > > no frame inverse
> > >
> > > ip address 10.1.1.5 255.255.255.0
> > >
> > > frame map ip 10.1.1.1 502 broad
> > >
> > > frame map ip 10.1.1.4 502
> > >
> > > frame map ip 10.1.1.2 502
> > >
> > > ip ospf net point-to-multipoint
> > >
> > > ip ospf 1 area 0
> > >
> > > ip pim sparse-mode
> > >
> > > ip pim dr-prior 0
> > >
> > >
> > >
> > > int f0/0
> > >
> > > ip address 10.1.5.5 255.255.255.0
> > >
> > > ip ospf 1 area 0
> > >
> > > descr RP and Mapping agent live out here.....
> > >
> > >
> > >
> > >
> > >
> > > Regards, George.
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> 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
_______________________________________________
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
