Native Multi-VRF-Lite Design with EIGRP Question

Hello,
we think about to implement a VRF-Lite design (no MPLS and MBGP) in our campus network (10,000 ports, 20x 6500Sup720, 400x L2-Switches). MPLS is from our point of view oversized for our requirements. We need only a segmentation from different departments. Our IGP is eigrp.
In the latest IOS-Release for the cat6500 (12.2.18SXD) is finally a VRF-Lite support for EIGRP inside.
We could test successful a design with different VRFs in our lab, the division workes fine. But we didn't found a way to implement shared service. These are in our case DHCP, DNS, InternerAccess and some others. We thought about a redistribution between our global EIGRP routing table and the EIGRP-vrf tables, but we didn't found a way to do this.
How can we do this?
Thanks

Use a crossover cable to connect a port belonging to the global routing table to a port belonging to a VRF. This way you can leak EIGRP routes from the global routing table into the VRF (through that physical connection). The drawback is that you use 2 ports (that could instead be used for other things...).
Another way to this, would be to use static routing; use ip route vrf VRF x.x.x.x m.m.m.m n.n.n.n global to allow traffic to go from the VRF into the global routing table.
Hope that helps...

Similar Messages

  • What target address does IPM select if the target IPSLA device is a multi-VRF CE?

    What target address does IPM select if the target IPSLA device is a multi-VRF CE?
    With IPM 4.2.1 it is not possible to select the correct target IP address when configuring a collector between two multi-VRF devices. It looks as if the primary management address for the target device is used in the collector configuration which, of course, belongs in a different VRF entirely.

    One example, and there may be others, is the (free) DynDNS dynamic DNS service which publishes a domain name for the WAN port of your router which can then be resolved, like all other domain names, to the actual IP address of the WAn port of your router. This service provides a solution to the problem of having a proper domain name in cases where your public IP address changes over time. Unless you pay for a static IP address, virtually all ISPs change your public IP address over time.
    So, you can register for a free DynDNS account at www.dyndns.com and that is how you come up with the User: and Password: information; use whatever User and Password you register at dyndns.com with.
    The first part of the hostname you can define as you wish, subject only to someone else having used it previously, and the remaining parts of the domain name might be "dyndns.org" or one of the other domain names provided by the DynDNS service. So, you could publish, via DynDNS, the name of your public IP address as, for example, joehlam.dyndns.org however you might want something less descriptive or more vague.

  • VRF-Lite with 6500 w/ Sup720

    I am working with a customer who would like to utilize path isolation in their network using VRF-Lite. I am currently debating between the use of GRE tunnels vs. VLANs between 3 core switches they currently have in place today. This is going to be overlay network on top of what they currently have. The core is all L2 today with 802.1q trunks between each of 3 cores in a ring topology. Closets are single homed into the core throughout.
    My question is regarding GRE vs. VLANs. Currently, we are looking at having to deploy 12 VRFs to support 12 seperate network types they would like to isolate. The Access layer switches will trunk to the cores where the core will apply VRFs to specific VLANs based on their role.
    Which is going to be a more scalable solution from a performance and adminstration standpoint. GRE, VLANs, or MPLS?
    Currently the GRE implementation is going to require that we configure many loopbacks and tunnels on each core in order to get the VRFs talking to each other in each core. The VLAN approach will require 24 VLANs per core (assuming we would go with PTP vs Multipoint for routing inside the VRF).
    Any thoughts on which way to proceed? From what i have read GRE is more appropriate when you have multiple hops between VRF tables, which in this case we do not. I am just concerned with loopbacks,tunnels, and then routing on top of that the GRE solution will lack scalability as they add more VRFs. A PTP VLAN will pose a similar problem without the need for loopbacks which should simplify the solution.
    Can we use MPLS here and just do PE to PE MPLS and still get the VRF segmentation we need between cores?
    I would like eventually migrate the entire core to L3 completely but today we are stuck with having to support legacy networks (DEC/LAT/SNA) and have to keep some L2 in place.
    Whats the best approach here?

    Shine,
    I actually ended up with basically the same design you are talking about here except that I ended up adding a couple 6500 +FWSM and NAC L3/L2 CAM/CAS into the mix.
    Here is the high level overview
    1. Every Closet had a minimum of 6 VLANs - unique to the stack or closet switch - Subnets were created for each VLAN as well - no spanning of L2 VLANs across switch stacks.
    2. VLANs were assigned for - Voice, Data, LWAPP VLAN, Guest/Unauthorized, Switch/Device Management, and at least 1 special purpose VLAN - (Lab, Building Controls, Security, etc).
    3. Then we trunked all the VLANs back to 1 of 3 cores - 6509s with Sup-720s
    4. Each Core 6509 was configured for each L2 VLAN with a L3 SVI (The VLANs configured here were not configured on any other cores - we didn't have available fiber runs to do any type of redundant pathing across multiple cores so it wasn't valid in this design to configure VLAN SVIs on more than one core).
    5. Each L3 SVI was assigned to the appropriate VRF based on use - Voice, Data, LWAPP, etc
    6. Spanning-Tree Roots for all VLANs trunked to a core were specific to that core - they did not trunk between Cores - no loops
    7. Each Core was connected via a L2 Trunk that carried Point to Point VLANs for VRFs traffic - We had an EIGRP AS assigned to each VRF on the link - so we had 6 VRFs and 6 EIGRP AS per trunk.
    8. This design occurred on each core x2 as it connected to the other cores in a triangle core fashion.
    9. Each of the Cores had a trunk to to 6500 with a FWSM configured - VRF/L3 PTP VLAN design continued here as well
    10. The 6500+FWSM was configured with multiple SVIs and VRFs - we had to issue mult-vlan mode on the FWSM to get it to work.
    11. Layer 2 NAC was configured with VLAN translation coming into the Core 6500/FWSM for Wireless in L2 InBand Mode - the L3 SVIs were configured on the clean side of the NAC CAM so traffic was pulled through the CAM from from the dirty side - where the controller mapped host SSIDs to appropriate VLANs. We only had to configure a couple host VLANs here - Guest and Private so this was not much of an issue - Private was NAC enabled, Guest VLAN/SVI was mapped to a DMZ on the firewall
    12. For Layer 3 NAC we justed used an out of band CAM configurations with ACLs on the Unauthorized VLAN
    It worked like a charm.
    If I had to do it all over again I would go with MPLS/BGP for more scalability. Configuring trunks between the cores and then having the mulitple EIGRP AS/PTP VLANs works well in networks this small but it doesn't scale indefinately. It sounds like your network is quite large. I would look into MPLS between a set of at least 3-4 Core PE/CE devices. Do you plan on building a pure MPLS core for tagged switched traffic only? Is your campus and link make up significant enough to benefit from such a flexible design?

  • Multi-vrf CE/vrf lite Instances

    I'm currently looking at deploying vrf lite on our ce's but I'm unable to locate the limitations on how many instances can be run. I realise that the low-end ce's (1700, 2600) the limitation is 5 instances. Is there any other CE related devices that can run more instances, if so, how many and what devices?
    Regards
    Mark

    Hi,
    The 5 instances restriction comes from the "Designing MPLS Extensions for Customer Edge Routers" Product bulletin. The following script from that document is:
    Conclusions
    In order to ensure that their data is kept private while traveling across a Service Provider’s network, customers are presented many VPN options to suit their needs. This paper has focused on one particular type of VPNs: MPLS-VPNs. A general description was outlined for MPLS-VPNs in order to discuss the new feature in Cisco IOS release 12.2: Multi-VRF CE.
    Multi-VRF CE extends limited PE functionality to CE devices by allowing the traditional LAN network behind a CE router to be segmented into separate VRFs. With this feature, the CE router is now able to segment their LAN traffic into a maximum of 5 separate VRFs.
    So, I'm not sure whether this is just a standard feature set for all models, or this particular feature has been upgraded to support more vrfs, which as you say, will require the appropriate capacity.
    Regards
    Mark

  • Vrf-Lite with MPLS requires a PE at the customer side?

    Folks,
    Looking at a cisco doc, which gives a sample configuration of VRF lite with MPLS (multiple customers in the same building using same MPLS cloud). My question is that how is it done in the real world. Does the provider place a PE at the customer site? cause the connection between the CE and PE has to be a link that can carry dot1Q (ethernet or fast etheret) atleast the example shows that.
    Any real world experience would be highly appreciated.
    Thanks,

    Hi,
    the customer needs no PE router installed at his site.
    You can use vrf-lite (aka multi-vrf) even on a Cisco router, which does not support MPLS at all. On the CE each dot1Q subinterface can be placed in a vrf. All you need is a routing process started within the vrf being adjacent to the PE.
    Example CE:
    ip vrf CE-VRF1
    rd 65000:1
    interface FastEthernet0.100
    encapsualtion dot1Q 100
    ip vrf forwarding CE-VRF1
    ip address 10.1.1.1 255.255.255.0
    router ospf 100 vrf CE-VRF1
    network 10.1.1.1 0.0.0.0 area 1
    The PE would have MBGP and different RD and RTs defined, whatever is needed to setup VRFs in the provider network. Infact PE and CE each do not know about each others VRF configs at all.
    VRFs on the CE define a separate IP routing context (control plane). The separation on the data plane is done via dot1Q headers (frame-relay, ATM PVC etc. would do as well) on the link between CE and PE. In an MPLS network data plane separation is done via labels.
    Hope this helps
    Martin

  • Eigrp support for Vrf-lite on 3550 switches

    Folks,
    Cisco has added support for EIGRP for Vrf-lite on Sup 720's and Metro 3750 swithches. Just curious if anyone knows timeline when Cisco would be doing the same for 3550 series switches.
    Thanks

    No current plans at this time for EIGRP for Vrf-lite on 3550 since 3750 platform supports it. Contact your account team for feature request who can contact the business unit with a business case.

  • ZBFW design with vrf

    Hello,
    I am preparing a zbfw design with 400+ ISR/ASR remote  routers, Flexvpn and 1 vrf.  Each router has a tunnel for visitors and another tunnel for normal users. Config below. In the documentation, I read "All interfaces in a zone must belong to the same Virtual Routing and Forwarding (VRF) instance"
    There is no need to communicate between vrf visitor and the GRT, but both use the common wan zone on gigibit 0/0 and gigabit 0/2  to communicate to central.
    My question: Can I put all 4 tunnel interfaces below in the same zone :vpn ?
    ip vrf Visitors
    interface Tunnel1111
    description === FlexVPN to nrtc102 (DC1 AVC - primary line) ===
    ip unnumbered Loopback1
    ip mtu 1380
    ip tcp adjust-mss 1340
    tunnel source GigabitEthernet0/0
    tunnel destination 10.255.117.104
    tunnel protection ipsec profile Primary-line
    interface Tunnel1112
    description === FlexVPN to nrtc102 (DC1 AVC - Secondary line) ===
    ip unnumbered Loopback2
    ip mtu 1380
    ip tcp adjust-mss 1340
    tunnel source GigabitEthernet0/2
    tunnel destination 10.255.117.105
    tunnel protection ipsec profile Secondary-line
    interface Tunnel1113
    description === FlexVPN to nrtcDMZ (DC1 - visitors - primary line) ===
    ip vrf forwarding Visitors
    ip unnumbered Loopback3
    ip mtu 1380
    ip tcp adjust-mss 1340
    tunnel source GigabitEthernet0/0
    tunnel destination 10.255.112.104
    tunnel protection ipsec profile Primary-line-visitors
    interface Tunnel1114
    description === FlexVPN to nrtcDMZ (DC1 - visitors - Secondary line) ===
    ip vrf forwarding Visitors
    ip unnumbered Loopback4
    ip mtu 1380
    ip tcp adjust-mss 1340
    tunnel source GigabitEthernet0/2
    tunnel destination 10.255.112.105
    tunnel protection ipsec profile Secondary-line-visitorsinterface
    Many thanks Karien

    Hello Karien,
    Not sure I get the question..
    The definition you are looking I guess is this one:
    A router can only inspect inter-VRF traffic if traffic must enter or leave a VRF through an interface to cross to a different VRF. If traffic is routed directly to another VRF, there is no physical interface where a firewall policy can inspect traffic, so the router is unable to apply inspection.
    Based on that I would say that on each VRF there will need to be a dedicated security zone applied,
    I will try to run a lab real quick tomorrow and get back to u,
    Remember to rate all of the helpful posts. That's as important as a Thanks.
    Julio Carvajal Segura

  • Question to understand VRF and VRF-lite features

    Hi,
    when I look at METRO switches  Feature list I see that most of them support only "VRF-Lite".
    Does it mean that they can't work with MPLS lables and can't be placed as PE devices in cases  where we need VPN services or any kinf of "Lable-switching" services?
    Which role then does those METRO switches play in a network?

    Hello Konstantin,
    VRF lite is a subset of MPLS L3 VPN features missing MPLS forwarding plane capabilities.
    An end to end dedicated IP path is needed for each VRF, practically a VRF-lite capable device should be connected to a fully capable PE node by using a L2 trunk and dedicating at least two Vlan and two  SVI for each VRF: one towards customer and one towards PE.
    you get a multi VRF CE that can be shared by multiple customers
    a fully capable PE node uses N+1 links for N VRFs, a multiVRF CE requires 2*N logical interfaces for N VRFs
    only one MPLS enabled backbone link is needed for handling traffic of multiple VRFs in a fully capable PE node.
    in metro ethernet VRF lite multi VRF CE are used as feeders sort of satellite of PE nodes to provide an access layer to customers
    Hope to help
    Giuseppe

  • How many VRF-Lite Routing Instances can a 6509-E with a 720-Sup module run?

    I know that in a 4500 style switch it supports a maximum of 64 VRF-lite routing instances. However what is the maximum amount of VRF-Lite routing instances can a 6509-E switch support with a Sup-720 sup module?

    Sup 720  supports 1024 VRF Lites
    see table-1 in this link:
    http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/product_data_sheet09186a0080159856.html
    HTH

  • 3745 Multi VRF with modules ??

    Hi,
    Please anyone can tell wheather Gig modules are supported on 3745 and if yes then how many? Also please tell which is the Gig module I could not find on cisco.com.
    And also do the onboard LAN ports support Multi VRF function ?
    Thanks
    NK

    We use VRFLite with the onboard LAN ports and it works just as expected.
    hth
    -birgit

  • Multi-VRF CE with Private VLANs

    Does anyone know if you can implement a VRF instance on a private vlan? I would assume so, and will lab it out as time permits, but was curious if anyone had tried it/knows one way or the other.

    Since both the platforms support VRF lite and MPLS VPN, you can use Frame-Relay as the encapsulation for sub interfaces with local DLCI switching.
    As the VRF configuration is not media dependent.
    HTH-Cheers,
    Swaroop
    Router 1
    interface Serial0/0
    no ip address
    encapsulation frame-relay
    no keepalive
    !--- This command disables LMI processing.
    interface Serial0/0.1 point-to-point
    !--- A point-to-point subinterface has been created.
    ip address 172.16.120.105 255.255.255.0
    ip vrf forwarding xxx
    frame-relay interface-dlci 101
    !--- DLCI 101 has been assigned to this interface
    Router 2
    interface Serial0/0
    no ip address
    encapsulation frame-relay
    no keepalive
    !--- This command disables LMI processing.
    interface Serial0/0.1 point-to-point
    !--- A point-to-point subinterface has been created.
    ip vrf forwarding xxx
    ip address 172.16.120.120 255.255.255.0
    frame-relay interface-dlci 101
    !--- DLCI 101 has been assigned to this interface

  • OSFP - VRF-Lite - question

    Posted by: p.danielsen - Dec 27, 2006, 5:21am PST
    Hi,
    A brief VRF-Lite question, I want to build a redundant setup using VRF-Lite on some Catalyst6509's, where I want to use OSFP as the IGP, and redistribute it into BGP, for uplink to our edge..
    Some time ago, I heard that there where a limitation on the numbers of OSPF processes the could be used.
    I have around 50 VRF's that I want to convert,
    Any one know if this is a problem ?.
    Thanks in advance
    /Peter

    There is no hard limit on the number of OSPF instances you can have in a VRF context anymore. This limitation has been removed in 12.2(18)SXE.
    Hope this helps,

  • Multi-VRF CE or VRF-Lite support on 1800/2800

    Can anyone please confirm whether ISR 1800 and 2800 series devices support Multi-VRF CE functionality and which IOS release should be used?
    I could not find any document which is explicitly mentioning the above for the mentioned boxes.
    Actually my Purchase Order has been held up due to this... ;-)
    Thanks...

    Yes, they both do. For specific IOS version required, please refer to the Cisco IOS features navigator:
    http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
    Hope this helps,

  • VRF Lite running in the enterprise network

    Hello everybody
    Altough VRF lite (or Mulit VRF) seems to be a Service Provider Tecnology.
    Does it make sense to use it in an Enterprise Network to isolate Networks from others ?
    I cant find any design paper which describes if this would make sense.
    What do you think. Is someone using it ? Does Cisco recommend it ?

    Yes, VRF-lite SHOULD be used in an Enterprise environment to isolate the different security classes of devices.
    In the past you would isolate different groups of users using Layer1, i.e. separate hubs either totally isolated or connected together by a router with ACLs. Since the PCs were only connected at shared 10 Mbit and the routers were such low performance and worms weren't really prevalent, this was not a big security issue at the time.
    Then we migrated to VLANs, which essentially allowed Layer2 isolation within the same switch to provide the same functionality of separating different classes of users and to break up broadcast domains. Unfortunately, everyone connected the VLANs together at Layer3 with a router (or SVI) which essentially connected everything together again! And almost no one gets the ACLs right (if at all) to isolate the VLANs from each other. In fact, in most cases every VLAN can automatically reach every other VLAN from a Layer3 or IP perspective. This is a huge security problem.
    Enter VRF-lite, essentially created by Cisco as their tag switching migrated to standards based MPLS and had a need to isolate Layer3 security domains from each other within the same switch (or router). Think of VLANs for routing tables. VRF stands for 'Virtual Route Forwarding', which basically means separate routing tables. Since VRF-lite is a per-switch feature (running locally to the switch) you will need to use other technologies to connect multiple VRF-lite switches together and keep the traffic isolated, see below.
    What makes this so secure is that there is no command within the switch to connect different VRFs together within the same switch. You would need to connect a cable between two ports on the same switch configured in different VRFs to be able to communicate between them (recent IOS 12.2SR allows tunnels with different source VRFs but that is a corner case). The reason for this is simple, remember the basis for VRF (and VRF-lite) is for a service provider to isolate multiple customers from each other within the same switch. Just like an ATM, Frame-Relay, SONET, or Optical switch, the command line makes it very difficult (or impossible) to accidentally connect 2 different customers together.
    Think about that. Even if someone was able to get ssh enable access to your switch (you aren't running telnet anymore, right?!), they CAN'T connect 2 VRFs together with any command.
    And, yes, this is highly recommended by Cisco Engineers and is actually deployed far more than you think. I have VRF-lite running on at least 10 client's networks and those are LARGE networks. VRF-lite was integrated into the environment purely to solve a Layer3 security class isolation issue. I have used Layer3 dot1q trunks on c6500 switches and tunnels to keep isolated connectivity between VRFs between switches.
    In Cisco speak, VRF-lite falls under the topic of 'Path Isolation' which is combined with other features that isolate traffic within the same network such as dot1q trunking, tunneling, VPN, policy-routing, and MPLS. Do a search on Cisco's web site for 'path isolation' and you will find a bunch of info.
    See the following URLs for a good start:
    http://www.cisco.com/en/US/netsol/ns658/networking_solutions_design_guidances_list.html
    http://www.cisco.com/en/US/netsol/ns658/netbr0900aecd804a17db.html
    http://www.cisco.com/en/US/netsol/ns658/networking_solutions_white_paper0900aecd804a17c9.shtml
    As always, rate all posts appropriately, particularly those that provide value and don't be shy about following up with additional questions or comments.
    Good luck!

  • Multi-VRF on the same device

    Hi, I have a certain design that I am thinking of implementing however need some help to understand the feasability as well as confirm if it is indeed possible to do it. It is sort of like configuring multi-vrf on the same device and leak routes from them into a global routing table. It seems impractical to do it however if I want to limit connectivity between various vlan's on a L3 level without ACL's this seems the better option. Please do correct me if that is not so.
    Design
    A device which has a number of vlan interfaces on the north side let's say a 6500 configured with a number of vlan's. Each vlan has its own vrf. The SVI interfaces are where I apply the ip vrf forwarding XXX command. This device will be like the PE I assume?
    Now I might be running various routing protocols (EIGRP, RIP, Static, BGP) within these vrf's with the devices on the other end that have no idea about vrf's. Since I have a number of routes I have learnt within their own vrf's I want to either export all these routes into the global table or create a global vrf where I can export all these routes.
    The reason being that I want to propogate all these routes to the south side. The south side interface of this PE 6500 is physically connected to a firewall via a L3 point-to-point interface. That firewall's south interface in turns connects to another switch.
    I am going to form a BGP session with between the Top PE 6500 Switch and the bottom switch and I would like to propogate all the routes that I have in their own individual vrf's on the Top 6500 PE switch to the bottom switch via BGP.
    I don't think I can run MP-BGP due to the firewalls being in the physical path. Besides I would like to run a normal BGP IPv4 session between the top and bottom switch to keep it simple and familiar.
    The reason I would like to have every vlan in its own vrf is to limit connectivity between the vlan's without configuring ACL's. It provides a bit more security between the VLAN's.
    What I am not sure about is how the packet forwarding would work or if it would work at all.
    Thx for your help.

    Hi Vikram,
    Firstly, you mentioned that the reason for going down this path is for security between the different VLANs. Have you looked at Private VLANs as another option?
    Certainly leaking routes between different VRFs can be achieved and I would recommend having a 'Shared VRF' that you leak in and out of. Having the Firewall between the PE nodes does present an issue both for BGP as well as LDP peering if you wanted to establish a MP-BGP session. From what you have mentioned above, this solution might over-complicate what you are trying to do.
    Are the network ranges in each VLAN also unique?
    Can the Firewall run IGP? If so, maybe you could run Private VLANs and the use an IGP to propogate the networks through the FW across to your other switch? If you were to establish a BGP session between the switches each side of the FW, the FW would also need to either become a BGP peer or have IGP enabled. Each BGP node would then need to inject the BGP routes into IGP. If this isnt done, the FW will drop traffic as there would not be a suitable route.
    Are the resources through the FW shared or are they also client connected networks?
    Trent Husking

Maybe you are looking for