Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

Bronze

Med attribute bgp

Hi everybody.

Please consider the following example:

     AS1                                 AS2

R1--199.199.199.0----R2----200.200.200.0----R3

In the above fig, R1 and R2 are in AS 1 and R3 is in AS2.

R1 is advertising its loopback address 10.10.10.10/8 to R2 via ibgp.

Below is the  path atributes of prefix 10.0.0.0 advertised by R1(1.1.1.1) to R2 (2.2.2.2) via ibgp.

No.     Time        Source                Destination           Protocol Info

     75 435.902000  1.1.1.1               2.2.2.2               BGP      UPDATE Message

Frame 75 (97 bytes on wire, 97 bytes captured)

Cisco HDLC

Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)

Transmission Control Protocol, Src Port: 50780 (50780), Dst Port: bgp (179), Seq: 65, Ack: 65, Len: 53

Border Gateway Protocol

    UPDATE Message

        Marker: 16 bytes

        Length: 53 bytes

        Type: UPDATE Message (2)

        Unfeasible routes length: 0 bytes

        Total path attribute length: 28 bytes

        Path attributes

            ORIGIN: IGP (4 bytes)

            AS_PATH: empty (3 bytes)

            NEXT_HOP: 1.1.1.1 (7 bytes)

            MULTI_EXIT_DISC: 0 (7 bytes)

            LOCAL_PREF: 100 (7 bytes)

        Network layer reachability information: 2 bytes

Next R2  learns the prefix 10.0.0.0/8 and advertises it via ebgp to R3. Below is the path attributes of the prefix as advertised by R2 to R3

One thing which is missing is MED.  R2  does not include the med when it advertises a ibgp-learned prefix to its Ebgp peer R3.

Is this normal ?

No.     Time        Source                Destination           Protocol Info

     14 35.035000   200.200.200.2         200.200.200.3         BGP      UPDATE Message

Frame 14 (87 bytes on wire, 87 bytes captured)

Cisco HDLC

Internet Protocol, Src: 200.200.200.2 (200.200.200.2), Dst: 200.200.200.3 (200.200.200.3)

Transmission Control Protocol, Src Port: 13919 (13919), Dst Port: bgp (179), Seq: 20, Ack: 20, Len: 43

Border Gateway Protocol

    UPDATE Message

        Marker: 16 bytes

        Length: 43 bytes

        Type: UPDATE Message (2)

        Unfeasible routes length: 0 bytes

        Total path attribute length: 18 bytes

        Path attributes

            ORIGIN: IGP (4 bytes)

            AS_PATH: 1 (7 bytes)

            NEXT_HOP: 200.200.200.2 (7 bytes)

        Network layer reachability information: 2 bytes

================================================================================

I noticed that when  a router advertises its prefix which is locally generated -----  network x.x.0.0 " or redistributed into bgp----, router advertises such prefix to its ebgp peer with med attribute.

For example, R3 is advertising prefix 40.0.0.0/8 which is configured on its loopback, to its ebgp peer R2 with med attribute.

Below is the packet capture :

No.     Time        Source                Destination           Protocol Info

    223 729.950000  200.200.200.3         200.200.200.2         BGP      UPDATE Message

Frame 223 (94 bytes on wire, 94 bytes captured)

Cisco HDLC

Internet Protocol, Src: 200.200.200.3 (200.200.200.3), Dst: 200.200.200.2 (200.200.200.2)

Transmission Control Protocol, Src Port: bgp (179), Dst Port: 13919 (13919), Seq: 248, Ack: 272, Len: 50

Border Gateway Protocol

    UPDATE Message

        Marker: 16 bytes

        Length: 50 bytes

        Type: UPDATE Message (2)

        Unfeasible routes length: 0 bytes

        Total path attribute length: 25 bytes

        Path attributes

            ORIGIN: IGP (4 bytes)

            AS_PATH: 2 (7 bytes)

            NEXT_HOP: 200.200.200.3 (7 bytes)

            MULTI_EXIT_DISC: 0 (7 bytes)

        Network layer reachability information: 2 bytes

            40.0.0.0/8

May I conclude from the above:

A router does not include med attribute when advertising ibgp-learned prefix to its ebgp peer.  A router will include med attribute when advertising a locally generated bgp prefix----the prefix entered bgp table via network or redistribute--- to its ebgp peer

  thanks and have a great weekend.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Med attribute bgp

Hello Sarah,

What you observed is correct. According to BGP RFC 4271:

                                                     If received over
   EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to
   other BGP speakers within the same AS (see also 9.1.2.2).  The
   MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be
   propagated to other neighboring ASes.

So the MED can be either set on locally injected routes, in which case it will be propagated over iBGP and eBGP, or it can be set on networks received from another AS, in which case it will be propagated only via iBGP but will be stripped away when advertising prefixes further via eBGP. The reason is clear: the MED is an indication to a neighboring AS which entry point it is supposed to use when sending traffic back to us. However, this recommendation has no meaning past the neighboring AS and therefore must be stripped.

Best regards,

Peter

1 REPLY
Cisco Employee

Med attribute bgp

Hello Sarah,

What you observed is correct. According to BGP RFC 4271:

                                                     If received over
   EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to
   other BGP speakers within the same AS (see also 9.1.2.2).  The
   MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be
   propagated to other neighboring ASes.

So the MED can be either set on locally injected routes, in which case it will be propagated over iBGP and eBGP, or it can be set on networks received from another AS, in which case it will be propagated only via iBGP but will be stripped away when advertising prefixes further via eBGP. The reason is clear: the MED is an indication to a neighboring AS which entry point it is supposed to use when sending traffic back to us. However, this recommendation has no meaning past the neighboring AS and therefore must be stripped.

Best regards,

Peter

418
Views
0
Helpful
1
Replies