From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 29 2009 - 13:52:30 ART
Hi,
My understanding of the use of that term (I personally haven't seen it
in common use for many years) would be where you're redistributing a
non-RIP IGP into RIP. The nuance here is that this is redistribution
of RIP into MP-BGP and then redistribution of those same routes/
prefixes back into RIP at another VPN location (this is basically an
SP topic). Whereas when you redistribute, for example, OSPF into RIP,
there is absolutely nothing in OSPF for RIP to derive a metric from.
But when you redistribute any IGP - RIP included - into BGP, the
metric is carried forward automatically via the BGP MED. So when you
redistribute back to the native IGP on the far side of the network,
you do in fact have something that RIP can use to derive a metric (and
you use the 'transparent' keyword to instruct IOS to go ahead and do
that). Having said all that, if you look at the case where I
essentially overrode the MED and manually set the metric at R3:
>>> 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
>>> 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
>>>
>>> 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
Note that R3's BGP "metric" is still derived from the MED, which was
derived from the native RIP metric at R2, yet what is advertised on to
R4 is based upon what I plugged into the 'redistribute' command on
R3. That's essentially-kind-of-sort-of the same thing as a "seed
metric," again as I understand the use of that term, but not not
exactly IMHO.
Or is there something else that you have in mind?
Regards,
Scott
On Mar 29, 2009, at 1:32 , Abdulwahab Jarman wrote:
> 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
>
> _______________________________________________________________________
> 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