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
