Trying to reach global ip address, from within VRF.

simongillard1 · ‎08-30-2015

Hello all,

I am trying to come up with a solution, with the ultimate end goal to have different customers traffic segregated via VRFs, but all share 1 ISP breakout default route. This is to save on public IP addresses, so that I dont have to use a separate interface and public address per customer inside a vrf.

This is from an ISP perspective, so the default breakout to the internet, I would like all customer traffic to breakout at this same point as global traffic, but until that point remain segregated within VRFs.

I am hoping to eventually be able to implement a solution where all customers use the same phase 1 for IPSec, but their phase 2 SA's are defined and segregated within VRFs.

Is this feasible? I would imagine the big ISP's implement something similar to preserve public address's ( not 1 public address per customer), aswell as the many private address they would have to route too and separate.

Currently, I am able to reach "our side" of the ISP point to point when sourcing from different VRFs, but I cannot reach the global ip address on the other side.

I have tried many different ways to allow an IP address from within a VRF to reach a global IP address, but cannot seem to find any solution, especially when this takes place from within 1 router.

R2 represents the customers router, R1 represents "our" router, the ISP for the customer, and R3 represents our peer for internet break out.

In these examples vrf shared exists between R1 and R3, but only on R1. vrf CUSTOMER_A exists between both R1 and R2 (in real life R2 wouldn't necessary need to be in a vrf as the connection wouldn't be directly connected, it would just be IPSec into a vrf port-channel.)

R2 (Customer Router): Able to ping 212.182.173.1 which is inside vrf shared when sourced from vrf CUSTOMER_A, but unable to ultimately reach the global ip address.

R2#ping vrf CUSTOMER_A 212.182.173.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.182.173.1, timeout is 2 seconds:
!!!!!

ping vrf CUSTOMER_A 212.182.173.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.182.173.2, timeout is 2 seconds:
....

R1 (ISP Router): Unable to ping global address on the other end of the point to point when sourced from vrf CUSTOMER_A, but able to when sourced from vrf shared.

ping vrf CUSTOMER_A 212.182.173.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.182.173.2, timeout is 2 seconds:
.....

ping vrf shared 212.182.173.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.182.173.2, timeout is 2 seconds:
!!!!!

If I could find a way for R2 to ping 212.182.173.2 from within the vrf (VRF > global ip) that would solve the connectivity issues.

Here are the full configs for the 3 Routers.

Router 1:

version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
!
ip vrf CUSTOMER_A
rd 1:2
route-target export 1:2
route-target import 1:2
route-target import 1:1
!
ip vrf shared
rd 1:1
route-target export 1:1
route-target import 1:2
route-target import 1:1
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 101
ip vrf forwarding CUSTOMER_A
ip address 172.16.0.1 255.255.255.0
!
interface FastEthernet0/1
ip vrf forwarding shared
ip address 212.182.173.1 255.255.255.0
speed auto
duplex auto
!
router bgp 65000
bgp router-id 1.1.1.1
bgp log-neighbor-changes
!
address-family ipv4 vrf CUSTOMER_A
redistribute connected
exit-address-family
!
address-family ipv4 vrf shared
redistribute connected
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 212.182.173.2
ip route vrf CUSTOMER_A 0.0.0.0 0.0.0.0 212.182.173.2 global
!
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end

Router 2:

version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
!
ip vrf CUSTOMER_A
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
speed auto
duplex auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 101
ip vrf forwarding CUSTOMER_A
ip address 172.16.0.2 255.255.255.0
!
interface FastEthernet0/1
no ip address
shutdown
speed auto
duplex auto
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route vrf CUSTOMER_A 212.182.173.0 255.255.255.0 172.16.0.1
!
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end

Router 3:

version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet0/1
ip address 212.182.173.2 255.255.255.0
speed auto
duplex auto
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end

I hope I've described the situation well enough for anyone to be able to offer any help or support, thank you very much for reading and I'd really look forward to any suggestions or different solutions people may know of to accomplish the goal.

Many thanks!

Reza Sharifi · ‎08-30-2015

Hi,

Have a look at this document.

https://rekrowten.wordpress.com/2014/02/21/route-leak-between-global-ipv4-table-and-vrf/

HTH

simongillard1 · ‎08-30-2015

Hi Reza,

Thank you for providing this link, whilst this does allow a global route to be reachable from within a vrf, it doesn't fit the criteria i'm looking for.

In the above sample the vrf traffic is not segregated over the 192.168.12.0/24 point to point, and not at all inside R2. Whilst the loopback0 or loopback22 on R2 could represent an global internet break out point, the different vrf traffic for customers would have to merge after entering R1.

I'm looking for a solution where the vrf traffic remains totally segregated, only up until the point where internet break out occurs one 1 global interface.

If in the previous link, the vrf ABC on R1 could be made aware of the 192.168.12.0/24 subnet, this would totally achieve that goal (you could ignore R2 essentially.)

Is that possible?

Many thanks

simongillard1 · ‎08-31-2015

Hi all,

I found an exact solution for this situation here:

http://aconaway.com/2011/12/12/vrf-aware-ipsec-tunnels/

This is exactly what I was after, I now only wonder if this is possible, but without the "global shared" interface egress interface being inside a VRF?

Is it possible to have this solution, but with a global interface as the ISP breakout for the separate segregated vrf customer traffic?

Many thanks