Re: BGP MED is not removed before advertising to external AS

Resetting MED to 0 manually will sure fix my problem. But I want to be sure
that what I see is not a design or config issue.
Thanks anyway for your suggestion.

On Thu, Mar 25, 2010 at 9:30 AM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:

> I thought debug ip bgp update would show it,but perhaps not. It might be a
> good idea to set MED to 0 inbound on R1 just to clear it.
>
>
> On Wed, Mar 24, 2010 at 4:27 PM, Tech Guy <autechguy_at_gmail.com> wrote:
>
>> Hi Bryan,
>>
>> Thanks for your input. We have two BGP peering with downstream
>> (customer's) AS. One is working fine, as expected (without MED being
>> propogated), one with problem. This causes us a problem, as traffic from
>> customer to our AS prefer to go via the peer with MED= 0.
>>
>> Even without checking other peers, we can easily see where you get MED
>> from by "show ip bgp x.x.x.x" on customer problematic router (R1), you can
>> see exactly where MED is learnt from. In this case via eBGP from R2, and not
>> from other peer (via iBGP).
>>
>> BTW, on R2 is there anyway (show or debug) to confirm that MED is reset to
>> 0 before the prefixes are advertised to R1?
>>
>>
>> Here's the production router versions
>>
>> R2#show version
>> Cisco IOS Software, 7200 Software (C7200-P-M), Version 12.4(19a), RELEASE
>> SOFTWARE (fc1)
>> System image file is "disk2:c7200-p-mz.124-19a.bin"
>> Cisco 7204VXR (NPE-G1) processor (revision C) with 983040K/65536K bytes of
>> memory.
>>
>> R1#show version
>> Cisco IOS Software, 7301 Software (C7301-IK9S-M), Version 12.4(7), RELEASE
>> SOFTWARE (fc6)
>> System image file is "disk0:c7301-ik9s-mz.124-7.bin"
>> Cisco 7301 (NPE) processor (revision E) with 983040K/65536K bytes of
>> memory.
>>
>> On Thu, Mar 25, 2010 at 1:20 AM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>
>>> Hello,
>>>
>>> R1 should not see the MED if the configuration is as you explained. Have
>>> you checked configurations on all routers to make sure that it's not getting
>>> set some other way? Btw, what model router/IOS?
>>>
>>> On Wed, Mar 24, 2010 at 6:40 AM, Tech Guy <autechguy_at_gmail.com> wrote:
>>>
>>>> Hi GS,
>>>>
>>>> I am experiencing an weird scenario in our production network where the
>>>> MED
>>>> is carried on to the our customer AS in an unexpected way.
>>>>
>>>>
>>>> (Customer) My ISP (upstream ISP)
>>>> R1 --------- R2 --------- R3
>>>> (AS1) (AS2) (AS3)
>>>>
>>>>
>>>> On a peer with upstream (R3), we use an inbound route-map to set MED of
>>>> 200,
>>>> so that we can influence the outgoing traffic routing policy, as we have
>>>> a
>>>> number of peers with our upstream ISP. Please note that this is
>>>> different
>>>> from a typical MED use, where you set MED on an outbound route-map to
>>>> influence incomming traffic from your peer.
>>>>
>>>> For some reason, that MED I set is carried on to the downstream AS
>>>> (customer, R1), even though that we do not set it on the peering to R1.
>>>> I
>>>> suspect that this is a bug (on R2), as I can not reproduce the same
>>>> behaviour on my lab router (different model, and different IOS).
>>>>
>>>> Has anyone experienced the same problem before?
>>>>
>>>> Another question, how I can be sure (what show, debug commands to use)
>>>> that
>>>> MED is reset before R2 sends the update to R1, apart from going to R1
>>>> and
>>>> check the attributes for the route myself?
>>>>
>>>> In the lab, on R2 the MED is set to 200 when 3.3.3.3/32 is received
>>>> from R3.
>>>> On R1, I do not see that MED of 200, that means R2 must reset it to 0
>>>> before
>>>> it advertises to R1. However, in the debug ip bgp update output, I do
>>>> not
>>>> see that R2 sends it with MED of 0. That's strange.
>>>>
>>>> Your clarification is appreciated.
>>>>
>>>> TGuy
>>>>
>>>>
>>>> R2#
>>>> *Mar 1 00:54:43.859: BGP(0): 23.0.0.3 rcvd UPDATE w/ attr: nexthop
>>>> 23.0.0.3, origin i, metric 0, path 3
>>>> *Mar 1 00:54:43.863: BGP(0): 23.0.0.3 rcvd 3.3.3.3/32
>>>> *Mar 1 00:54:43.867: BGP(0): Revise route installing 1 of 1 routes for
>>>> 3.3.3.3/32 -> 23.0.0.3(main) to main IP table
>>>>
>>>> *Mar 1 00:54:43.871: BGP(0): 12.0.0.1 send UPDATE (format) 3.3.3.3/32,
>>>> next
>>>> 12.0.0.2, ***metric 200***, path 3
>>>> *Mar 1 00:54:43.971: BGP(0): updgrp 1 - 12.0.0.1 updates replicated for
>>>> neighbors: 23.0.0.3
>>>>
>>>>
>>>> R2#show ip bgp
>>>> BGP table version is 9, local router ID is 23.0.0.2
>>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>>> internal,
>>>> r RIB-failure, S Stale
>>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>> Network Next Hop Metric LocPrf Weight Path
>>>> *> 3.3.3.3/32 23.0.0.3 200 0 3 i
>>>>
>>>>
>>>>
>>>> R1#
>>>> *Mar 1 00:54:44.227: BGP(0): 12.0.0.2 rcvd UPDATE w/ attr: nexthop
>>>> 12.0.0.2, origin i, path 2 3
>>>> *Mar 1 00:54:44.231: BGP(0): 12.0.0.2 rcvd 3.3.3.3/32
>>>> *Mar 1 00:54:44.235: BGP(0): Revise route installing 1 of 1 routes for
>>>> 3.3.3.3/32 -> 12.0.0.2(main) to main IP table
>>>>
>>>>
>>>>
>>>> R1#show ip bgp
>>>> BGP table version is 8, local router ID is 12.0.0.1
>>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>>> internal,
>>>> r RIB-failure, S Stale
>>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>> Network Next Hop Metric LocPrf Weight Path
>>>> *> 3.3.3.3/32 12.0.0.2 0 2 3 i
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Bryan Bartik
>>> CCIE #23707 (R&S, SP), CCNP
>>> Sr. Support Engineer - IPexpert, Inc.
>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>>
>>
>>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S, SP), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com <http://www.ipexpert.com/>

Blogs and organic groups at http://www.ccie.net
Received on Thu Mar 25 2010 - 10:18:25 ART