--------- Forwarded message ---------- From: "El ayachi HADEK" To: "blodwick" , "'Josef A'" , "'Group Study'" Date: Fri, 2 Dec 2005 08:54:08 -0000 Subject: RE: A bgp question I think this is a good idea: in R6 and R5, use BGP Conditional Advertisement with, for example, the "match ip route-source" (=R3's IP address) option of the "non-exist-map". Please, can you test it and let us now. Are you allowed to use floating static routes? -----Message d'origine----- De : nobody@groupstudy.com [mailto:nobody@groupstudy.com]De la part de blodwick Envoyi : Thursday, December 01, 2005 1:53 PM A : 'Josef A'; 'Group Study' Objet : RE: A bgp question What about a conditional advertisement to R3 for the prefix? ~ Brian L -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Josef A Sent: Thursday, December 01, 2005 8:10 AM To: Group Study Subject: Re: A bgp question Thanks guys for looking into this. I probably was not very clear on the restrictions: I want to force R3 to use BB3 as the next-hop for those AS 54 routes it is learning from BB1 via ibgp. I do not want to use weight or local preference, and would still like to use the ibgp routes via R5 should the link to BB3 fails. TIA Josef On 11/30/05, Josef A wrote: > > Hello Guys: > > Here is a question on bgp next-hop modification. > > I have a topology like this: > > > BB3 ------------------ R3 > | > | > R5 > | > | > BB1------------------- R6 > > > BB1 and BB3 are both in AS54. > > R3, R5, and R6 are in AS 100. > > AS 100 is learning some prefixes from AS54. I have initially set the local > preference inbound on R6 so that AS100 will prefer the R6-BB1 link to reach > those prefixes from AS54. > > Thus R3 is now using BB1 as its next-hop for those prefixes. > > My goal now is to override that behavior on R3, and force R3 to make BB3 > the next-hop for those prefixes, without using WEIGHT. I have tried using a > route-map inbound on R3 matching those prefixes and using the set ip > next-hop A.B.C.D or the set ip next-hop peer-address command . But this > is not working. > > What am I missing? > > Your thoughts and/or comments is appreciated > > Josef. --- ---------- Forwarded message ---------- From: "Des" To: Date: Sat, 3 Dec 2005 01:57:13 +0800 Subject: iBGP Hi there, I have the following scenerios. R1(AS100)------R2(non-bgp)-----R3(AS100) I am peering with R3 with ibgp. I can receive all the routes from R1. But however, I cannot ping R1 advertised networks. I need to have a static route at R2 for those network advertised by R1. Is there any way without adding static routes? Tks! Des ---------- Forwarded message ---------- From: Anthony Sequeira To: Des Date: Fri, 2 Dec 2005 13:06:49 -0500 Subject: Re: iBGP Ahh yes - BGP is not running in the transit path of your AS - so it is a BLACK HOLE when it comes to reaching BGP learned prefixes. Perhaps the group will help me list ALL of the possible solutions here....I will get us started: 1. Static routes on R2 2. Run BGP on R2 3. Default route on R2 4. Redistribute the BGP routes into the underlying IGP 5. Tunnel BGP across R2 using GRE 6. ???? 7. ???? ---- --------- Forwarded message ---------- From: "Venkataramanaiah.R" To: Cisco certification Date: Sat, 3 Dec 2005 00:36:49 +0100 Subject: Multicast question.. Hi, I have the following FR topology.. ______R2_____R4 / R1-- \______R3_____R5 (239.5.5.5) I have PIM Sparse mode running everywhere.. and of course with PIM nbma mode at R1. R2 is the RP and R1 is the MA. R5 has joined some group, Say 239.5.5.5(Will call this Grp5 henceforth). There are two issues in this topology. Let me discuss them one by one. 1) When R5 sends PIM join to the RP (R2) via R3, the joins are sent directed to R2 from R3. This prevents the join to become successful. We can fix this by adding a static mroute at R3 for the RP pointing to R1. THis will let the shared tree to be built from the RP R2 via, R1-R3 and the receiver R5. Hope there are no other solutions for this problem. 2) When we ping the Grp5 from R4, the packets would reach the receiver for a while. After sometime, the last hop DR (i.,e R5) tries to switchover to SPT and this breaks the multicast flow in the FR cloud. We can probably fix this by using SPT threshold infinity at R5. Then the traffic would flow smoothly to R5. The main issue that i am unable to address is when we have some group say Grp3 joined at R3 and if we ping this group from R2. In this case, setting spt-threshold infinity at R3, does not seem to help. Since the source is on the same network address in the FR cloud, the ping works for a while through the shared tree via R1, but after sometime, R3 seem to be tearing down the source tree because it thinks the source is directly connected and it stops the mulitcast flow for a while. I am sure you guys would have faced this issue, so I am wondering if there is any solution for this problem.. Thank you -Venkat ---------- Forwarded message ---------- From: Leigh Harrison To: "Venkataramanaiah.R" Date: Sun, 04 Dec 2005 11:46:22 +0000 Subject: Re: Multicast question.. Hey Venkat, This will work with tunnels - I assure you. There must be a problem with either your tunnels or your static mroutes. Make sure that you have put the static mroutes on both sides of the link and do "sh ip mroute" to see if there are active. Also, try using an "mtrace" to see where it's being sent to. Honestly, it does work. LH Venkataramanaiah.R wrote: >i am doing ip unnumbered lo0 on my tunnels, so i think it does not make any >difference then.. > >-V > >On 12/4/05, Godswill Oletu wrote: > > >>Venkat, >> >>I meant mroute to R2/R3's tunnel interface (eg tunnel 0) not lo0, the lo0 >>might still be obeying the IGP path.. >> >>----- Original Message ----- >>*From:* Venkataramanaiah.R >>*To:* Godswill Oletu >>*Cc:* Josef A ; Cisco >> >> >certification > > >>*Sent:* Sunday, December 04, 2005 5:18 AM >>*Subject:* Re: Multicast question.. >> >>Yes mroute points to R2 lo0.. if i add mroute for R2 serial via tunnel, >>the sho ip rpf on R3 does not accept this change, as it considers R2 serial >>as directly connected. >> >>Someone interested can recreate and test it.. May be i am overlooking >>something in my lab.. >> >> >>-Venkat >> >>On 12/4/05, Godswill Oletu wrote: >> >> >>>Even with a static mroute pointing to the tunnel interface as the next >>>hop >>>for R2? >>> >>>----- Original Message ----- >>>From: "Venkataramanaiah.R" >>> >>> >>>To: "Josef A" >>>Cc: "Cisco certification" >>>Sent: Saturday, December 03, 2005 4:38 PM >>>Subject: Re: Multicast question.. >>> >>> >>> >>> >>>>Hi Josef, >>>> >>>> I thought about using the tunnel, however when i tested it, >>>> >>>> >>>the >>> >>> >>>>multicast traffic does not seem to take the tunnel. It still flows >>>> >>>> >>>through >>> >>> >>>>the FR network natively and the situation does not change.. >>>> >>>>-Venkat >>>> >>>>On 12/3/05, Josef A wrote: >>>> >>>> >>>>>Thought of a tunnel between R2 and R3 ? >>>>> >>>>>Josef >>>>> >>>>> >>>>>On 12/2/05, Venkataramanaiah.R < vramanaiah@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>> I have the following FR topology.. >>>>>> >>>>>> >>>>>> ______R2_____R4 >>>>>> / >>>>>>R1-- >>>>>> \______R3_____R5 ( 239.5.5.5) >>>>>> >>>>>> >>>>>> I have PIM Sparse mode running everywhere.. and of course with >>>>>> >>>>>> >>>PIM >>> >>> >>>>>>nbma >>>>>>mode at R1. >>>>>> >>>>>> R2 is the RP and R1 is the MA. R5 has joined some group, Say >>>>>>239.5.5.5 (Will call this Grp5 henceforth). >>>>>> >>>>>> There are two issues in this topology. Let me discuss them one >>>>>> >>>>>> >>>by >>> >>> >>>>>>one. >>>>>> >>>>>>1) When R5 sends PIM join to the RP (R2) via R3, the joins are >>>>>> >>>>>> >>>sent >>> >>> >>>>>>directed >>>>>>to R2 from R3. This prevents the join to become successful. We can >>>>>> >>>>>> >>>fix >>> >>> >>>>>>this >>>>>>by adding a static mroute at R3 for the RP pointing to R1. THis >>>>>> >>>>>> >>>will >>>let >>> >>> >>>>>>the >>>>>>shared tree to be built from the RP R2 via, R1-R3 and the receiver >>>>>> >>>>>> >>>R5. >>> >>> >>>>>>Hope >>>>>>there are no other solutions for this problem. >>>>>> >>>>>>2) When we ping the Grp5 from R4, the packets would reach the >>>>>> >>>>>> >>>receiver >>> >>> >>>>>>for a >>>>>>while. After sometime, the last hop DR (i.,e R5) tries to >>>>>> >>>>>> >>>switchover >>>to >>> >>> >>>>>>SPT >>>>>>and this breaks the multicast flow in the FR cloud. We can >>>>>> >>>>>> >>>probably >>>fix >>> >>> >>>>>>this >>>>>>by using SPT threshold infinity at R5. Then the traffic would flow >>>>>>smoothly >>>>>>to R5. The main issue that i am unable to address is when we have >>>>>> >>>>>> >>>some >>> >>> >>>>>>group >>>>>>say Grp3 joined at R3 and if we ping this group from R2. In this >>>>>> >>>>>> >>>case, >>> >>> >>>>>>setting spt-threshold infinity at R3, does not seem to help. Since >>>>>> >>>>>> >>>the >>> >>> >>>>>>source is on the same network address in the FR cloud, the ping >>>>>> >>>>>> >>>works >>> >>> >>>>>>for a >>>>>>while through the shared tree via R1, but after sometime, R3 seem >>>>>> >>>>>> >>>to >>>be >>> >>> >>>>>>tearing down the source tree because it thinks the source is >>>>>> >>>>>> >>>directly >>> >>> >>>>>>connected and it stops the mulitcast flow for a while. I am sure >>>>>> >>>>>> >>>you >>> >>> >>>>>>guys >>>>>>would have faced this issue, so I am wondering if there is any >>>>>> >>>>>> >>>solution >>> >>> >>>>>>for >>>>>>this problem.. >>>>>> >>>>>>Thank you >>>>>>-Venkat >>>>>> >>>>>> >>>>>> >>>>>> >>>_______________________________________________________________________ >>> >>> >>>>>>Subscription information may be found at: >>>>>>http://www.groupstudy.com/list/CCIELab.html >>>>>> ---