Hi Ross, The VRF route leaking is somehow complex stuff - there appears to be scattered documentation about it around CIsco site - see for example http://www.cisco.com/en/US/docs/ios/12_2sr/12_2sra/feature/guide/srbgprid.html
What we do to dynamicly leak routing from one VRF to another is to do it with eBGP. Simply make a eBGP session between the VRFs (f.e. create a Loopback for each VRF) and send the routes across - see http://forum.nil.com/viewtopic.php?f=10&t=59&sid=9c8b6a132bfdbfd0794b69b573b1914c&start=10 Another alternative is to put the routes into VRF BGP table and leak them with "route-target import" - see http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml To take somewhat intelligent approach I suggest to read about the "Common services VRF" in "MPLS and VPN Architectures" - ~ Ivan Pepelnjak, Jim Guichard - a great set of books not only about MPLS. Hope it helps, -pavel On Wed, Jan 6, 2010 at 3:28 PM, Ross Vandegrift <r...@kallisti.us> wrote: > > Hi everyone, > > I have a multi-VRF CE setup that is used to provide a different > forwarding path for two groups of VLANs (one group has a layer 2 > firewall in front of it, the other does not). > > Each VRF has a physical interface uplinking to the global table and a > default pointing out of that interface. The global table uplinks to > the rest of the network and carries a full BGP view. All three tables > have an OSPF instance. I'm trying to move these routes out of OSPF > into iBGP, and IOS seems intent on foiling me. > > 1) There doesn't appear to be any BGP way to get a VRF route into the > global table as an IPv4 route. This makes some sense, as that's > basically asking to redistribute between address families - which > doesn't make any sense in most cases. > > 2) I've tried redistributing from a VRF OSPF instance into ipv4 > BGP, but IOS says no: > lab-6506.dc3(config)#router bgp 65000 > lab-6506.dc3(config-router)#redistribute ospf 2 > %VRF specified does not match this router > lab-6506.dc3(config-router)#redistribute ospf 2 vrf shared > %VRF specified does not match this router > Similar for other cross-VRF redistributions. > > 3) I've lab'd a config where I move everything into a VRF from the > global table, and then use PE-CEish eBGP to get the routes to the rest > of the network. This works, but the AS_PATH is wrong. I could use > as-override to fix this, but that isn't supported on the 6500 core > routers. > > 4) I tried to come up with a way to get the global table's OSPF > instance cut down appropriately, but most of the LSAs are type 5 since > we redistribute static routes. This prevents the goal of getting the > routes out of OSPF. > > 5) Manually duplicate every VRF static/connected route in the global > table and just do the usual redistribution of statics. This seems > like a very difficult config to keep in sync - about 3k prefixes with > occasional additions or updates. But it does actually work. > > Have I missed any options? #5 seems like the only thing that has any > hope of being correct, but man, that's a pain. I might be able to > live with #3, but I need to make sure that all of our tools will live > with the incorrect AS_PATH. > > Thanks, > Ross > > -- > Ross Vandegrift > r...@kallisti.us > > "If the fight gets hot, the songs get hotter. If the going gets tough, > the songs get tougher." > --Woody Guthrie > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAktEnfYACgkQMlMoONfO+HDNIgCgt3fTLm6coNVhSI3yxXpGB/b0 > fkAAn0z6IJEJbg6KxRI/XV4jBb+mkgwp > =TMwu > -----END PGP SIGNATURE----- > > _______________________________________________ > cisco-nsp mailing list cisco-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/