Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

How to deny a VRF to advertise routes learned from another VRF.

Folks.

I'm facing a problem which I'll try to describe in a really short and simple manner.

Scenario description:

Suppose a Full Mesh MPLS-based VPN containing only three sites, lets name it Sites A, B, and C.

The sites A & B deploys BGP between its CEs & VRFs, and Site C deploys routing through static routes.

So, I have: Site A CE <--------BGP--------> VRF A

Site B CE <--------BGP--------> VRF B

Site C CE <-- static routes --> VRF C

VRF A, VRF B, and VRF C export and import the same route-target.

Platforms : Cisco 75XX , version 12.0(27)S4

Both Sites A & B have Internet access.

Site A CE advertises a default route to its VRF (VRF A) through BGP when its Internet connection is operational

Site B CE also advertises a default route to its VRF (VRF B) through BGP when its Internet connection is operational

Both sites A & B may provide Internet access to Site C. When both VRF A & VRF B are learning a default route

from its respective CE, they retransmit these default routes to VRF C. In this scenario VRF C must choose access through

VRF A, and this choice is guaranteed through local-preference associated to both routes learned (from VRF A & from VRF B).

Now the problem description:

When the Site A Internet access goes down, Site A CE stops to advertise a default route to its VRF (VRF A) as expected,

