cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
493
Views
0
Helpful
5
Replies

Why is BGP inserting a Weight?

neil_titchener
Level 1
Level 1

Hi All,

I've setup BGP/EIGRP redistribution on a WAN router and I don't understand why I'm seeing a Weight in one route and not in another when the two subnets are subject to the same route configuration.  There is no BGP weight configuration on this router so I'd be extremely grateful if someone could explain why I'm seeing a Weight for one router and not another and how I remove this Weight.  I believe I can add a set statement to the route-map setting the Weight to zero but happy for any advice.  Apart from the Weight the routing looks ok so it's not a routing/route redistribution issue it's just the Weight which is skewing the routing decisions.  I've changed some detail as it's a private network.

Configuration

outside interface

interface GigabitEthernet0/0/0
 description WAN link to BT router 10.99.1.1 circuit ID xxxxx
 ip address 10.99.1.2 255.255.255.252
 no ip redirects
 no ip proxy-arp
 ip mtu 1492
 ip tcp adjust-mss 1452
 negotiation auto
 service-policy output xxxxxx
end

router eigrp 10
 network 172.21.0.0
 network 172.22.0.0
 redistribute bgp 65059 route-map bgp-to-eigrp-redist
 eigrp router-id 172.26.254.12
!
router bgp 65001
 bgp router-id 10.99.1.2
 bgp log-neighbor-changes
 timers bgp 10 30
 neighbor 10.99.1.1 remote-as 2855
 neighbor 10.99.1.1 description BT-router
 neighbor 10.99.1.6 remote-as 65001
 neighbor 10.99.1.6 description HQDC-WAN-02
 neighbor 10.99.1.6 update-source GigabitEthernet0/0/0
 neighbor 10.99.1.10 remote-as 65001
 neighbor 10.99.1.10 description hq2DC-WAN-01
 neighbor 10.99.1.10 update-source GigabitEthernet0/0/0
 neighbor 10.99.1.14 remote-as 65001
 neighbor 10.99.1.14 description HQ2DC-WAN-02
 neighbor 10.99.1.14 update-source GigabitEthernet0/0/0
 !
 address-family ipv4
  synchronization
  network 10.99.1.0 mask 255.255.255.252
  redistribute eigrp 10
  neighbor 10.99.1.1 activate
  neighbor 10.99.1.1 default-originate route-map default-originate
  neighbor 10.99.1.1 soft-reconfiguration inbound
  neighbor 10.99.1.1 route-map eigrp-to-bgp-redist out
  neighbor 10.99.1.6 activate
  neighbor 10.99.1.6 soft-reconfiguration inbound
  neighbor 10.99.1.10 activate
  neighbor 10.99.1.10 soft-reconfiguration inbound
  neighbor 10.99.1.14 activate
  neighbor 10.99.1.14 soft-reconfiguration inbound
 exit-address-family


access-list 65 remark route-map bgp-to-eigrp-redist define specific routes for outbound load balancing
access-list 65 permit 172.23.96.0 0.0.31.255
access-list 65 permit 172.23.128.0 0.0.31.255
access-list 65 permit 172.23.160.0 0.0.31.255
access-list 70 remark route-map bgp-to-eigrp-redist define specific routes for outbound load balancing
access-list 70 permit 172.23.192.0 0.0.31.255
access-list 70 permit 172.23.224.0 0.0.31.255
access-list 70 permit 10.99.1.0 0.0.0.255
access-list 70 permit 10.99.102.0 0.0.0.255

route-map bgp-to-eigrp-redist permit 10
 match ip address 65
 set metric 10040000 10 0 1 1
!
route-map bgp-to-eigrp-redist permit 20
 match ip address 70
 set metric 10010000 40 0 1 1
!
route-map bgp-to-eigrp-redist permit 30
 set metric 10040000 10 0 1 1

sample output showing the Weight

     Network          Next Hop                      Metric     LocPrf     Weight Path
 * i 172.23.120.0/24  10.99.101.5              0           100           0          2855 65002 i
 * i                  172.24.120.217                  5888      100           0          ?
 *>                   10.99.101.1                                                      0          2855 65002 i
 * i                  10.99.101.9                        0            100           0          2855 65002 i
 *>  172.23.121.0/24  172.24.120.169      11008                     32768 ?
 *                    10.99.101.1                                                       0         2855 65003 i
 * i                  172.24.120.201                  10752    100           0         ?
 * i                  10.99.101.13                      0            100           0         2855 65003 i
 * i                  10.99.101.5                        0            100           0         2855 65003 I

thanks for looking and thanks for any advice :-)

5 Replies 5

Hello

Weight is locally significant only, it is not advertised to any other peer or rtr, So what you are seeing is that rtrs locally default weight value for the prefix  172.23.121.0/24 via 172.24.120.169

res

Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Thanks Paul, I understand how Weight works but why am I seeing it for 172.23.121.0/24 and not for 172.23.120.0/24.  The result of this is that the 172.23.121.0/24 route is not being redistributed into EIGRP when the routing configuration is identical to both subnets.  I have four routers connected to the external AS system and fully meshed internally.  The route maps provide a level of load balancing and failover redundancy between the four routers.   I'm finding that many routes that sit within the same defining access-lists are sometimes redistributed into EIGRP (as I would expect) and sometimes not redistributed.  All routes that are not redistributed have a Weight assigned.

Hello

This was learned from an IBGP peer, so weight would not be advertised and prefixs that are received via a IGBP,EBGP neighbor will have the weight path attribute of 0

 * i 172.23.120.0/24  10.99.101.5              0           100           0          2855 65002 i
 * i                  172.24.120.217                  5888      100           0          ?
 *>                   10.99.101.1                                                      0          2855 65002 i


This was originated by the local rtr
 *>  172.23.121.0/24  172.24.120.169      11008                     32768 ?

res
Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

It's also been learned by an eBGP peer, 10.99.101.1.  The aim is to redistribute this route into EIGRP but it's not doing that.  When I set up the route-maps I used the delay metric to differentiate between the preferred routes however the values I used were small, 10, 20, 30 and 40.  I think I need to change these to be 100, 500, 1000 and 1500 so there's a greater calculated metric for each potential route.  Will this resolve how BGP is interpreting these routes?

Hello Neil 

your query was regards how and why weight was seen for one prefix and not the other correct?

Regards the routes not being advertised don't forget only the valid route populated in the rtrs rib via the bgp table would get advertised 

res

paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card