From: Abdulwahab Jarman (aj203465@gmail.com)
Date: Sun Mar 29 2009 - 04:32:19 ART
What about using (seed metric) here?
>
>
>
> On Thu, Mar 26, 2009 at 10:44 AM, Scott M Vermillion <
> scott_ccie_list@it-ag.com> wrote:
>
>> Thanks much Narbik - I clearly didn't read carefully enough before posting
>> my response.
>>
>> CCIESP,
>>
>> As I'm sure you already know (but just for the sake of discussion), from
>> RIP->BGP, the RIP (or any IGP) metric will automatically carry forward to
>> the BGP MED PA/metric. You can then either choose to carry that forward
>> (plus 1) on the way back out of BGP on the other end via 'transparent', or
>> you can just hard-code it to some arbitrary value on the way out. I suppose
>> at the end of the day, depending on what you were trying to accomplish or
>> how your task language was put together, you'd want the option to either do
>> a metric manipulation inbound into BGP, outbound from BGP, or some
>> combination thereof. Threw together a quick scenario and posted some
>> results below.
>>
>> Regards,
>>
>> Scott
>>
>>
>>
>> (150.1.1.1/24)-R1 <http://150.1.1.1/24%29-R1> <-RIPv2-> R2 (AS1) <-eBGP->
>> (AS2) R3 <-RIPv2-> R4
>>
>> R1 advertises 150.1.1.0/24 into RIPv2, R2 redistributes same from RIPv2
>> into eBGP, and then R3 redistributes eBGP back into RIPv2. Just to keep
>> thing clear (well, that was the intent, anyway), R1 is advertising
>> 150.1.1.0/24 to R2 with a metric of 8. We first look at no metric
>> specified going inbound to BGP and a transparent metric coming out:
>>
>> Rack1R2#sh run | beg router bgp
>> router bgp 1
>> no synchronization
>> bgp log-neighbor-changes
>> redistribute rip
>> neighbor 10.0.23.3 remote-as 2
>> no auto-summary
>>
>> Rack1R3#sh run | sec rip
>> router rip
>> version 2
>> redistribute bgp 2 metric transparent route-map BGP_2_RIP
>> network 10.0.0.0
>> no auto-summary
>>
>> The view from R3:
>>
>> Rack1R3#sh ip route bgp
>> 150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
>> B 150.1.1.0/24 [20/8] via 10.0.23.2, 00:00:45
>>
>> The view from R4:
>>
>> Rack1R4#sh ip route rip
>> 150.1.0.0/24 is subnetted, 1 subnets
>> R 150.1.1.0 [120/9] via 10.0.34.3, 00:00:07, FastEthernet0/1
>>
>>
>> No surprises there but that's our baseline. OK, so now we manipulate
>> metric going into BGP on R2 and we keep the transparent option on R3:
>>
>> Rack1R2#sh run | beg router bgp
>> router bgp 1
>> no synchronization
>> bgp log-neighbor-changes
>> redistribute rip metric 4
>> neighbor 10.0.23.3 remote-as 2
>> no auto-summary
>>
>> Rack1R3#sh run | sec rip
>> router rip
>> version 2
>> redistribute bgp 2 metric transparent route-map BGP_2_RIP
>> network 10.0.0.0
>> no auto-summary
>>
>> The view from R3:
>>
>> Rack1R3#sh ip route bgp
>> 150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
>> B 150.1.1.0/24 [20/4] via 10.0.23.2, 00:04:09
>>
>> The view from R4:
>>
>> Rack1R4#sh ip route rip
>> 150.1.0.0/24 is subnetted, 1 subnets
>> R 150.1.1.0 [120/5] via 10.0.34.3, 00:00:27, FastEthernet0/1
>>
>>
>> Finally, we back out the metric manipulation going into BGP on R2 and we
>> just hard-code metric coming out of R3:
>>
>> Rack1R2#sh run | beg router bgp
>> router bgp 1
>> no synchronization
>> bgp log-neighbor-changes
>> redistribute rip
>> neighbor 10.0.23.3 remote-as 2
>> no auto-summary
>>
>> Rack1R3#sh run | sec rip
>> router rip
>> version 2
>> redistribute bgp 2 metric 5 route-map BGP_2_RIP
>> network 10.0.0.0
>> no auto-summary
>>
>> The view from R3:
>>
>> Rack1R3#sh ip route bgp
>> 150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
>> B 150.1.1.0/24 [20/8] via 10.0.23.2, 00:01:42
>>
>> The view from R4:
>>
>> Rack1R4#sh ip route rip
>> 150.1.0.0/24 is subnetted, 1 subnets
>> R 150.1.1.0 [120/5] via 10.0.34.3, 00:00:18, FastEthernet0/1
>>
>> If it wasn't so late and I wasn't so tired, the thing to do would have
>> been to have added a second site redistributing RIP into BGP. That would
>> have demonstrated the case where circumstances/task language required that
>> we do transparent outbound from BGP but that one of the two sites doing
>> redistribution into BGP had too high a hop-count for the route to properly
>> propagate. That would show one corner case where manipulating metric at the
>> inbound point of redistribution would actually be mandatory. Oh, what the
>> hell...
>>
>> So this just adds R5 in AS3 peering eBGP w/ R3. It is redistributing in
>> 150.1.6.0/24, which has a hop-count of 15 at R5. We are required, for
>> whatever reason, to implement the transparent option at R3, so one option
>> available to us to ensure that 150.1.6.0/24 reaches R4 is to drop the
>> metric at R5 instead of at R3.
>>
>> The problem:
>>
>> Rack1R5#sh run | sec bgp
>> router bgp 3
>> no synchronization
>> bgp log-neighbor-changes
>> redistribute rip
>> neighbor 10.0.35.3 remote-as 2
>> no auto-summary
>>
>> Rack1R3#sh run | sec rip
>> router rip
>> version 2
>> redistribute bgp 2 metric transparent route-map BGP_2_RIP
>> network 10.0.0.0
>> no auto-summary
>>
>>
>> Rack1R5#sh ip route rip
>> 150.1.0.0/24 is subnetted, 2 subnets
>> R 150.1.6.0 [120/15] via 10.0.56.6, 00:00:18, FastEthernet0/1
>>
>> Rack1R3#sh ip route bgp
>> 150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
>> B 150.1.6.0/24 [20/15] via 10.0.35.5, 00:00:10
>> B 150.1.1.0/24 [20/8] via 10.0.23.2, 00:54:19
>>
>> Rack1R4#sh ip route rip
>> 150.1.0.0/24 is subnetted, 1 subnets
>> R 150.1.1.0 [120/9] via 10.0.34.3, 00:00:12, FastEthernet0/1
>>
>>
>> The solution:
>>
>> Rack1R5#sh run | sec bgp
>> router bgp 3
>> no synchronization
>> bgp log-neighbor-changes
>> redistribute rip metric 1
>> neighbor 10.0.35.3 remote-as 2
>> no auto-summary
>>
>> Rack1R3#sh run | sec rip
>> router rip
>> version 2
>> redistribute bgp 2 metric transparent route-map BGP_2_RIP
>> network 10.0.0.0
>> no auto-summary
>>
>> Rack1R5#sh ip route rip
>> 150.1.0.0/24 is subnetted, 2 subnets
>> R 150.1.6.0 [120/15] via 10.0.56.6, 00:00:23, FastEthernet0/1
>>
>> Rack1R3#sh ip route bgp
>> 150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
>> B 150.1.6.0/24 [20/1] via 10.0.35.5, 00:00:13
>> B 150.1.1.0/24 [20/8] via 10.0.23.2, 00:59:36
>>
>> Rack1R4#sh ip route rip
>> 150.1.0.0/24 is subnetted, 2 subnets
>> R 150.1.6.0 [120/2] via 10.0.34.3, 00:00:11, FastEthernet0/1
>> R 150.1.1.0 [120/9] via 10.0.34.3, 00:00:19, FastEthernet0/1
>>
>>
>>
>>
>>
>> On Mar 25, 2009, at 8:35 , Narbik Kocharians wrote:
>>
>> Yes you should consider the transparent option, its NOT when you
>>> redistribute the RIP routes into BGP, its when you redistribute them back
>>> to
>>> RIp on the other end.
>>>
>>> On Wed, Mar 25, 2009 at 1:10 PM, Scott M Vermillion <
>>> scott_ccie_list@it-ag.com> wrote:
>>>
>>> Thus far I have personally been going with the 'transparent' metric
>>>> option.
>>>> Obviously you want to look to ensure that doesn't result in anything
>>>> being
>>>> advertised as unreachable.
>>>>
>>>> Mind you, I haven't been to the SP lab and I haven't gotten terribly far
>>>> into my preparations for it, so I may yet find some reason to change my
>>>> approach. FWIW...
>>>>
>>>>
>>>> On Mar 25, 2009, at 10:31 , CCIESP wrote:
>>>>
>>>> Hi All
>>>>
>>>>>
>>>>> When redistributing RIP into BGP VRF address family for example is it
>>>>> best practice to specify a metric ? I have always just done the redist
>>>>> rip command but i am now wondering if it isnt better to add a metric
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Narbik Kocharians
>>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>> www.MicronicsTraining.com
>>> www.Net-Workbooks.com
>>> Sr. Technical Instructor
>>>
>>>
>>> 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
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:08 ART