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 Blogs and organic groups at http://www.ccie.netReceived on Wed Mar 24 2010 - 08:20:41 ART
This archive was generated by hypermail 2.2.0 : Thu Apr 01 2010 - 07:26:35 ART