BGP and MED

I have a scenario in BGP i am playing with, and i'm not sure i understand what's happening.

 

I have 2 routers, router 3 and router 1. They have a iBGP peering. R3 redistributes ospf into bgp. 

R3 has 172.16.103.3 on the lo0 interface, R1 has 172.16.101.1/24 on the lo0 interface. They both have ip ospf network point-to-point configured so it shows up as configured in bgp output.

[code]

R3 config:


router ospf 1

 log-adjacency-changes

 network 13.0.0.3 0.0.0.0 area 0


router bgp 13

 template peer-session IBGP

  remote-as 13

  password ibgp

  update-source Loopback0

 exit-peer-session

 !

 redistribute ospf 1

 neighbor 172.16.101.1 inherit peer-session IBGP

 no auto-summary

[/code]

R1 has similar config in ospf and bgp without the redistribution. Here is the output of show ip bgp from R3 and r1 resp. :


[code]

R3#sh ip bgp

BGP table version is 4, local router ID is 172.16.103.3

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

*> 13.0.0.0/24      0.0.0.0                  0         32768 ?

*> 172.16.101.0/24  13.0.0.1                65         32768 ?

*> 172.16.103.0/24  0.0.0.0                  0         32768 ?


[/code][code]

R1#sh ip bgp

BGP table version is 5, local router ID is 172.16.101.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

r>i13.0.0.0/24      172.16.103.3             0    100      0 ?

r>i172.16.103.0/24  172.16.103.3             0    100      0 ?

R1#

[/code]

My main questions are:

-Why does R1 not get its own loopback address from R2. It is advertised by inspecting advertise-routes but it does not show in R1's table.

-Why does R3 set the MED and R1 does not

 

I noticed that the status code does not show i or e when advertising ourself, as on R3. R3 copes the igp metric into the MED, but the next-hop is directly connected, not known through IGP. Why does it still copy the IGP metric, i thought it only did this when the next-hop is known through an IGP. The other routes on r3 are directly connected interfaces, so get no MED or next-hop metric.

On R1, all routes get a next-hop metric as there the next-hop in show ip bgp is known through an IGP (ospf). For some reason R1 does not get it's own network back in the bgp table, ( i would have expected it to show up as a rib-failure?). And why does R1 not receive any attached MED values?

 

Last but not least, the weight 32768, is this the value that is assigned by default when redistributing? If so, why does R1 not have this weight attribute?

 

Please forgive me for any questions which i would have figured out eventually. It's just that this forum is so helpful and you are all a great bunch of guys/gals :-)

Comments

  • OK, I'll try to answer some of your queries.

    RIB failure means that the route has been learnt with a better AD from some other protocol (OSPF).

    By default locally originated routes get a weight of 32768. This is so that local routes are preferred over routes received.

    The reason you don't see an i or e (you should never see e) is that you have redistributed routes. Redistributed routes have an unknown origin explained by the question path in the path. Since the path is empty it means you received the prefix over iBGP which is also indicated to the far left.

    MED is used to announce to neighboring AS which path you want external traffic to take IN to your AS. This means that MED is not used inside the local AS. By default MED is only compared for prefixes from same neighboring AS but this behavior can be manipulated.

    I'm not sure why you are not seeing R1 loopback announced by R3. Do a debug ip bgp updates and see if you are receiving it. It might be that you are receiving it but R1 does not install it due to it being connected.

  • Hi atv,

    See here why R1 is not getting it's own Loopback address from R3:

    R3 is advertising R1's loopback address but R1 deleting it because next-hop is itself, if any BGP neighbor re-advertise the routes with next-hop is local-router, it deletes the route.

    R2#show ip bgp neighbors 1.1.1.1 advertised-routes

       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.1/32       12.12.12.1              22         32768 ?
    *> 2.2.2.2/32       0.0.0.0                  0         32768 ?
    *> 12.12.12.0/24    0.0.0.0                  0         32768 ?
    *> 22.22.22.22/32   0.0.0.0                  0         32768 ?

    Total number of prefixes 4
    R1#show ip bgp | be Net
       Network          Next Hop            Metric LocPrf Weight Path
    r>i2.2.2.2/32       2.2.2.2                  0    100      0 ?
    r>i12.12.12.0/24    2.2.2.2                  0    100      0 ?
    *>i22.22.22.22/32   2.2.2.2                  0    100      0 ?

    If you turn on debug ip bgp updates, and clear the bgp peering using clear ip bgp *, you can see this message:

    *Apr  1 07:10:30.523: BGP(0): 2.2.2.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: NEXTHOP is our own address;

    Why RIB failure on R1 because all routes are advertising by other routing protocols with better Administrtive Distance:

    R1#show ip bgp | be Net
       Network          Next Hop            Metric LocPrf Weight Path
    r>i2.2.2.2/32       2.2.2.2                  0    100      0 ?
    r>i12.12.12.0/24    2.2.2.2                  0    100      0 ?
    *>i22.22.22.22/32   2.2.2.2                  0    100      0 ?

    I have denied 22.22.22.22 network to install by OSPF on routing table so there is no RIB failure:

    R1#show run | section router ospf
    router ospf 1
     log-adjacency-changes
     network 0.0.0.0 255.255.255.255 area 0
     distribute-list prefix DENY22 in
    R1#show ip prefix-list
    ip prefix-list DENY22: 2 entries
       seq 5 deny 22.22.22.22/32
       seq 10 permit 0.0.0.0/0 le 32

    Good Luck

  • Thing for the edge: That one is cool here for remembering the bgp attributes!

    http://media.packetlife.net/media/library/1/BGP.pdf 

     

    Regards!

    Markus

  • Hi Guys,

    Sorry for the late reply.

    Ok so i understand why R1 does not get it's own loopback address, as explained by naryan.

    I also understand why R1 does not get the MED (because only outside ASes get and compare the MED) (so a ebgp peer would get the MED)

    As far the weight only being on R3, that's because weight is not a attribute that propagates, it's local, and R3 is the one originating the routes, so as Daniel said by default locally originated routes get a weight of 32768.

    What i don't understand yet is *why* R3 sets the MED to begin with. Is this because of that we are originating routes as well (by way of redistribution in bgp)?

Sign In or Register to comment.