Hi Imran,Firstly, I have just verified on proctor labs that the simple removal
of "ip pim autorp listener" from R2 did NOT fix the issue. But, interestly,
not for the reason I had anticipated. I have a large printed out which I will
paste into an Email shortly. However, I'll discuss your comments below. I
agree, one of the side effects of point to multipoint OSPF is the injection of
/32 routes. But why?? Why does it do this? Very simply, the whole idea of
point to multipoint OSPF is that all traffic from spoke to spoke goes through
the hub, INCLUDING traffic from frame addresses on both spokes. The /32 s
ensure that a router always uses an OSPF route to get to any of the hubs/spokes
and not the /24 connected route. This forces all traffic through the hub.
However, once a spoke has determined that to get to the other spoke, it has to
route to the hub, it will use the frame map for the hub, not the spoke. So,
the fact that there is a mapping there for the spoke is completely irrelevent.
Before OSPF was configured, the routers would use the additonal map statement
to test connectivity to each other. After ospf P2MP, they will not, but the
presence of the spoke to spoke map statements has no bearing whatsover on
network operation once OSPF P2MP is configured. As I said, CEF will only use
the spoke to hub mappings. Your second point is partially correct. Using NBMA
mode causes issues. The issue is not a TTL one, but an "wrong ip address" one:
the spoke will receive a PIM join from a different IP address than its PIM
neighbour's address, which it will reject. The scope of the 224.0.1.39 and
224.0.1.40 groups are not necessarily one. They are whatever you configure in
the commands: ip pim send-rp-announce loopback 0 scope <TTL>ip pim
send-rp-discover loopback 0 scope <TTL> commands. In the initial configs, I set
the TTL on these to be higher than the diameter of my test network (I picked
255 but as long as it was bigger than 4 it did not matter). Regards, George.
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
