BGP Attributes and More specif route

[TK19]

Hi all,

This is my first post here...

Wanted to confirm something, with the following scenario:

Two routes are being advertised to a BGP neighbor, one is a more specific (/32) and another a /28.  

The design is advertising the /32 with two as path prepend and /28 with one as path.

From my understanding, in the normal forwarding plane, more specific always wins.

But in this scenario, the BGP process of Path selection will be looked at first (I think).

So the question is, will BGP neighbor install the more specif route (with two as-paths) or install /28 which has only one as-path?

Thanks in advance,

TK

[Sergey Lisitsin]

TK19,

Actually, both routes will get installed. They are considered different routes. The traffic for a host that matches /32 path will go via that path. The packets matching /28 prefix will go via /28 path.

[TK19]

Thanks for the reply.

The situation we had, if I can repeat with some diagrams, was we were advertising a /32 with one as-path to the ISP and from a second router adverting a /28 with two as-paths, to the same ISP.   ISP was steering traffic back to us through the router that was advertising a /28 (PE2-CE2), for devices that were configured to talk to /32.

CE1  (/32 as-path x 2)   --> PE1 (ISP)    core

CE2 (/28 as-path x 1)   --> PE2 (ISP)     core

I think it could be that the ISP design when exporting to the core is adverting aggregates?  As i cannot think of any other reason why they would prefer /28 path for traffic destined to /32.

Thanks,

TK

[Richard Burts]

TK

Thanks for the additional information. What you describe here is certainly not the expected behavior. It may take some additional investigation to understand this issue. As a next step would you post the output on both of your BGP CE routers of the command show ip bgp neighbor advertised

HTH

Rick

[TK19]

Thanks for the reply.

I cannot paste any details here due to Confidentiality, security will be all over me, and i wont have access to the router now for next few days.

If there is anything specific you want to know, please let me know and i'll update accordingly.

Thanks,

TK

[Sergey Lisitsin]

TK19,
Can you please explain what do you mean by "for devices that were configured to talk to /32." I don't understand this point. You advertise a /32 route to the ISP and that route matches a single host. Every router having this route will use it to reach that single host. For example, you advertise 192.168.1.10/32 to ISP1 and 192.168.1.0/28 to ISP2. Both ISPs exchange all routes. Any traffic for 192.168.1.10 will come via ISP1. Traffic for all other hosts in 192.168.1.0/28 will come via ISP2.

[TK19]

Hi Sergey,

So we have Dual-homed design where the two CE's are connected to the two PE's, of the same ISP.  

The issue is, the devices that are connected in the remote location, on the other side of the ISP cloud are configured to with next hop of /32 (lets say its a server sitting in our organisation, behind the CE)

As explained earlier, the ISP PE is preferring the /28 path (CE2-PE2) instead of the /32 path (CE1-PE1).

So, my theory is, it could be that the ISP when getting the 192.168.1.0/28 & the /32 from the CE, its ignoring the /32 and exporting only /28 (aggregate) to the remote devices. 
On the other side of the cloud where the remote device is connected, the PE its connected to has only the /28 in its routing table, which it received from the core.  Now, the remote device, which needs a route to /32 is seeing this /28 subnet and therefore the return traffic is using the /28, as that is the only route it has on the remote side PE.  Again this is just a theory, i might be wrong!

Hope that explains.

Thanks,

TK            

[Giuseppe Larosa]

Hello TK,

you have now described with more details your network scenario.

If I understand correctly you have an MPLS L3 VPN service.

In this case your routers the CE1 and CE1 are peering with directly connected PE nodes.

Yes, the MPLS SP can actually perform  filtering of /32 host routes or aggregation before exporting the resulting VPNv4 prefix.

You can ask to the MPLS SP to help you in achieving the desired behaviour.

Another important point is that the two PE nodes should use different route distinguishers, in this way their VPNv4 prefixes would be NOT comparable and propagated everwhere via route reflector and  the remote PE could see both routes and make a choice after importing based on BGP attributes.

Usually /30 prefixes are accepted in a VPN as most VRF access links use them. As an approximation of your desired behaviour you could try to advertise a /30 prefix from CE1, including the IP address of the server of interest, and you can see if the /30 prefix is propagated to remote PE.

In any case I would ask to the MPLS SP to have different RDs on their PE1 and PE2 nodes.

This can be an improvement.

Hope to help

Giuseppe

[TK19]

Hi Giuseppe,

The /32 is really for our own design reasons, to prefer to more specific than the aggregate, but what was puzzling me is why the ISP was preferring the /28 and not the /32. 
Thanks for all you help in this forum, at least the initial confusion is now clear.

Cheers,

TK

[paul driver]

Duplicated - apologies

[Giuseppe Larosa]

Hello Tk19,

as explained by Sergey BGP is a classless routing protocol so it is able to see the two prefixes including the prefix length as two different NLRI.

Both will be installed in BGP table and in the routing table and as usual the most specific prefix is used depending on packet destination address.

The two advertisements are compared only if they have the same network mask / prefix len only in that case BGP will pick a single BGP best path for the NLRI.

Hope to help

Giuseppe

[SamanBayat4424]

Hi

The BGP AS path is an attribute, which means that it’s present for all prefixes exchanged between BGP neighbors. 

Unsurprisingly, an individual BGP router adds entries to its local BGP table by using the same general methods used by IGPs: by using the network command, by hearing the topology information via an Update message from a BGP neighbor, or by redistributing from another routing protocol. 

So AS path attributes are completely different with injecting routes to BGP table. It doesn't matter.

Generally when you inject a subnet into bgo table, then you will decide to tune the attributes.

[vividhat]

Both routes will be treated separately. In case, there are routes with same subnets then attributes will be considered.

[paul driver]

Hello

Just like to add -Make sure your not becoming a transit path between ISP's only advertised locally originated prefixes

example:
ip as-path access-list 10 permit ^$
router bgp xx
neighbor <iSPx) filter-list 10 ou