VRF A learns the default route that VRF B learns from Site B CE and advertises (that's fine), and VRF A advertises the

default route (from VRF B) to Site A CE (that's fine); "BUT" VRF A also advertises the default route learned from VRF B

to VRF C, and that's the problem.

I wish that VRF A would not advertise to VRF C the route it learns from VRF B !

As the VPN topology is Full Mesh, VRF C learns the same route straight from VRF B and also from VRF A (as VRF A is redistributing

the route learned from B), and due the metrics associated to the routes according to its source, VFR C is chosen to route

redistributed from VRF A as the best path.

To overcome this problem, at VRF A using "import map" I associate a specific route-target (lets say : ASN:96) to the routes

learned from VRF B (that works fine), and though "export map" I tried to deny VRF A to advertise it but this did not work.

When I issue a "sh ip bgp vpnv4 <VRF-A> 0.0.0.0" I can verify that the routes learned from VRF B got associated to the desirable RT

(ASN:96), but looks like at the time the route is advertised by VRF A (export route-target) that RT (ASN:96) is not been considered,

the route is advertised, and (ASN:96) is removed. Due it, it doesn't work to deploy a "import map" at VRF C denying routes marked

with RT "ASN:96".

So I wonder how could I deny VRF A to advertise routes learned from VRF B, knowing that a prefix-list is not feasible ?

I'd appreciate a lot any feedback that could help me solving this specific matter.

Yours Truly.

Murilo Pugliese.

9 REPLIES

Re: How to deny a VRF to advertise routes learned from another V

Hello Murilo,

I think the solution to your puzzle lies in the way CE A inserts the default route into BGP. I assume this is done like this and A does not have redundant connections to the MPLS VRFs:

router bgp 65000

network 0.0.0.0

default-information originate

This will insert the default route into BGP once ANY default route is in the IP routing table. What I would suggest is to conditionally insert the default network into BGP on CE A.

router bgp 65000

network 0.0.0.0 route-map DefNHcheck

route-map DefNHcheck

match ip next-hop 10.1.1.1

This assumes your local default-route next hop in location A is 10.1.1.1

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: How to deny a VRF to advertise routes learned from another V

Dear Martin.

First of all, thanks for your reply.

You are right regarding who CE A inserts the default route into BGP. When Site A has it connection to the Internet operational, at first it learns a default route from couple sources, through IGP as Internet connection is established at another CE, and from BGP (CE-PE VPN connection). Due a administrative distance manipulation, the CE that holds the VPN connection considers the default route learned

via IGP as the best path, and so it advertises it toward its VRF. At the Site A VRF, default route is learned from couple sources, via eBGP (CE) and via iBGP (MPLS domain BGP - MPBGP), and that one learned from eBGP is considered the best route.

So, the VRF does not advertises it back to its attached CE. Anyway, Internet access redundancy is working just fine at Site A.

The problem is happening at Site C, as I do not know how come (when Site A Internet access is down and the route learned at VRF A from VRF B is being considered the best, and only, route) VRF A is advertising to other VRFs (VRF C in this case) routes learned from a third party VRF (VRF B), what should not happening.

In this scenario, VRF C learned the default route originally advertised by VRF B straight from it and also from VRF A (that is distributing the route it learns from VRF B).

In this case, the workaround kindly suggested will not solve this issue, as far as I can understanding it.

Best regards.

Murilo Pugliese.

Re: How to deny a VRF to advertise routes learned from another V

Hello,

I think it is CE A causing the problem, not the VRF. Simple reason: updates learned through iBGP are never sent to another iBGP neighbor. So the PE router with VRF A will not send the update learned through PE B with VRF B to router PE C with VRF C.

The problem in your case is: why on earth CE A is announcing the default route in the first place, if the internet connection is down? It might be a mis-/suboptimal configuration on CE A, which I assume.

So you should prevent CE A from announcing the default route, which my initial config should achieve.

Hope this helps! Please rate all posts.

regards, Martin

New Member

Re: How to deny a VRF to advertise routes learned from another V

Martin.

I think I did not make myself clear.

The CE A is not announcing the default route back.

When Site A Internet connection is up, it considers the default route learned from IGP better than the one learned from eBGP, due a metric manipulation. So, CE A advertise the default route learned through IGP toward VRF-A. The VRF-A than consider the route learned through eBGP better than the one learned through iBGP (advertised by VRF-B).

When Site A Internet connection is down, there is no default route learned from IGP.

Then VRF-A just learns the default route advertised by VRF-B (iBGP), and distributes it to its CE (Site A).

At Site A everything is working just fine, any both situations : its own Internet connection up or down.

The problem is effecting VRF-C (Site C). Its supposed to always prefer the default route learned from VRF-A instead of the one learned from VRF-B, when learns from both VRFs.

But when Site A internet connection is down, VRF-A just learns a default route from VRF-B, as expected it advertises this route toward CE @ Site A, but for sure it should not advertise this route (learned from one VRF) to another VRF.

I know that wasn't supposed to happen, and as it was told by a nice fellow:

When a PE imports a route via MP-BGP, it does not re-advertise this route via MP-BGP to other PEs.

That's the problem, with no relation to the CE at Site A. It's happening at the PE level.

That is the reason your kindly suggested configuration will not solve this issue.

Anyway, I did appreciate your good will.

Best regards.

Murilo Pugliese.

Re: How to deny a VRF to advertise routes learned from another V

Hello, can you post a "show bgp vpnv4 vrf" for A and C in case the problem exists?

What you are saying is that the PE is forwarding an iBGP update to another iBGP neighbor. This IS in violation of all BGP RFCs and thus a severe IOS bug, IF it can be proved true.

All I wanted to say is: make sure there is no misconfiguration involved (most likely on CE A).

If you are sure, then open a case with TAC and for sure the IOS will be defered pretty soon in case you can prove yourr statement.

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: How to deny a VRF to advertise routes learned from another V

Dear Martin.

That's really weird.

Just to give you a snapshot regarding what's going on, follows bellow the outputs of "show ip bgp vrfv4 vrf 0.0.0.0" for the VRFs related to Site-A, Site-B & Site-C.

PE-1#sh ip bgp vpnv4 vrf Site-A 0.0.0.0

BGP routing table entry for AS:98:0.0.0.0/0, version 48608

Paths: (1 available, best #1, table Site-A)

Advertised to update-groups:

1 4

65001, imported path from AS:97:0.0.0.0/0

X.Y.W.86 (via Site-B) from X.Y.W.86 (X.Y.W.86)

Origin IGP, metric 1, localpref 80, valid, external, best

Extended Community: RT:AS:97

PE-1#

PE-1#

PE-1#sh ip bgp vpnv4 vrf Site-B 0.0.0.0

BGP routing table entry for AS:97:0.0.0.0/0, version 38523

Paths: (1 available, best #1, table Site-B)

Advertised to update-groups:

1

65001

X.Y.W.86 (via Site-B) from X.Y.W.86 (X.Y.W.86)

Origin IGP, metric 0, localpref 100, valid, external, best

Extended Community: RT:AS:97

PE-1#

PE-3#sh ip bgp vpnv4 vrf Site-C 0.0.0.0

BGP routing table entry for AS:99:0.0.0.0/0, version 2558971

Paths: (2 available, best #1, table Site-C)

Not advertised to any peer

65000, imported path from AS:98:0.0.0.0/0

X.Y.W.160 (metric 2) from X.Y.W.166 (X.Y.W.166)

Origin IGP, metric 1, localpref 100, weight 32768, valid, internal, best

Extended Community: RT:AS:98

Originator: X.Y.W.160, Cluster list: 0.0.0.1

65001, imported path from AS:97:0.0.0.0/0

X.Y.W.160 (metric 2) from X.Y.W.166 (X.Y.W.166)

Origin IGP, metric 1, localpref 80, weight 32768, valid, internal

Extended Community: RT:AS:97

Originator: X.Y.W.160, Cluster list: 0.0.0.1

PE-3#

A case was already opened at Cisco TAC, but to be honest with you from 2 year ago on I'm not that much confident on TAC efficiency solving my issues, so I decide to post the problem description @ Networking Professional and other technical list willing to get feedback from other sources.

Best regards.

Murilo Pugliese.

Silver

Re: How to deny a VRF to advertise routes learned from another V

Just giving a top of the mind answer, set another additive RT using an export map in each VRF. Match the Extended Comminity (Or I think even a normal community will work) and deny redistrubution of routes. Let me know if what i said is simply not workable at all.

New Member

Re: How to deny a VRF to advertise routes learned from another V

I've tried it already and unfortunately that doesn't work. Trying to overcome this problem, at VRF A using "import map" I associate a specific

route-target (lets say : ASN:X) to the routes

learned from VRF B and that worked just fine, then though a "export map" I tried to deny VRF A to advertise routes marked with this RT but this did not work.

When I issued a "sh ip bgp vpnv4 0.0.0.0" I could verify that the routes learned from VRF B got associated to the desirable RT (ASN:X), but looks like at the time the route was advertised by VRF A (export route-target) that RT (ASN:X) was not been considered, the route was advertised and (ASN:X) was somehow removed. Due it, it cold not deploy a "import map" at VRF C denying the import/learning

of routes marked with that RT (ASN:X) either.

Re: How to deny a VRF to advertise routes learned from another V

Well the real problem can be seen from the "show bgp" output (I removed the less important parts):

PE-1#sh ip bgp vpnv4 vrf Site-A 0.0.0.0

BGP routing table entry for AS:98:0.0.0.0/0, version 48608

Advertised to update-groups:

1 4

65001, imported path from AS:97:0.0.0.0/0

Extended Community: RT:AS:97

and

PE-3#sh ip bgp vpnv4 vrf Site-C 0.0.0.0

BGP routing table entry for AS:99:0.0.0.0/0, version 2558971

65000, imported path from AS:98:0.0.0.0/0

Extended Community: RT:AS:98

65001, imported path from AS:97:0.0.0.0/0

Extended Community: RT:AS:97

Where from does the path AS 65000 come? In fact this usually means, that the erroneous entry in VRF C does not come from the same source as the default route in VRF B. The AS path is 65001 for the default sent from VRF B, but AS 65000 for the undesired entry.

Does the undesired entry vanish if you shut the BGP sessions from VRF A to neighbors in AS 65000?

Can you please highlight, where AS 65000 and AS 65001 are found? Could it be that CE A has AS 65000?

Also can you provide a "show bgp vpnv4 unicast all 0.0.0.0/0" on your route-reflectors?

Hope this gets a little closer to a solution.

Regards, Martin

248
Views
0
Helpful
9
Replies
CreatePlease to create content