Solved: Med attribute bgp

sarahr202 · ‎02-03-2012

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.

Peter Paluch · ‎02-03-2012

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

View solution in original post

Peter Paluch · ‎02-03-2012

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