Routing

Hi All !

I have a strange request which actually deals with a problem I had to face.

1. Topology :

VPN RED <=> PE1 <=> PV (RR) <=> PE2 <=> VPN RED

                           PE1 <=> PI (RR) <=> PE2

2. Design :

The PI router is the Route Reflector for family inet and  inet6 labeled-unicast explicit-null

The PV router is the Route Reflector for family inet-vpn

3. Supposition :

PE1 is sending the correct VPN NLRI and route to PEV

4. Question

How is it possible, by mistake as well, to make PV not filling the bgp.l3vpn.0 table ? I mean not route at all present in bgp.l3vpn.0 table, which include hidden route....

5. Context :

I meet this problem few weeks ago and I'm not able to reproduce the problem. I don't have access to the device. I remember I had to go through traceoption and saw error message like "invalide target"....

I need your help !

Thank you

Salah

This is mostly guesswork, not knowing all the conditions (your description was excellent but I am talking about being on the console) I can make two suggestions.

1. The RR did not have LSPs defined to the PEs. This would cause a lookup failure in the inet.3 table and cause the routes to be hidden in bgp.l3vpn.0 table. This is also unlikely because if I understand correctly, you said there were no hidden routes as well.

2. The RR had the "keep all" knob explicitely deactivated. This is applied by default when you define a cluster, making the router an RR. Deactivating this would make the RR behave like a regular PE and therefore any routes that do not match a local route-target import policy will be ignored and not brought into the bgp.l3vpn.0 table. 

Like I said, those are two of the possible causes I can think of. Without knowing more, nothing else comes to mind at this moment.

HTH,

Nic

Hi Nic,

Thanks a lot for your reply.

From your answer 1) this doesn't match my context as that a emtpy inet.3 will make my bgp.l3vpn route has hidden. So they will be present in my bgp.l3vnp table which is not what I was looking for.... 🙂

From you answer 2) It's a good point !  Well almost. When I configured "keep none" in my bgp group vpn-rr, I got the the result I expected : the bgp.l3vpn table is empty ! Well, it actually almost the result I expected because when I look on PE1, it doesn't advertise the L3VPN RED routes to the RR, which is not what I expected....

So any others idea ?

--

Salah

Ok, so I had to reread the question carefully. I thought this was a situation you had encountered but it looks like this is a situation you want to create.

So we both agree on point 1.

For point 2, the PEs, 1 and 2 should be advertising thier routes to the RR normally. Configuring keep all|none on the RR will not make a difference to the advertised routes (show route advertising-protocol bgp NEIGHBOR). I would suggest you check the configuration again on PE1/PE2 to ensure this is happening. If it is not, I would think that the reason may be different than the keep configuration on the RR.

On the flip side, an empty bgp.l3vpn.0 table on RR means that it is now unable to perform any reflection. Therefore, your PE to PE MBGP is now broken. 

I guess in the end, there seems to be no way (none I know of at least) that will ensure an empty L3VPN table on RR but still keep the PE to PE MBGP working. Was there a special reason for this requirement?

HTH,

Nic

thanks again for your reply.

It's a situation I had and I didn't understand. So I want to create it because I have no access to the device anymore.

a) When I configured the "keep none" statement on the RR, the PE1 ADVERTISE  the route. I didn't wait enough the first time. Actually I didn't expect that "keep ...." will reset the bgp session. So anyway, "keep none" will empty the bgp.l3vpn table on the RR and has no action on the PE. Good ! So you almost solve the problem except that I didn't got the same "error" message I was able to see when I faced the problem (something like "invalid target comm"...)

"On the flip side, an empty bgp.l3vpn.0 table on RR means that it is now unable to perform any reflection. Therefore, your PE to PE MBGP is now broken. "

=> Correct. Actually it's the problem I meet : the VPN RR wasn't able to assume the VPN route reflection because the bgp.l3vpn table was empty, even if the PE1 (show I had to go through traceoptions to see a message like "invalid target"....

Woooooooooww Well actually your writing make me understand what was wrong !!!!

Missing the cluster statement !

Very basic mistake !!! I was able to reproduce the 'problem"

Thanks a lot for your help !

No problem. Selecting a post as solution and kudos gladly accepted. 😉

Nic