Re: MSDP CACHING PEER VS RPF PEER

no explicit command to identify how to identify a cached peer .

As probably the cached peer is in other autnomous system you can get this
info by other channel .

 This does not apply to ccie lab as you will be the one confiugring on both
authono mous systems

Or

when you send an SA requst to a NON caching peer it send an error
notification back to you . so you can try sending SA request messages one
by one basis to each MSDP PEER untill you get atleast one .

The above points are not revelent these days .

*In all current and supported Cisco IOS software releases, caching of MSDP
SA messages is mandatory and cannot be manually enabled or disabled. By
default, when an MSDP peer is configured, the ip multicast cache-sa-state
command will automatically be added to the running configuration. Prior to
Cisco IOS Releases 12.1(7) and 12.0(14)S1, caching of SAs was disabled by
default and could be enabled with the ip msdp cache-sa-state command.*

On Sun, Dec 25, 2011 at 6:16 PM, CCIE KID <eliteccie_at_gmail.com> wrote:

> Cool man got ur point.
>
> So there are three types of messages for MSDP
>
> 1. Source Active Messages (SA Messages)
> 2. SA request
> 3. SA response.
>
> SA messages are transmitted by every peer in the MSDP mesh to each and
> every other peer in the mesh evry 60 seconds to inform the available
> sources and their multicast group they r sending traffic
>
> SA request is sent by peer who are not caching any SA messages sent by the
> peer.
>
> SA response is sent by a caching peer who has cached all the messages
> sent by a peer in the MSDP mesh.
>
> Correct me if i am wrong
>
> Now my question ,how does a peer knows that which peer has CACHED all the
> information from any other peer ?
>
> How to identify a Cached peer ?
>
>
> On Sun, Dec 25, 2011 at 8:26 PM, Imran Ali <immrccie_at_gmail.com> wrote:
>
>> *look at this way *
>> **
>> **
>> *SA messages are sent every 60 seconds *
>> **
>> *if i dont have any active member in a perticular group say 225.1.1.1
>> and i recieved an SA for it , i will forward it to my peers and drop it .
>> *
>> **
>> *by default i will not cache " that SA " . What happent when CEO of my
>> company wants that feed ??? *
>> **
>> *will he wait for next 60 seconds ? so in order to reduce the join
>> latency i will have one peer who is caching the info regardless if he has
>> members in that group or not ..*
>> **
>> **
>> *so that peer from whom i am requstiing SA for group 225.1.1.1 is
>> caching peer *
>> **
>> *obviously it is one of my MSDP peers but may not be on best path back
>> to source , that is ok, as RFP is only performed ON SA messages and not SA
>> REQUEST OR RESPONSE . *
>> **
>> *but you may ask why i m myself not caching the info ?? why requsting
>> others , it is because of memory stress
>> *
>> On Sun, Dec 25, 2011 at 5:47 PM, CCIE KID <eliteccie_at_gmail.com> wrote:
>>
>>> Ok i got ur point dude, Here only the RP caches the multicast info from
>>> other RP peers.
>>> So if it caches the info from other RP neighbors, it will immediately
>>> joins to that source when it has receivers for that particular group.
>>>
>>> So when a RP doesnt cache the message , and it receives a client for a
>>> particular multicast group, that particular RP will trigger will a SA
>>> request message towards their MSDP peers ( ie towards other RP's ) and if
>>> there is any other RP in the MSDP mesh has the source info , it will
>>> trigger a SA response message towards the Requested RP .
>>>
>>> If it doesnt have any Source info, it will trigger an error message.
>>>
>>> Am i correct dude ?
>>>
>>>
>>>
>>> On Sun, Dec 25, 2011 at 6:19 PM, Imran Ali <immrccie_at_gmail.com> wrote:
>>>
>>>> this will make you grasp easier
>>>>
>>>>
>>>>
>>>> The originating RP continues to send periodic SAs for the (S, G) every
>>>> 60 seconds for as long as the
>>>>
>>>> source is sending packets to the group. When an RP receives an SA, it
>>>> has the option to cache the
>>>>
>>>> message. Suppose, for example, that an RP receives an SA for
>>>> (172.16.5.4, 228.1.2.3) from
>>>>
>>>> originating RP 10.5.4.3. The RP consults its mroute table and finds
>>>> that there are no active members
>>>>
>>>> for group 228.1.2.3, so it passes the SA message to its peers
>>>> downstream of 10.5.4.3 without
>>>>
>>>> caching the message. If a host in the domain then sends a join to the
>>>> RP for group 228.1.2.3, the RP
>>>>
>>>> adds the interface toward the host to the outgoing interface list of
>>>> its (*, 224.1.2.3) entry. Because
>>>>
>>>> the previous SA was not cached, however, the RP has no knowledge of the
>>>> source. Therefore, the RP
>>>>
>>>> must wait until the next SA message is received before it can initiate
>>>> a join to the source.
>>>>
>>>> If, on the other hand, the RP is caching SAs, the router will have an
>>>> entry for (172.16.5.4, 228.1.2.3)
>>>>
>>>> and can join the source tree as soon as a host requests a join. The
>>>> trade-off here is that in exchange
>>>>
>>>> for reducing the join latency, memory is consumed caching SA messages
>>>> that may or may not be
>>>>
>>>> needed. If the RP belongs to a very large MSDP mesh, and there are
>>>> large numbers of SAs, the
>>>>
>>>> memory consumption can be significant.
>>>>
>>>> By default, Cisco IOS Software does not cache SAs. You can enable
>>>> caching with the command
>>>>
>>>> *ip*
>>>> *
>>>>
>>>> msdp cache-sa-state.
>>>> *
>>>>
>>>> To help alleviate possible memory stress, you can link the command to an
>>>>
>>>> extended access list that specifies what (S, G) pairs to cache.
>>>>
>>>> If an RP has an MSDP peer that is caching SAs, you can reduce the join
>>>> latency at the RP without
>>>>
>>>> turning on caching by using
>>>>
>>>> *SA Request *and *SA Response *messages. When a host requests a join to
>>>>
>>>> a particular group, the RP sends an SA Request message to its caching
>>>> peer(s). If a peer has cached
>>>>
>>>> source information for the group in question, it sends the information
>>>> to the requesting RP with an SA
>>>>
>>>> Response message. The requesting RP uses the information in the SA
>>>> Response but does not forward
>>>>
>>>> the message to any other peers. If a noncaching RP receives an SA
>>>> Request, it sends an error
>>>>
>>>> message back to the requestor.
>>>>
>>>>
>>>> On Sun, Dec 25, 2011 at 3:38 PM, CCIE KID <eliteccie_at_gmail.com> wrote:
>>>>
>>>>> Imran i read it man . I am not getting the exact concept.
>>>>>
>>>>> Wat is exactly called as Caching SA?
>>>>>
>>>>> Wat r different types of Source Active messages.
>>>>>
>>>>> SA response, SA reply....
>>>>>
>>>>> Can u explain me the process of Caching SA, peer RPF neighbor, peer
>>>>> RPF flooding..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Dec 24, 2011 at 10:38 AM, Imran Ali <immrccie_at_gmail.com>wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Caching SA responces are different then original SA advirtisments
>>>>>>
>>>>>> while former do not get subjected to RPF , the later does . And if
>>>>>> received from non rpf neighbor those SA's gets discarded.
>>>>>>
>>>>>>
>>>>>> Read vol 2 tcp ip for acutal concepts of caching sa , peer RPF
>>>>>> neighbor , peer RPF FLOODING etc . and peter's above response add cerry to
>>>>>> it
>>>>>> On Sat, Dec 24, 2011 at 5:32 AM, CCIE KID <eliteccie_at_gmail.com>wrote:
>>>>>>
>>>>>>> Hi Imran,
>>>>>>>
>>>>>>> I didnt understnad ur question properly . Can u rephrase it man.
>>>>>>> From what Petr explained, yes if u form a TCP connection between two
>>>>>>> RP's from two different AS, u just emit the information of source for this
>>>>>>> particular multicast group.
>>>>>>> Multicast Source Discovery protocol ( MSDP) emits the information of
>>>>>>> source to synchronise the information about Source to RP's present in
>>>>>>> different AS other than his own.
>>>>>>> So basically there is no RPF check for MSDP SA messages, it justs
>>>>>>> transmits the info about the source, so there will no multicast info
>>>>>>> piggbacked into multicast packet as Petr mentioned
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 24, 2011 at 12:02 AM, Petr Lapukhov <
>>>>>>> petr_at_internetworkexpert.com> wrote:
>>>>>>>
>>>>>>>> Right, directly connected in this context means "having direct MSDP
>>>>>>>> peering session"
>>>>>>>>
>>>>>>>> 2011/12/23 Imran Ali <immrccie_at_gmail.com>:
>>>>>>>> > *THANKS for great info .*
>>>>>>>> >
>>>>>>>> > but how can you say msdp peer directly connected ? .
>>>>>>>> >
>>>>>>>> > IN my senario RP's are centrally located in each PIM SM domain ,
>>>>>>>> and are
>>>>>>>> > physically not directly connected .
>>>>>>>> >
>>>>>>>> > are you referring to logical tcp connection on port 639 ?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Fri, Dec 23, 2011 at 8:41 PM, Petr Lapukhov
>>>>>>>> > <petr_at_internetworkexpert.com>wrote:
>>>>>>>> >
>>>>>>>> >> I belive your question is "whether the SA messages in SA
>>>>>>>> Response are
>>>>>>>> >> subject to peer-RPF checks" and "whether the caching peer must
>>>>>>>> be on
>>>>>>>> >> RPF path toward the originating RP". The answer is no to both
>>>>>>>> >> questions, and there are two reasons:
>>>>>>>> >>
>>>>>>>> >> 1) MSDP SA request/response messages are not relayed, they are
>>>>>>>> >> exchanged on pure p2p basis between two directly connected MSDP
>>>>>>>> >> speakers (peers). Therefore, there is no need for RPF check for
>>>>>>>> >> request message - it could be sent to any caching peer.
>>>>>>>> Futhermore,
>>>>>>>> >> the requesting RP does not know the originating RP address prior
>>>>>>>> to
>>>>>>>> >> requesting group state. There is even no field in SA Request
>>>>>>>> message
>>>>>>>> >> to encode this information :) So even if you want, you can't do
>>>>>>>> an RPF
>>>>>>>> >> check - only request the cached state for a group.
>>>>>>>> >>
>>>>>>>> >> 2) MSDP SA response messages do not carry any piggy-backed
>>>>>>>> multicast
>>>>>>>> >> data, unlike the SA message, so there is no need to relay that
>>>>>>>> >> information either, and hence no need to RPF check the SA
>>>>>>>> Response
>>>>>>>> >> message.
>>>>>>>> >>
>>>>>>>> >> It is interesting to notice, that details on SA Request message
>>>>>>>> >> exchange did not make it to MSDP RFC, though you can find them
>>>>>>>> in the
>>>>>>>> >> draft documents. The final RFC only specifies the TLV codes for
>>>>>>>> >> request/response messages.
>>>>>>>> >>
>>>>>>>> >> --
>>>>>>>> >> Petr Lapukhov, petr_at_INE.com
>>>>>>>> >> CCIE #16379 (R&S/Security/SP/Voice)
>>>>>>>> >> CCDE #20100007
>>>>>>>> >>
>>>>>>>> >> Internetwork Expert, Inc.
>>>>>>>> >> http://www.INE.com
>>>>>>>> >> Toll Free: 877-224-8987
>>>>>>>> >> Outside US: 775-826-4344
>>>>>>>> >>
>>>>>>>> >> 2011/12/23 Imran Ali <immrccie_at_gmail.com>:
>>>>>>>> >> > hI
>>>>>>>> >> >
>>>>>>>> >> > Does the caching RP in MSDP must be a peer RPF neighbor to the
>>>>>>>> RP sending
>>>>>>>> >> > SA request messages ?
>>>>>>>> >> >
>>>>>>>> >> > can a non rpf peer in msdp act like a caching RP ??
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> > Blogs and organic groups at http://www.ccie.net
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> _______________________________________________________________________
>>>>>>>> >> > Subscription information may be found at:
>>>>>>>> >> > http://www.groupstudy.com/list/CCIELab.html
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Blogs and organic groups at http://www.ccie.net
>>>>>>>> >
>>>>>>>> >
>>>>>>>> _______________________________________________________________________
>>>>>>>> > Subscription information may be found at:
>>>>>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Petr Lapukhov, petr_at_INE.com
>>>>>>>> CCIE #16379 (R&S/Security/SP/Voice)
>>>>>>>> CCDE #20100007
>>>>>>>>
>>>>>>>> Internetwork Expert, Inc.
>>>>>>>> http://www.INE.com
>>>>>>>> Toll Free: 877-224-8987
>>>>>>>> Outside US: 775-826-4344
>>>>>>>>
>>>>>>>>
>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________________________________
>>>>>>>> Subscription information may be found at:
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> With Warmest Regards,
>>>>>>>
>>>>>>> CCIE KID
>>>>>>> CCIE#29992 (Security)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> With Warmest Regards,
>>>>>
>>>>> CCIE KID
>>>>> CCIE#29992 (Security)
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> With Warmest Regards,
>>>
>>> CCIE KID
>>> CCIE#29992 (Security)
>>>
>>>
>>>
>>
>
>
> --
> With Warmest Regards,
>
> CCIE KID
> CCIE#29992 (Security)

Blogs and organic groups at http://www.ccie.net
Received on Sun Dec 25 2011 - 19:33:54 ART