PBR for 2nd ISP Based Guest Network - 4331/IOS XE Router

[johnhart]

Hi IOS SMEs,

I have set up a "Guest" network via second ISP connection.

My primary network is via different ISP and has working BGP based routing, which advertises a set of Class C addresses and gets static route to ISP returned.

The guest network is on interface GE0/2/1:

!
interface GigabitEthernet0/2/1
ip address dhcp
ip nat outside
zone-member security OUT
negotiation auto
!

I have set up "Guest" network on Vlan15 using NAT & PBR (to ensure Guest traffic by-passes BGP based routing):

interface Vlan15
ip address 172.16.ZZ.1 255.255.255.0
ip nat inside
zone-member security GUEST
ip policy route-map ALT_PATH_2
!

ip nat inside source route-map ALT_PATH_1 interface GigabitEthernet0/2/1 overload

!
route-map ALT_PATH_1 permit 5
match ip address 123
!

!
route-map ALT_PATH_2 permit 10
match ip address 123
set ip next-hop 110.XXX.16.1
!

ip access-list extended 123
permit ip 172.16.ZZ.0 0.0.0.255 any

Both my primary network (via BGP) and Guest network with PBR are working as expected. The problem I have is that the PBR "next-hop" ip address (110.XXX.16.1) has been added manually using information provide by looking at the GB0/2/1 dhcp route option details:

#show dhcp lease
Temp IP addr: 110.XXX.17.105 for peer on Interface: GigabitEthernet0/2/1
Temp sub net mask: 255.255.248.0
DHCP Lease server: 58.YYY.26.202, state: 5 Bound
DHCP transaction id: E42
Lease: 14400 secs, Renewal: 7200 secs, Rebind: 12600 secs
Temp default-gateway addr: 110.XXX.16.1
Next timer fires after: 01:10:15

I configured the "next-hop" to avoid the Guest traffic hitting the GB0/2/1 interface and then being routed based on the BGP static route. The problem is that as the address & default-gateway on GB0/2/1 are provided via dhcp, The result is that if the ISP changes the allocated address (& default-gateway) then my PBR "next-step" configuration breaks.

Can IOS XE SME/s please advise if there is way to achieve successful "avoidance" of BGP based static routes via PBR which somehow automatically gets next-hop from dhcp rather than through me manually looking this up and configuring it.

Thanks in advance for any advise/suggestions.

John Hartley

[Richard Burts]

John

Assuming that the DHCP from the ISP for your guest traffic includes a default route in addition to an IP address, I suggest that using a VRF for the interface for guest users and the interface for the ISP would then let you configure a default route for that vrf pointing to the advertised route from the guest ISP.

[johnhart]

Hi Richard,

thanks very much for suggestion on using VRF to address guest network.

After a bit of research and reading, I changed my config as follows:

1. Added VRF

ip vrf GUEST-VRF

 rd 137XXX:73

2. Put DHCP Server (and exclusions) for Guest network into VRF

ip dhcp excluded-address vrf GUEST-VRF 172.16.XX.1 172.16.XX.9

ip dhcp pool GUEST-POOL-1

 vrf GUEST-VRF

 ...

3. Put NAT definition into VRF

ip nat inside source route-map ALT_PATH_1 interface GigabitEthernet0/2/1 vrf GUEST-VRF overload

4. Put both ISP interface & guest network interface into VRF (and removed PBR from guest interface)

interface GigabitEthernet0/2/1

 ip vrf forwarding GUEST-VRF

 ip address dhcp

 ...

interface Vlan15

  ip vrf forwarding GUEST-VRF

  ip address 172.16.XX.1 255.255.255.0

 ...

5. Added DHCP derived static route into VRF

ip route vrf GUEST-VRF 0.0.0.0 0.0.0.0 GigabitEthernet0/2/1 dhcp

This appears to all be working ok and achieve aim of removing my manually added "next-hop" for PBR approach. I believe it also provides much better isolation for GUEST network from main network.

One question on the VRF RD, if you use an RD based on valid AS Number, does this result in the VRF getting advertised ?

Does this look ok to you or have I missed something ?

Regards,

John

[Richard Burts]

John

Thanks for the update. Your changes look pretty good to me. While I think you could have achieved your goal using PBR, I agree that VRF provides a more simple and more effective solution than PBR. And it provides some isolation that PBR could not have provided.

Not sure I understand your question about advertising RD/AS number, but I don't think there is an issue for your approach.