Most correctly, physical media is irrelevant. Well... almost. It's relevant in a sense that OSPF has certain defaults when it comes to the physical media that are used to choose the most appropriate logical network type. The actual OSPF behavior is determined only by the logical type, not by the media type.
Now, here's something more... just for giggles. If you try the exact same configuration on Juniper, it will go to Full and then go down after Dead Interval expires. It will never establish again unless you restart OSPF process. Fun and games, eh? ;-) -- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor - IPexpert On Tue, Jun 5, 2012 at 10:47 AM, HEMANTH RAJ <[email protected]> wrote: > Yeap understood man ... Thanks for the late night abuse. Will sip two beers > and wink my eyes twice to see that again. > > Network Type matters more than physical media. I was under wrong impression > on this ? > > Ur name should be Marko Maltreat Milivojevic :) > > > > On Tue, Jun 5, 2012 at 11:07 PM, Marko Milivojevic <[email protected]> > wrote: >> >> Sure it won't be ACKd, but really.. who cares™ unless unicast is being >> blocked by say... an ACL :-) >> >> Technical abuse is my middle name ;-) >> >> -- >> Marko Milivojevic - CCIE #18427 (SP R&S) >> Senior CCIE Instructor - IPexpert >> >> On Tue, Jun 5, 2012 at 10:35 AM, HEMANTH RAJ <[email protected]> wrote: >> > Hmm the catch here is the " UNICAST" from DR and the other side will >> > Unicast >> > it instead of sending a Multicast packet >> > >> > But the multicast packet will not be Acknowledged that is sent by the >> > Neighbor on the Point to Point side. >> > >> > I will also try to do a wireshark capture and update u >> > >> > Thanks for Technically Abusing me. Nice learning :) lol >> > >> > >> > >> > On Tue, Jun 5, 2012 at 10:57 PM, Marko Milivojevic <[email protected]> >> > wrote: >> >> >> >> Wrong again ;-) >> >> >> >> I would have to re-run all the Wireshark traces to give you 100% >> >> correct answer, but the below one is say 95% correct. >> >> >> >> They will be both. DROther will multicast them, but it will respond in >> >> kind if it receives unicast. DR will always unicast. Assumption here >> >> is that not all neighbors will be interested to hear what DR has to >> >> say, but only the one that is attempting to form an adjacency. While >> >> DROther (or in this case a mismatched p2p) will multicast DBD, when it >> >> receives the unicast descriptor from the DR it will send its own back >> >> as unicast if the previous one went unack'd. >> >> >> >> >> >> -- >> >> Marko Milivojevic - CCIE #18427 (SP R&S) >> >> Senior CCIE Instructor - IPexpert >> >> >> >> On Tue, Jun 5, 2012 at 10:20 AM, HEMANTH RAJ <[email protected]> >> >> wrote: >> >> > hmm yeap sure marko , yes LSU are not multicast correct, but DBDs are >> >> > sent >> >> > on multicast or unicast on ethernet. >> >> > I will try this and let u know th results. >> >> > When i was doing the lab, i found the DBs are not properly >> >> > synchronized. >> >> > I >> >> > thought the DR may be a problem >> >> > Have to buckle up my socks again to see this >> >> > >> >> > hmm LSU's are multicast or unicast depending on the media ( ethernet >> >> > or >> >> > point to point ) >> >> > >> >> > On Tue, Jun 5, 2012 at 10:46 PM, Marko Milivojevic >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> Try it... It's such a common problem we even have it in many of our >> >> >> workbooks. >> >> >> >> >> >> Link state updates are not multicast. >> >> >> >> >> >> -- >> >> >> Marko Milivojevic - CCIE #18427 (SP R&S) >> >> >> Senior CCIE Instructor - IPexpert >> >> >> >> >> >> On Tue, Jun 5, 2012 at 10:10 AM, HEMANTH RAJ <[email protected]> >> >> >> wrote: >> >> >> > Hi Marko , >> >> >> > >> >> >> > hmm i don't see my databases synchronized if i have one side as >> >> >> > BCAST >> >> >> > and >> >> >> > other side as point to point. >> >> >> > how will DR accept on 224.0.0.5 if he thinks others are DRother >> >> >> > how will the DB are synced ? >> >> >> > could u explain me a bit more ? >> >> >> > >> >> >> > >> >> >> > On Tue, Jun 5, 2012 at 9:47 PM, Marko Milivojevic >> >> >> > <[email protected]> >> >> >> > wrote: >> >> >> >> >> >> >> >> On Tue, Jun 5, 2012 at 9:10 AM, Venkee <[email protected]> >> >> >> >> wrote: >> >> >> >> > In this case, from one end (BCAST), would see the type-2 lsa in >> >> >> >> > database >> >> >> >> > but >> >> >> >> > not on router where we have p-t-p, he might have said this >> >> >> >> >> >> >> >> That is correct. However, if you look at the adjacency between >> >> >> >> the >> >> >> >> two >> >> >> >> routers, it would appear as perfectly valid and the databases >> >> >> >> will >> >> >> >> be >> >> >> >> in sync. >> >> >> >> >> >> >> >> Another difference you will see in the database is the type of >> >> >> >> link >> >> >> >> in >> >> >> >> Type-1 LSA that will be Point-to-point/Stub on the p2p side and >> >> >> >> Transit on the broadcast side. This discrepancy is the one >> >> >> >> routers >> >> >> >> will use to identify the problem and cause them not to "trust" >> >> >> >> each >> >> >> >> other. >> >> >> >> >> >> >> >> -- >> >> >> >> Marko Milivojevic - CCIE #18427 (SP R&S) >> >> >> >> Senior CCIE Instructor - IPexpert >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Problems arise because we talk,problems are not solved because we >> >> >> > don't >> >> >> > talk >> >> >> > So good or bad talk to your affectionate one's freely. >> >> >> > >> >> >> > Yours Friendly, >> >> >> > H P HEMANTH RAJ >> >> >> > CCIE#28593 (R&S) >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Problems arise because we talk,problems are not solved because we >> >> > don't >> >> > talk >> >> > So good or bad talk to your affectionate one's freely. >> >> > >> >> > Yours Friendly, >> >> > H P HEMANTH RAJ >> >> > CCIE#28593 (R&S) >> >> > >> >> > >> > >> > >> > >> > >> > -- >> > Problems arise because we talk,problems are not solved because we don't >> > talk >> > So good or bad talk to your affectionate one's freely. >> > >> > Yours Friendly, >> > H P HEMANTH RAJ >> > CCIE#28593 (R&S) >> > >> > > > > > > -- > Problems arise because we talk,problems are not solved because we don't talk > So good or bad talk to your affectionate one's freely. > > Yours Friendly, > H P HEMANTH RAJ > CCIE#28593 (R&S) > > _______________________________________________ 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
