BGP MPLS VPN (MP-BGP) detailed questions

[gianluca.bianchi]

Hi All,

I have a few Q’s about BGP/MPLS/VPN that I haven’t found answer on, on any text or community. As they are all related, I think it's better to open a single thread for them all.

1- consider this setup on PE1 - PE2 (the objective here is for PE1 and PE2 to see all each other's routes for a specific VRF):

PE1

ip vrf lab

rd 100:1

route-target export 100:2

route-target import 100:3

PE2

ip vrf lab

rd 100:1

route-target export 100:3

route-target import 100:2

This should work fine, because RD, RT-IMP and RT-EXP (on each single router) are totally unrelated; am I correct? (As long as the statements cross-match with the other router of course)

2- focusing on how a single PE advertises routes into MPBGP,

PE1

ip vrf lab

rd 100:1

export map VPN-A

route-target export 100:2

route-target import 100:3

route-map VPN-A permit 10

set extcommunity rt 100:5

The effect should be: PE1 advertises all its routes into MPBGP, with just one RT-EXP value (that is 5); is that right?

So for ex., this PE2 should be able to import all those routes:

PE2

ip vrf lab

rd 100:1

route-target export 100:3

route-target import 100:5

And this PE3 shouldn't be able to import any routes from PE1, right?

PE2

ip vrf lab

rd 100:1

route-target export 100:3

route-target import 100:2

Basically this Q is about the order of processing within PE1; I think it is:

First ATTEMPT to advertise all routes marking them with RT-EXP = 2; then put them through the local router's filter (export-map), that changes the RT from 2 to 5; then place them into MPBGP with RT = 5, only.

I don't think the router should then go back and check again the route against its RT-EXP statement that assigns "2" only... right? Otherwise it would be impossible to use an export-map that sets ExtCommunity without the "additive" keyword...

3- I have found this setup on some Cisco documentation (Ivan Pepelnjak, Jim Guichard MPLS and VPN Architectures, CCIP Edition 2000):

PE1

ip vrf lab

rd 100:1

export map VPN-A

The VPN-A map is defined, but no route-target export (or import) statements are configured in the vrf, at all; is it simply a typo/mistake or does it mean that the export-map is not only a filter, but it can actually "push" advertisements out, for assigned export-RT ?

4- this is the main Q of all for me; if the following is used as an import-map for a customer vrf:

route-map customer-imports permit 10

match ip address prefix-list abc

match extcommunity VoiceNets

route-map customer-imports deny 20

match extcommunity VoiceNets

route-map customer-imports permit 30

match ip address prefix-list Management-Addresses

match extcommunity Mon

route-map customer-imports deny 40

match extcommunity Mon

route-map customer-imports permit 50

I would like to know the exact meaning of the DENY clauses; for ex. statement 20, does it mean: do not import any prefixes from vrf VoiceNets (except those already imported thanks to statement 10), regardless what happens in the following clauses? Or does it mean: do not import them SO FAR, unless a broader permit statement (such as #50, "permit any") allows it? I suspect the former is correct, but I'd like confirmation.

5- And for last I would really appreciate it if someone could indicate me a very good book to study details of BGP/MPLS/VPNs, as I have about 20 of them, and none of them goes deep enough into details. I would need the precision and clarity of authors such as Scott Morris, and the (few) ones like him....

Thanks in advance to whoever can help! (Forgive the capital letters here and there, it's only for clarity).

Luca

[Harold Ritter · Accepted solution]

Hi Luca,

1. RDs do not need to match between PEs but you are correct of the RTs.

2. Correct, routes will be exported with RT 100:5 only, since the "additive" keyword is not used. Only VRFs importing RT 100:5 will get these routes.

3. I think this just a partial configuration to illustrate the export map. The "route-target export" is optional if you use an "export map". The "route-target import" has to be used if you want to import routes in the VRF, whether you use an "import map" or not.

4. Correct. deny 20 will deny all routes matching extended community VocieNets that have not been accepted in the previous instance.

5. For me, Jim Guichard's book as always been a good reference.

Regards

[gianluca.bianchi]

Hi Harold,

thank you for your answers; they are all clear to me, except #3.

When you say: <I think this just a partial configuration to illustrate the export map. The "route-target export" is optional if you use an "export map">

I am confused, because from the first statement, I seem to understand that since it is just a partial config, the author actually means that also export-RTs should be configured, and he just doesn't bother showing them; on the other hand, from the 2nd statement, it looks like an export-map itself can already "push" routes out, even without any export-RTs configured in that particular vrf.

I think (but I am far from sure!) that an export-map is not enough, and also export-RTs are necessary, for this reason: an export-map may or may not set values for RTs; so hypotetically one could configure something like this:

PE1

ip vrf lab

rd 100:1

export map VPN-A

route-target import 100:3

route-map VPN-A permit 10

match ... (some routes)   <<<<<------ without any RTs being set!

thus creating a vrf that exports routes without any export-RT assigned to them; which I guess makes no sense, IOS should block it...

I hope I explained myself

Thanks,

Luca

[Harold Ritter · Accepted solution]

Hi Luca,

Sorry for the confusion.

What I meant is that you do not necessarely need a "route-target export" statement if you have an "export map". As you mentioned, this is assuming that the "export map" sets the RT. Otherwise, you would still need to use the "route-target export" statement. I personally think I prefer to use an "export map" without a "route-target export" statement as it makes it less ambiguous which RT the routes are exported with.

Regards

[gianluca.bianchi]

Thank you very much Harold!

Luca