Multiprotocol BGP VPNV4 without labels

[ipotts]

Hello,

I want to use Multiprotocol BGP VPNV4, but I don't want it to send labels in the MBGP update for the routes, however I can't find a way to stop the labels being sent.

Can anyone please tell me how to strip/remove/stop the labels being attached to the VPNV4 updates?

I have tried

no mpls ip globally and per interface.

no neighbor send-label under the address-family vpnv4, however this gives the error message that it is not allowed.

Basically want to achieve is shown in the attachment. I want MBGP to advertise the VPNV4 routes so that R6 can receive the routes for the right VRFs. R3 is given all the red/orange VRF routes via the blue ipv4 VRF. Therefore in the forwarding of a packet from the green VRF on the left to the green VRF on the right the forwarding should all be without MPLS labels.

For example the packet (dest=192.168.150.1) hits R6 and from MBGP it sees 192.168.150.0/24 via 192.168.140.2. R6 then recurses to find that 192.168.140.2 is via 192.168.130.2 and sends out the packet.

R3 has learned 192.168.150.0/24 from a standard BGP connection with the blue VRF on the right side (which imports all local VRF routes).

The problem is that currently 192.168.150.0/24 is sent via VPNV4 with a label, so I get encap failed since there is no MPLS LDP running for the outer label stack (i.e. not standard MPLS VPN label stack).

[swaroop.potdar]

It would be nice to understand what and why are you doing the VPN setup this way.

HTH-Cheers,

Swaroop

[ipotts]

Hello,

The main reason is that I don't have the option to have MPLS in the middle of the network, whether natively, or tunneled over GRE/L2TP.

I want the green VPN at site A to only ever see routes for the green VPNs at the other sites, and MBGP with route-targets does a good job of this. The core network (represented by R3)is a core of many routers that don't run MPLS. This core is fed all VPN routes via the blue VPN (it imports all RTs).

Therefore the packet flow from the green VRF on R6 to green VRF on R2 is:

1. R6 green VRF only has routes to green VPN, so from within green VPN can't route to any other VPN (soft separation). IP source routing and default route are disabled.

2. R6 sends the packet to R3. R3 has all IPv4 routes for all VPNs from the blue VPN, so knows to forward the packet to R2.

3. R2 now forwards the packet to the final destination.

Therefore, I get "soft" separation of VRFs without the need for MPLS labels,

Regards,

Ian

[mheusing]

Hi,

The scenario you want either requires labels "in the middle", GRE/L2TP tunnels between PEs or a setup of VRF lite aka Multi-VRF. The problem I see with your approach is actually R2. How do you make sure the packet received by R3 ends up in the proper VRF? The tricky part with VPNv4 without labels is setting up the proper forwarding.

One option is to configure GRE or L2TP tunnels between the PE routers and enable MPLS on them. R3 would then only see IP traffic and would not require VPN routes at all.

The usual way to achieve the goal without labels is to configure VRFs on all involved routers and maybe not even use BGP at all.

Example:

Assign R6 interfaces G0/0 and G0/1.1 to VRF Green, G0/1.2 to VRF Blue

Assign R3 int G0/1.1 and F4/0.1 to VRF green and F2/0.2 and F4/0.2 to VRF blue

Assign R2 int F0/0.1 and F0/1 to VRF green and F0/0.2 to VRF blue

(there seem to be some interfaces missing in your drawing)

Then configure an IGP f.e. an OSPF process per VRF on each of the involved routers.

This is the typical scenario with a clear separation of VRF green and VRF blue end to end. I do not know your restrictions and requirements leading to your network design, so in case VRF-lite with f.e. OSPF as described above does not apply in your case, please let me know what I am missing.

Hope this helps! Please rate all posts.

Regards, Martin

[ipotts]

Hello,

Thank you for your reply.

I should have explained that R3 represents a core/global IPv4 network, that I can't make any changes to. All I can do it send it IPv4 EBGP routes.

Therefore, in response to your points about R2 not knowing which VRF to forward to, R2 has no VRF ,and has been sent IPv4 routes for all VRFs from the blue VRF on R2 (there is no address overlap between VRFs, so I can safely import all VRFs into the blue VRF).

Therefore, the next hop for R3 is the blue VRF interface on R2. R2 then has imported routes from all VRFs, so knows which VRF to deliver the packet to.

Currently R2 is a 2801, running ip advanced services, so with the 2801 not supporting MPLS, it receives its MBGP VPNV4 routes without any labels, which means my forwarding path from R2>R3>R6 works well (in one direction as I can see from a traceroute). So I can get this working okay with 2801s (MBGP without MPLS), but I can't do it with any other platform. Currently R6 is a 2821 with ip advanced services IOS, and it has MBGP+MPLS, so has a label for the green VRF routes on R2. If I could strip off this label somehow, then the solution would work perfectly, but I see now way to remove this label, without deploying 2801s at each site, which isn't an option, since I need higher end boxes for higher bandwidth,

Best Regards,

Ian

[swaroop.potdar]

Hi Ian,

looking at your diagram and your constraints, there seems to be only one way to achieve this. That is using Policy Based VRF Selection.

You will have to configure PBR VRF selection on your R6 and R2 routers,so the outgoing traffic towards this uncontrolled core would be IPv4 traffic and when it enters your edges on R6 or R2 it enters a VRF. Like wise your R2 or R6 routers would be having ipv4 peering with this external core and internally at each end they would be having vpnv4 for respective vrf. This solution is only possible since you have unique non overlapping and publically routable customer address space.

Here is a reference link for this feature:

http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a00804fbfac.shtml

HTH-Cheers,

Swaroop

[ipotts]

Hello,

Thank you for the link, it looks interesting.

I am looking at the config example - http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a00804fbfac.shtml#wp1065448

It shows a PE that has customers connected on POS1/0, and based on their source address, their VPN is selected. The advertisement of the customer routes into the VPN1 and VPN2 is clear.

However the advertisement of the VPN1 and VPN2 routes back to the customer is not clear to me, since the interface is not bound to a VRF, so I can't use any of the standard ip vrf import statements to control which routes are sent towards the customer.

Therefore, I don't understand in the attached diagram how I can get PE1 to advertise to CE1 the VPN1 routes of 200.10.0.0/16 and VPN2 routes of 200.20.0.0/16.

Can I please have some advice on how I can advertise the 200.10.0.0/16 and 200.20.0.0/16 from PE1 to CE1 using EBGP with IPv4 (not MBGP with VPNv4)?

The difficulty here is that PE1's POS1/0 interface is not in a VRF so the import/export commands, and the BGP address-family ipv4 vrf commands can't be used (i.e. the interface is in the global table).

[swaroop.potdar]

You will have to use the vrf static route pointing to the non-vrf PE-CE link. As the process cannot be done using dynamic routing.

Other option is to treat your AS 2 in between as a CE and AS 1 and AS 3 Edge routers would be PE for AS 2 routers. Peer with the routers in AS 2 inside a common vrf which would import all the vpn routes from the MPLS domain using RT's on both sides and pass it as ipv4 towards AS 2.

(MPLS)AS1(PE1)(PE3)AS3(MPLS)

the vrfx above would import all the routes from multiple vpns in and advertise out to AS2. when you receive the routes on either sides (from AS1 to AS3 or vice versa into vrfx export them assigning the RT which each specific VPN is importing to whom those prefixes belong)

Do let me know if i am not thinking as you are.

HTH-Cheers,

Swaroop