cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1259
Views
0
Helpful
7
Replies

iBGP advertisement manipulation

ianmprice
Level 1
Level 1

Hello,

So I have a problem where I know what is wrong, I just can't find a good way to fix it.

See attached diagram and relevant device configs / Outputs.

Scenario:

Router 1 and Router 2 are iBGP peers with Router 1 acting as RR.

Router 2 is connected to a 3rd Party for a single host resource (200.0.0.143) and uses a static route to get there.

Router 2 redistributes this Static route into BGP so that Router 1 can reach it and reflect to other clients.

Router 2 advertises the transit network to the third party via the "network" command in BGP

There is no IGP running, Only BGP.

Issue:

Routes are being advertised with the proper source (192.0.0.28), but the forwarding address chosen is from the route recieved from the BGP peer via the Internet. Obviously this is normal behavior, but what I need is for the forwarding path selected to be towards router2.

I see why it is not working, the next-hop for .104/29 is chosen to be forwarded out towards the internet. This causes the route that depends on the next hop of .108 to follow that same path.

Next-hop-self did not work, as this is not an eBGP learned route

Local preference for internet learned routes are set to 9,000

Local preference for all 192.0.0.0/24 subnets are set to 100,000

What I want:

A clean way to have the next hop for the .104/29 network, and subsequently the destination host .134, be towards router2, but still be able to use the next-hop learned via the internet for fail over.

Router1 should not have to apply any special logic to accomplish this.

I have tried using an outbound route-map on Router2 for the next hop as router2's peering interface (set ip next-hop 192.0.0.28), and while this gets traffic moving the direction I want (trace route verification), the route lookup for .104/29 and .134 still shows the next-hop as the internet path on router1. This is not very clean and I prefer not use this method if another is available.

_____

Thanks in advance for any suggestions or documentation that can point me in the right direction.

-Ian

7 Replies 7

JohnTylerPearce
Level 7
Level 7

I noticed the configuration below

Router1#sh ip bgp neighbors 192.0.0.28 received-routes

     Network           Next Hop            Metric LocPrf Weight Path
* i 192.0.0.104/29  192.0.0.28             0 100000      0 i
* i 200.0.0.134/32  192.0.0.108            0 100000      0 i

Can you post the results of a 'show ip route 192.0.0.28' and 'show ip route 192.0.0.108' on Router1?

Router1#sh ip route 192.0.0.28

Routing entry for 192.0.0.0/27

  Known via "connected", distance 0, metric 0 (connected, via interface)

  Routing Descriptor Blocks:

  * directly connected, via GigiabitEthernet0/1

      Route metric is 0, traffic share count is 1

Router1#sh ip route 192.0.0.108

Routing entry for 192.0.0.104/29

  Known via "bgp 200", distance 200, metric 0, type internal

  Last update from 36.7.65.0 11:38:38 ago

  Routing Descriptor Blocks:

  * 36.7.65.0, from 36.7.65.0, 11:38:38 ago

      Route metric is 0, traffic share count is 1

      AS Hops 0

      MPLS label: none

      MPLS Flags: NSF

Have you done, a 'clear ip bgp neighbor x.x.x.x soft in' yet on the iBGP session?

You have soft reconfiguration configured, so they're shouldn't be any downtime.

Yes, both directions.

Many times. :)

* i 192.0.0.104/29  192.0.0.28             0 100000      0 i

* i 200.0.0.134/32  192.0.0.108            0 100000      0 i

On Router1, what are the best routes for the above? Or are those the ONLY BGP routes you have for those networks?

I kind of figured you have done a 'clear ip bgp neighbor x.x.x.x soft in' before

*>i 192.0.0.104/29 36.7.65.0                0 100000      0 i

* i                  192.0.0.28             0 100000      0 i

* i 200.0.0.134/32

                       192.0.0.108            0 100000      0 i

*>i                  192.0.0.108             0 100000      0 i

Whats weird is that next hop. 36.7.65.0 (which is owned by as4134). All i see as a valid route is 36.4.0.0/12, which its obviously a part of, where as every other BGP route learned from my ISP has the next hop of the peers address.

Where is it getting this next hop?

So, before the BGP Path attributes come into play, BGP will do several checks. One is, if the received BGP route, receives a BGP path with it's on AS inthe AS_PATH, the other is, verify if there is a route for the next-hop address. Once both of these checks have passed, then the BGP Path Selection process will come into play, as long as they're are multiple routes to the same destination prefix.

Since, it's obviously preferring the BGP route to next_hop 36.7.65.0 when need to do the following.

1.
Prefer the path with the highest WEIGHT.

Note:  WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.

2.
Prefer the path with the highest LOCAL_PREF.

Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference  command, or to have a value of 100 by default.

3.
Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.

Local paths that are sourced by the network  or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address  command.

4.
Prefer the path with the shortest AS_PATH.

Note: Be aware of these items:

This step is skipped if you have configured the bgp bestpath as-path ignore  command.


An AS_SET counts as 1, no matter how many ASs are in the set.


The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.


5.
Prefer the path with the lowest origin type.

Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.

6.
Prefer the path with the lowest multi-exit discriminator (MED).

Note: Be aware of these items:

This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored.

In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.


If bgp always-compare-med  is enabled, MEDs are compared for all paths.

You must disable this option over the entire AS. Otherwise, routing loops can occur.


If bgp bestpath med-confed  is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE.

These paths originated within the local confederation.


THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is changed before insertion into the BGP table. The MED changes to to 4,294,967,294.


Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst .

If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a MED of 4,294,967,294.


The bgp deterministic-med  command can also influence this step.

Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a demonstration.


7.
Prefer eBGP over iBGP paths.

If bestpath is selected, go to Step 9 (multipath).

Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.

8.
Prefer the path with the lowest IGP metric to the BGP next hop.

Continue, even if bestpath is already selected.

9.
Determine if multiple paths require installation in the routing table for BGP Multipath.

Continue, if bestpath is not yet selected.

10.
When both paths are external, prefer the path that was received first (the oldest one).

This step minimizes route-flap because a newer path does not displace an older one, even if the newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).

Skip this step if any of these items is true:

You have enabled the bgp best path compare-routerid  command.

Note: Cisco IOS Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E introduced this command.


The router ID is the same for multiple paths because the routes were received from the same router.


There is no current best path.

The current best path can be lost when, for example, the neighbor that offers the path goes down.


11.
Prefer the route that comes from the BGP router with the lowest router ID.

The router ID is the highest IP address on the router, with preference given to loopback addresses. Also, you can use the bgp router-id  command to manually set the router ID.

Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.

12.
If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.

This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.

13.
Prefer the path that comes from the lowest neighbor address.

This address is the IP address that is used in the BGP neighbor configuration. The address corresponds to the remote peer that is used in the TCP connection with the local router.

If you go through the following for the two routes listed for the two destination prefixes, you should be able to find what's causing the BGP routes with 36.7.65.0 winning as the nxt hop.

Review Cisco Networking products for a $25 gift card