OSPF default route inject into VRF

[LynK]

Guys,

I am trying to essentially re-design our guest infrastructure. What I am trying to do is get a default route from our firewalls, that advertises down to our cores into a guest VRF. For whatever reason in GNS3 this will not work. Any thoughts? I do not want to advertise a static route because that defeats the purpose of redundancy.

Can this be done?

Design is simple. Firewall and core are in GRT right now. I have an SVI + VRF for guest network in GNS3. Trying to see if I can get the 0.0.0.0 propagated.

Here is the config:

Code Select Expand


ip vrf GUEST
rd 1094:1
import ipv4 unicast map Import
route-target export 1094:1
route-target import 1094:1
!
interface Loopback1040
ip address 10.10.40.1 255.255.255.0
ip ospf 1 area 0
! 255.255.255.0
ip ospf 1 area 0
!
interface Loopback1094
ip vrf forwarding GUEST
ip address 10.10.94.1 255.255.255.0
!
interface GigabitEthernet3/0
description ***TO INTENRET***
ip address 10.0.0.5 255.255.255.252
ip ospf 1 area 0
negotiation auto
!
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
route-map Import permit 10
match ip address prefix-list DEFAULT
!


[deanwebb]

Said the security guy, "What's wrong with static routes?"

Feel free to me.

[LynK]

lol... nothing is wrong with them if you have 1 ISP, and don't care about redundancy

[LynK]

yeah I figured it out. You need BGP to utilize the GRT IGP, then issue the network 0.0.0.0 under the GRT address family, then do the import config:

Code Select Expand


router bgp 65000
bgp log-neighbor-changes
!
address-family ipv4
  network 0.0.0.0
exit-address-family
!
address-family ipv4 vrf GUEST
  redistribute connected
exit-address-family
!
!
!
!
ip vrf GUEST
rd 1094:1
import ipv4 unicast map Import
route-target export 1:99901
route-target import 1:5


This allows you to reach out, but then there is no return route. But in order for a return route, you need a static route to the vrf network.... and then you need to advertise it in ospf.... But if you advertise it in ospf then you defeat the purpose of a VRF....


anyone know a workaround.... lol.

[wintermute000]

I'm not seeing the issue.  Of course you need the return route.

The VRF has to 'merge' somewhere at some point (presumably on the FW) so the return route only needs to be present from there on end. You don't need (shouldn't) to propagate back into internal.

However, if your design is sane then surely the VRF boundary is on the FW so you could just block guest <--> internal traffic with FW rules anyway. If you're running OSPF depending on your area boundaries you may not actually have an option to not propagate ROFL but like I said make the VRF to GRT boundary on the FW then you can just deny the traffic easily.


If you want to nut it out then I think you're going to need to throw up some diags

[LynK]

yeah running VRFs directly to the firewall is definitely the cleanest rout (and probably the best). But I was just testing a scenario in my lab for simple internet access through a transit VRF on the core to firewall links (separate obviously).

[wintermute000]

you're going to need to throw up a diag, because running a VRF to the firewall is the same as 'transit VRF on the core to the firewall links' in my mind... you got a separate VRF, it goes to the FW?

[LynK]

Ok. Maybe it will make sense if I clarify the design.



You are talking about running multiple VRFs directly to the firewall with subinterfaces/physical per VRF.


I am talking about having no VRFs on the firewalls, but having a single VRF on the core side which goes to the "inside" interface of the firewall. This VRF is used as a transit VRF for shared internet access. The reason I am trying to design something like this is if the firewall team refuses to run VRFs on their side, or if they refuse to run multiple interfaces for internet access.


see attached for a dumbed down visio

[wintermute000]

Ah ok then in that case yeah yu're going to have to import/export bidirectionally

like this sample (excuse ye olde VRF syntax). Note Tenant1 is basically shared services so there are selective filters i.e. the import/export is not completely open. But the logic should be clear. I was doing a similar use case on a single router a few years back (to leak shared services into clients).

Code Select Expand


ip vrf TENANT1-M
rd 1:1
import map RM-TENANT1-IMPORT
route-target export 1:1
route-target import 1:1
route-target import 901:901
!
ip vrf TENANT2-M

rd 901:901
import map RM-TENANT2-IMPORT
route-target export 901:901
route-target import 901:901
route-target import 1:1
!

route-map RM-TENANT2-IMPORT permit 10
match ip address prefix-list PL-TENANT1-TO-TENANT2
!
route-map RM-TENANT2-IMPORT deny 20
!
route-map RM-TENANT1-IMPORT permit 10
match ip address prefix-list PL-TENANT2-TO-TENANT1
!
route-map RM-TENANT1-IMPORT deny 20

router ospf 1 vrf TENANT1-M
router-id 172.25.1.33
capability vrf-lite
area 1 authentication message-digest
redistribute bgp 1 subnets tag 33 route-map RM-TENANT2-TO-TENANT1-SUMMARYONLY
passive-interface default
no passive-interface Port-channel1.995
network 172.25.1.0 0.0.0.255 area 1
!
router ospf 33 vrf TENANT2-M
router-id 10.33.0.33
capability vrf-lite
area 0 authentication message-digest
redistribute static metric-type 1 subnets
redistribute bgp 1 subnets tag 901 route-map RM-CUST-TAGFILTER
passive-interface default
no passive-interface FastEthernet0/0/0.901
network 10.33.0.33 0.0.0.0 area 0
network 192.168.254.0 0.0.0.255 area 0
!
router bgp 1
bgp router-id 172.25.1.33
bgp log-neighbor-changes
!
address-family ipv4 vrf TENANT1-M
  aggregate-address 10.33.0.0 255.255.0.0 summary-only
  redistribute static
  redistribute ospf 1 route-map RM-TENANT2-IMPORT
exit-address-family
!
address-family ipv4 vrf TENANT2-M
  redistribute static
  redistribute ospf 33
exit-address-family
!

And yeah you need to run everything through BGP including redistributing between OSPF. The VRF import/export mechanisms are operating via MP-BGP.