I am trying to "leak internet" into a VRF. All is configured and working fine, however, the default route is entered static with the 'ip route vrf' command.
Is there a way that I can get the default route from my global table (learned on all PE via OSPF) and somehow 'redistribute' it into the VRF?
If I enter it as static, I have to choose one of our upstreams over another. Is there a better way to do this? I want it to lose the default if one of the providers goes down and use a different default.
Come to think of it, better yet, is there a way to just say to use the global routing table for any unknown routes within the VRF (maybe restricted by source IP)? Our PE's have full routing tables from iBGP global. That way I will get the redundancy and optimization.
Any help would be great! All the cisco docs only have one 'Internet'
That's still a static route. I should of been more clear in the original post. When I said I used the "ip route vrf blah blah" I assumed to mean "ip route vrf blah blah global" I should of been more clear.
It works fine with that, I need it learned dynamically from the global table, or to just use the global table for all unknown routes. I can't point it to a specific IP with a static as at any given time I may and don't know what the next hop is. It's a large multi-homed, fully meshed iBGP/ospf network and is dependant on the destination adress for what the next hop would be. I don't really have "default routes" as all PE/P routers have full routing tables.
Well it looks liks I can try:
(config-vrf)#import ipv4 unicast | multicast [prefix-limit] map route-map
At least that way, I can setup all our egress routers to dump a default route into the network.. None of the routers should really use them (except for routes not in the full table for some reason)
At least this way there is some resiliency in the VRF for it's default route so if the default learned is lost, it should learn another from one of the other routers advertising it.
I would still rather just be able to say "if route unknown use the global" even better to say "if source is x.x.x.x and route unknown, use global table" maybe I am dreaming...
I will give this setup a try today.
I feel like I am talking to myself :)
Looks like this is restricted to only 5 vrf's so, no good to me. No point in even trying it.
* from cisco docs:
A maximum of 5 VRF instances per router can be created to import IPv4 prefixes from the global routing table.
tbh thats the first time i have seen that command - i thought - nice one! then read your second post and went "typical".
helooooo is there anybody out there?
*tumble weed blows past*
I'm pretty new with mpls, but here's a thought.. What do you think?
I will create another vrf that is say "internet" and within that, I will try that new command and import the default route to it, other than that.. the "internet" vrf won't really have any routes just a default pointing to the global/imported default.
Could I then import the "internet" vrf into any vrf's that need the default global route?
Are there are problems you see with that?
I can only imagine the documentation I will need to get created on commissioning an internet service within a VRF and the data path process :)
You can try it. But i think there are 2 issues in this.
1) I think prefixes imported into this vrf cannot be imported in other vpnv4 vrfs.
2)Default route redistribution is a big question mark if you ask me , though i have never tried it
You may be right..
I am getting the default into my 'internet' vrf, but it does not seem to be importing into my 'customer' vrf. I am determined though.. so I will find a way :)
I was just browsing past, and saw the tumbleweeds blow by
I've done this approach before, or something like it. The key is, I think, this works as long as any natting and firewalling is done by the customer before you see the internet bound traffic. Only public address space can be used in this vrf. Or if you as provider are doing the natting, then all internet vrf address space must be discrete.
It might make more sense to create separate "customer-to-internet" vrfs, to allow for firewalling and natting to be handled by the customer in "internet" rather than intranet space to keep things cleaner and more secure. And as you said, leak your default into your internet vrf. Leaking can be static, ipv4 bgp, whatever is appropriate for your network.
To the customer, they get two connection types, 1 is internal, and the other internet. Same as they always have. And you, as provider, get the provisioning "benefits" provided by mpls.
The customer will be doing the NAT, I was thinking of somehow limiting so only public IP's would get out of the vrf into the global table/default (not sure if possible haven't looked into it yet)
For your suggestion, how do you assign the 2 vrf's to the customer? by using sub-interfaces? Would I then have all 'internet' customers a member of the same 'internet' vrf? I can only import the default route into a maximum of 5 vrf's (limitation of IOS) unless there is another way to get the dynamic default into the VRF from the global.
Others will correct me, but I think you pretty much have two choices. You could do sub-interfaces/VCs or separate interfaces. The limitation on your side is that you need to be able to place the interface or sub-int in a vrf. For the customer, that choice depends on the type of connectivity we're talking about, and customer connectivity options. For example, can your customer separate an internet and intranet VC with without separate equipment a la vrf-lite, drop & insert, etc, or do they want to?
In the model I was referring to, these circuits or VCs would land on separate CE (including router/firewall/ids etc) for obvious security reasons.
Either way, one vrf is a customer inter-site vrf, and the other is an untrusted internet feed. If you do the subinterface route, the customer will need use their own vrfs to separate and firewall internet traffic.
The next portion is the trickiest, and needs to be thought through carefully. But here's the general idea.
To leak your defaults and advertise customer spaces, create another bgp "address-family ipv4 vrf xxxx" using a private AS instance to create some confederation-like peerings with your core or an appropriate portion thereof.
Long and short of it is that in this model, you are creating a "customer" called Internet. This "customer" just happens to have "sites" at several of your real customer premises.
In any event, you're not leaking default into your customers' trusted address space from your core. Your real customers are getting an unprotected live internet feed on the new Internet pipe. Since you own the peering that provides this connectivity, you provide the Internet/public addresses your "Internet" customer uses at your real customer sites.