From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Thu Mar 26 2009 - 04:44:24 ART
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 <-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
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:07 ART