cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1608
Views
2
Helpful
9
Replies

MPBGP (VPNV4) is not working with VRF in transport Interface.

Jesuraj Pandian
Level 1
Level 1

Hi Team,

I have two scenarios where I am trying to bring up a VPNV4 session between two routers (PE1 & PE2). In one of the scenario, it works fine, while the other is not working. 

Scenario 1: 

If I create a VPNV4 peering using loopback interface (Lo) and transport interface (Gi2/0) in global table (added a static routes for loopback reachability on both PE routers), the VPNV4 peering comes up with no issues. 

(L0 / global) PE1 (Gi2/0 / global)  ------- (Gi2/0 / global) PE2 (Lo / global)

Scenario : 2

I have configured the PE1 and PE2 transport Interface (Gi2/0) and Loopback (Lo) into a VRF (OUTSIDE). Now, I have added necessary static routes for the loopback reachability in VRF OUTSIDE and I am able to ping each other. However, the VPNV4 peering is not coming up with this setup. 

(L0 / vrf: OUTSIDE) PE1 (Gi2/0 / vrf:OUTSIDE )  ------- (Gi2/0 / vrf: OUTSIDE) PE2 (Lo / vrf: OUTSIDE)

PE1#ping vrf OUTSIDE 30.1.1.1 sou lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.1.1.1 

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/60/156 ms

Below is the debugging output: 

*Sep  2 15:24:45.563: BGP: 30.1.1.1 Active open failed - no route to peer, open active delayed 7168ms (35000ms max, 60% jitter)

*Sep  2 15:24:52.731: BGP: 30.1.1.1 Active open failed - no route to peer, open active delayed 11264ms (35000ms max, 60% jitter)

I would like to hear your expert advise as to why the VPNV4 peering is not coming in scenario 2. Wether, this is a default behaviour? or do I missing something in the configuration? I have attached the configuration of both routers for your review and suggestion. Thank you in advance!

Regards,

Jesuraj

 

 

 

9 Replies 9

Harold Ritter
Spotlight
Spotlight

Hi @Jesuraj Pandian ,

The VPNv4 neighbor needs to be reachable via the global routing table (GRT). Configuring reachability to this neighbor via a VRF other than the default VRF (GRT) will not work.

Can you please explain what you are trying to achieve, so we can help you.

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

hi @Harold Ritter 

Thank you so much for your reply. Now, I understood, that the VPNV4 will only form using the global routing table. The reason I am trying to form a VPNV4 via VRF is to see whether we can run multiple VPNV4 session in same router or not?. 

Hi @Jesuraj Pandian ,

The reason I am trying to form a VPNV4 via VRF is to see whether we can run multiple VPNV4 session in same router or not?. 

And what would be the purpose of this?

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

Hello

PE1
router bgp 100
address-family ipv4 vrf OUTSIDE
neighbor 30.1.1.1 remote-as 100
neighbor 30.1.1.1 update-source Loopback0
neighbor 30.1.1.1 activate


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello @paul driver 

Many thanks for your reply. I have tried with the configuration you have provided. The IPv4 unicast peering BGP peering is up, but there VPNv4 does not come up stating "no route to peer". As @Harold Ritter mentioned, VPNV4 instance is looking for the route for peer loopback IP address in Global Routing Table (GRT) and it is failing to form. 

 

Regards, 

Jesuraj

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @Jesuraj Pandian ,

the VPNv4  address family neighborship has to be built in the global routing table GRT as noted by @Harold Ritter .

This is also required to build a working data forwarding plane as the MPLS label stack used to send L3 VPN packets uses two labels : the external label or IGP label is the label on the LSP with destination = remote PE loopback and the internal VPN label is provided by MP BGP in AF VPNv4 by remote peer with BGP next hop = remote PE loopback.

This is called recursion and it works only with GRT.

This is the reason why the VPNv4 AF needs to be in the GRT it is not indipendent it re-uses GRT MPLS forwarding table to reach the remote PE loopback.

enabling a VPNv4 session over a VRF interface would not provide this capability (BGP next hop recursion to solve BGP next hop to MPLS LSP to remote PE loopback). This is why it is not allowed.

Hope to help

Giuseppe

 

Hi @Giuseppe Larosa@paul driver,

Thank you so much for the detailed information about the usage of GRT in MP-BGP session. It was very much helpful to understand the reason behind using GRT.

I've attached the lab setup digram that we're trying to achieve. Please find its details.

We're trying to form a MP-iBGP session between loopback ip of customer-1 that span across two routers and in the same way, one more MP-iBGP session between loopback ip of customer-2 as shown in the diagram.

We keep the WAN connection in its own VRF as we may have more than one WAN connection so that the IPSec tunnel always stays up regardless of the failure of one wan connection.

Could you please help us to understand and in what way we can achieve this lab setup?

JesurajPandian_0-1693909523845.png


Thank you so much,
Jesuraj.

Jesuraj Pandian
Level 1
Level 1

Hi,

Any help on the request?

 

Thank you,

Jesu.

I see only PE2 have address family ipv4 but PE1 have not?