This post is about a situation I ran into a while ago and records my configs and testing for converting from a PBR setup to VRF on a Cisco 881 router with a diagram at the end.
Through a combination of configs involving PBR (Policy Based Routing) AKA Source Routing (as opposed to standard Destination Routing), Proxy Server exceptions, and Default Route/missing Default Route it was impossible to get to internet facing apps/sites over guest wifi or branch backup VPN.
I knew I could use VRF’s (Virtual Routing and Forwarding) to separate the traffic and solve the issue, but had to prove it to my team as they weren’t familiar with VRF’s. A Cisco router without VRF’s built only has the “global routing table”. VRF’s create separate instances of routing tables; one for each VRF, while leaving the global in place.
IOS-XE comes with a mgmt-intf VRF by default for a separate management network. Carriers use VRF’s, or contexts in some non Cisco hardware, to keep customers traffic separate and allow for overlapping network schemes. If needed you can “leak routes” between VRF’s and/or the global routing table. This would be done if the carrier has something like a network monitoring server that needs to access customer devices.
I used a post by Jeremy Stretch at packetlife.net as a guide and to show that someone smarter than me confirmed the design. http://packetlife.net/blog/2012/sep/4/simultaneous-tunneled-and-native-internet-access/
Jeremy’s post goes into the details of building everything from the base up.
Testing:
Test from a computer on guest wifi:
C:\Users\>tracert google.com Tracing route to google.com [172.217.5.78] over a maximum of 30 hops: 1 81 ms 139 ms 251 ms 172.17.1.1 2 152 ms 35 ms 29 ms [10.1.180.1] 3 520 ms 173 ms 652 ms [10.254.254.161] 4 4 ms 6 ms 7 ms [****] 5 8 ms 5 ms 15 ms [****] 6 12 ms 10 ms 6 ms 144.228.109.65 7 34 ms 166 ms 219 ms sl-mpe50-sea-.sprintlink.net [144.232.3.126] 8 662 ms 638 ms 849 ms 72.14.242.31 9 572 ms 45 ms 9 ms 108.170.245.115 10 578 ms 995 ms 370 ms 66.249.94.201 11 955 ms 618 ms 507 ms 209.85.240.228 12 268 ms 457 ms 447 ms 216.239.54.158 13 358 ms 342 ms 638 ms 216.239.51.124 14 61 ms 71 ms 51 ms 108.170.247.193 15 56 ms 88 ms 68 ms 108.170.237.113 16 55 ms 32 ms 44 ms 172.217.5.78 Trace complete.
Test from a computer on the regular corp wifi or LAN:
C:\Users\>tracert google.com Tracing route to google.com [172.217.5.78] over a maximum of 30 hops: 1 12 ms 5 ms 11 ms 192.168.2.1 2 5 ms 5 ms 3 ms 10.3.254.1 < --- Headend Tunnel interface 3 10 ms 4 ms 5 ms [10.254.254.161] 4 17 ms 2 ms 9 ms [***] 5 6 ms 4 ms 4 ms [****] 6 10 ms 3 ms 7 ms 144.228.109.65 7 6 ms 2 ms 2 ms sl-mpe50-sea-.sprintlink.net [144.232.3.126] 8 5 ms 4 ms 5 ms 72.14.242.31 9 7 ms 4 ms 3 ms 108.170.245.115 10 9 ms 12 ms 9 ms 66.249.94.201 11 10 ms 29 ms 26 ms 209.85.240.228 12 34 ms 54 ms 59 ms 216.239.54.158 13 32 ms 32 ms 32 ms 216.239.51.124 14 30 ms 31 ms 30 ms 108.170.247.193 15 33 ms 30 ms 29 ms 108.170.237.113 16 38 ms 31 ms 40 ms 172.217.5.78 Trace complete.
Config differences:
ADD config:
First you have to create a named VRF. Some people use all caps for VRF names to make them stand out. I don’t because it’s a pain when you want to ping, trace, or use any VRF specific commands.
!The VRF names doesn’t matter but fdoor relates to Front Door VRF sometimes used with DMVPN. It separates the base routing and the “overlay routing” used by the VPN. You could also put all interfaces in VRF’s and not use the global routing table but I didn’t.
!Create the VRF. ! ip vrf fdoor ! !Required to support DHCP when using VRF’s. no ip dhcp use vrf connected ! !Place the internet interface in the VRF interface <internet-interface> ip vrf forwarding fdoor ! !Place the guest interface in the VRF interface vlan15 ip vrf forwarding fdoor ! !Tell the tunnel to use the VRF for its source interface. Interface <tunnel-number> tunnel vrf fdoor
CHANGE config:
!The NAT needs to be told about the VRF. !Change this: ip nat inside source list 130 interface <internet-interface> overload ! !To this: ip nat inside source list 130 interface <internet-interface> vrf fdoor match-in-vrf fdoor overload !The default route needs to be moved to the VRF. !Change from this: ip route 0.0.0.0 0.0.0.0 <internet-interface> <internet-gw> ! !To this: ip route vrf fdoor 0.0.0.0 0.0.0.0 <internet-interface> <internet-gw>
REMOVE config:
! interface Vlan10 no ip policy route-map wifi-mgmt-route-map ! ! interface Vlan30 no ip policy route-map wifi-guest-route-map ! ! interface Vlan36 no ip policy route-map LAN-route-map ! ! no route-map wifi-mgmt-route-map permit 10 !match ip address CAPWAP-traffic !set ip precedence flash-override !set ip next-hop <branch-LAN-gw> ! no route-map LAN-route-map permit 10 !match ip address all-except-localwifi !set interface Tunnel1999 ! no route-map wifi-guest-route-map permit 10 !match ip address 130 ! !These routes are not needed as we have dynamic routes for the tunnel and a static default route for internet access in the fdoor VRF. no ip route 0.0.0.0 0.0.0.0 vlan33 <branch-LAN-gw> 254 no ip route <DNS1> 255.255.255.255 <internet-interface> <internet-gw> no ip route <DNS2> 255.255.255.255 <internet-interface> <internet-gw>
As you can see you end up with less configs and better routing. I was able to convert a few hundred of these setups over a few weeks with old school copy pasta. But it I had to do this again I’d spend time on a Python script that would convert, test, and document the results.
