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

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
Blogs and organic groups at http://www.ccie.net