[Xorp-hackers] BGP MED attributes

Mark Handley M.Handley at cs.ucl.ac.uk
Fri May 23 10:48:54 PDT 2008


Stefan,

I've looked at the code, and the relevant line is in bgp/plumbing.cc:

    /* 3. Configure MED filter.
          Remove old MED and add new one on transmission to EBGP
peers. */
    /* Note: this MUST come before the nexthop rewriter */
    filter_out->add_med_removal_filter();
    if (peer_type == PEER_TYPE_EBGP) {
        filter_out->add_med_insertion_filter();
    }

So we add a MED removal filter, and then add a MED insertion filter if
the peering is EBGP.  I think this is probably a bug - unconditionally
removing MED on IBGP peerings is not what is required.  It is required
that it can be removed, but not that it must always be removed.
Simply moving the line add_med_removal_filter() line inside the if
statement will probably have the desired behaviour.

I'm about to go away on vacation, so I won't get a chance to make this
change in CVS and run the regression tests before leaving.  Can you
file a bugzilla bug report on this please, so we don't lose track of
it.

Thanks,
Mark

On Fri, May 23, 2008 at 6:16 PM, Štefan Gula <steweg at ynet.sk> wrote:
> Hi,
>
> In current implementation I believe that it is not possible to send
> MED attribute to IBGP neighbors for routes learned from EBGP
> neighbors. For example:
> We have got 3 routers: R1, R2, R3
> R1 is in AS 100
> R2 and R3 are in AS 200
> they are connected through links L1, L2, L3 like this:
> L1: R1 <->R2
> L2: R2 <->R3
> L3: R3 <->R1
>
> Now want I want to achieve is set MED attribute for routes in AS100 on
> R1 for link L1 to 100 and for link L2 to 200. This can be accomplished
> without problems. The problem is that routers R2 and R3 doesn't send
> MED attribute in their updates about the routes learned from R1.
> According to RFC 1771 MED is optional non-transitive and "If received
> over external links, the MULTI_EXIT_DISC attribute may be propagated
> over internal links to other BGP speakers within the same AS". So why
> not enable to sending this attribute to other IBGP neighbors?
>
> There is also one other limitation about NEXT_HOP attribute. In
> current implementation every router changes NEXT_HOP attribute to
> itself (or the IP set in configuration). Sometimes this behaviour is
> not required and I would like to see the option to disable this
> behavior.
>
> Best regards.
>
> --
> Stefan Gula, CCNP
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>



More information about the Xorp-hackers mailing list