Hi, I hope someone can help me or point me in the right direction for a possible solution here. I'm currently working on a solution to terminate a new MPLS network. The connection is VRF within BGP. There are two VRF's coming in via BGP. These two networks need to be separate when it comes to connectivity/routing on the end LAN networks. My device that terminates the provider MPLS connection is running BGP and the LAN's I will be connecting to both run OSPF. The device I am using to connect to the MPLS is a Cisco 3560X. The VRF's are both up and I can see routes etc. The setup is like this
ISP Device------>Cisco 3560X with BGP/OSPF------>Cisco 3560 Enhanced IOS------>LAN
This setup is identical for both VRF's, the only exception is the Cisco 3560 Enhanced IOS device will be physically different, there will be two of these, one for each network.
What I would like to do with each VRF is at some point break them out of the VRF and into the global routing table, I dont want to extend the VRF ideally beyond the Cisco 3560X device. If I need to extend the VRF into Cisco 3560 Enhanced I can do that, but from that device I really need to be redistributing my routes in to and from a global table/OSPF process. My reasoning behind this is that the LAN consists of a non Cisco devices running OSPF and given the scale of the network I'd rather not have to configure this for VRF, if I can leave it untouched then that would be my absolute preference!
I know this is goes against the basis of using VRF, but VRF is needed to traverse the MPLS links given the data involved, but when it comes onto both LAN's if I could possibly get each VRF into it's own, non VRF routing process that would be ideal. I had considered running BGP on my Cisco 3560 enhanced and making it a neighbor of the Cisco 3560X, then from the Cisco 3560 E, breaking out the routes into a standard OSPF process, I couldn't quite get this working.
Any help, advice, thoughts would be greatly appreciated.
>> This setup is identical for both VRF's, the only exception is the Cisco 3560 Enhanced IOS device will be physically different, there will be two of these, one for each network.
What you want to do is feasible and reasonable I would suggest you to post your configurations.
Generally speaking, you can use use OSPF between the C3560X multi VRF aware and each C3560E (not VRF aware global routing table) you should use a per VRF OSPF process on the C3560X.= all complexity on the C3560X.+ mutual redistribution of OSPF in VRF and BGP.
Also using eBGP between C3560X ( in VRF) to C3560E (global routing table) + BGP redistribution into OSPF in C3560E is possible.
You should use a different private AS number for the C3560E in order to have an eBGP session.
When redistributing into OSPF the keyword subnets is highly recommended.
You can use network commands in BGP to advertise OSPF subnets unless they are more then 200. This would avoid one redistribution from OSPF to BGP on the C3560E.
I'm having a couple of problems with this, I hope you can offer more advice. I have a single BGP process ID on the Cisco 3560X, in here there is an address family with the external/MPLS BGP neighbor for the VRF(I'm only bringing one VRF online just now). This VRF is working and I can see the external routes etc. If I try to create an eBGP relationship from the 3560X to my Cisco 3560E under this address family/VRF it doesn't seem to establish. If I move the eBGP relationship on the 3560X to 3560E from under address family on Cisco 3560X and directly under the router bgp 65xxx, then it establishes and I can see the routes advertised from my BGP process on the 3560E. Is it possible from a BGP address family to have a neighbor relationship and advertising/receiving advertisements from VRF and the same with a non VRF neighbor? My 3560E is just configured with a standard BGP AS and no mention of VRF.
Should I be establishing the eBGP relationship from under the 'global' BGP process on 3560X to 3560? If I do this, how do I get the routes from VRF to Global/Global to VRF.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...