Ahh no no... I wouldn't go as far as calling it that. Especially not when it comes to OSPF ;-). I even have proof in all its bloggy form ;-)
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor - IPexpert On Thu, Jun 7, 2012 at 1:15 PM, Elie Raad <[email protected]> wrote: > Hello Marko, > > Thanks for your reply concering my question. :) again juniper is "smarter > than IOS . ;). > the qestion came up while going over Vol 2 Lab16. > > > > Best Regards, > > Elie Raad > ________________________________________ > From: [email protected] > [[email protected]] on behalf of Marko Milivojevic > [[email protected]] > Sent: Tuesday, June 05, 2012 9:03 PM > To: HEMANTH RAJ > Cc: [email protected] > Subject: Re: [OSL | CCIE_RS] OSPF Question > > 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 _______________________________________________ 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
