What Image of 3750 supports VRF lite?

Folks,
I want to implement VRF lite in my network, we have a bunch of 3750's in out network at the edge. Cisco doc says that 3750 support vrf lite, but i tried to download
Base
ip services
advanced service image
for the 3750, and i still do not see the VRF lite commands?
Any ideas?

According to the IOS Feature Navigator, any EMI image from 12.1(11)EA1 supports VRF lite.
Please refer to the following URL to access the IOS Feature Navigator:
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
Hope this helps,

Similar Messages

  • Does IOS XR support vrf lite?

    Am researching PE-CE configuration for a multiservice CE, using eBGP as the protocol. The XR fundermentals book describes this, but does not give an example of the CE configuration.
    I want to configure several sub-interfaces and alloacate to different VRF's, running vrf lite on CE. The sub-interface bit works fine. I cannot find which document describes vrf lite configuration, am using XR 4.3.0.
    does anyone have an example of how to set up an IOS XR ce with vrf lite they could share, using ebgp as the routing protocol?

    ok, I see that bit. So I set this up with sub-interfaces, assign each to a vrf. Works great!
    How do configure eBGP to act as the PE-CE routing protocol, it is that bit that I cannot get to work. I configured BGP, defined the vrf's under the BGP process, and then defined the neighbors under the BGP/VRF settings. The eBGP peerings all established, but no prefixes were received. And yes, I had an inbound/outbound route policy configured.
    will have another look later today at this, but any suggestions greatfully received.

  • What image on 3750 to support VOIP?

    i have a new 3750 switch that came with ipbase ios and i need an image to support voip. i looked for downloads on the cisco site but none of the image names told me which support voice. any ideas?
    thanks in advance.

    Hi
    Switches don't directly need to support any 'voice' features like routers do - they simply need to be able to run QoS, supply VVLAN info via CDP and so on.
    All these things are standard features on all images (Base, IPServices and Adv IP Services).
    The extra features in non-base feature sets are mainly to do with dynamic L3 routing.
    So, in short, your IPBase IOS is fine. If you want a different feature set the upgrade is licensed anyway so you should by a feature license (which is quite expensive).
    Regards
    Aaron
    Please rate helpful posts...

  • What image types are supported in iMovie?

    I'm going on a trip with a group of youth, and I'm wanting to send video updates back to their family members during the trip. I've gotten an image to sync to my iPhone 4, and I can import it into iMovie, but while it shows the photo at the bottom, it won't actually show the image in the movie preview area?
    Importing photos that were taking on the iPhone works, as does taking a photo directly from iMovie, but I want to add some special graphics into the Movie itself.
    Is there a way to tell what formats are supported? The image was made in gimp, 700x300 @ 150dpi exported as a PNG and as a JPG, but neither of them work.

    I'm not sure if you tried this, but here it goes:
    _ Using your Mac, make a copy of your Graphic / image to your Desktop
    _ Launch "Preview" on your Mac
    _ Save the file as a JPG
    _ Quit "Preview"
    _ Copy this newly saved JPG to "iPhoto"
    _ Quit "iPhoto"
    _ Launch "iTunes"
    _ Plug your iPhone4 via USB
    _ From "iTunes", select the iPhone4 and go to the Photos Tab.
    _ Make sure the Event or Album of the Graphics/iMage you created above, is Checked
    _ Sync your iPhone
    Now from your iPhone4, verify that you can add this photo into iMovie.

  • VRF-Lite versus VLANs at access edge

    What would be the advantage in using VRF-Lite at the CE (e.g. a 3750 switch) and trunking a series of /30 pt-pt VLANs (one for each VRF) from the PE to the CE switch, and then defining customer VLANs on the 3750 versus defining the customer VLANs on the PE device and simply trunking the customer VLANs down to the 3750 switch. In the latter scenario, the IP Services feature set would not be required on the 3750 as VRF-Lite would not be necessary at the edge; just VLAN separation, with IP routing disabled.
    A couple of possible benefits for using routed /30 links to the CE:
    (i) if the routing is complex at the CE site and more subnets need to be advertised towards the PE (i.e. it's more than a single VLAN);
    (ii) SP does not need to get involved in customer routing, but in a small Enterprise MPLS scenario, the customer and the provider may be one and the same, so may be less of an issue;
    (iii) A dual-homed CE device may need routes advertised towards two separate PEs.

    Hello Matthew,
    a multi VRF CE also known as VRF lite is a shared device: it can be partitioned between different customers reducing cost of ownership for each of them.
    It is typically owned and managed by a service provider.
    It can fit to multi-tenant office facilities.
    If yours is an enterprise scenario and the device is not going to be shared you can save some money making the C3750 a simple L2 switch and terminating all L3 interfaces on the PE itself.
    On the other hand a VRF lite CE can reduce the number of L3 interfaces that need to be defined on the PE providing a scalability advantage (every platform has a maximum number of interfaces supported regardless they are in VRF or in global routing table)
    Hope to help
    Giuseppe

  • 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.

  • What is VRF-Lite

    Can anyone explain what is the difference between VRF and VRF Lite. What is the main purpose/application of VRF Lite?
    Thanks in advance
    AK

    Vrf-lite is a leaner cut down version of MPLS-VRF.
    Where in MPLS-VRF you need labels for VPN traffic switching, you dont need labels in VRF-lite.
    VRF-lite mainly relies on routing using multiple virtual routing instances created for each vrf for switching traffic. There is no label switching for VRF-lite.
    Since there is no label switching, you need to populate VRF's on every hop on your network. For example |Lan--PE1---PE2---PE3--Lan|
    PE1 has 2 vrf's connected to a local lan, to route these VRF's to the other end(PE3), you will need to have dedicated interfaces(or subinterfaces on each hop and enable routing instances for each VRF on each hop.
    But with MPLS-VRF you need to just enable the VRF's on PE1 and PE3 with MPBGP and Label Switching enabled.
    So the advantage of VRF-Lite is to have virtualization of your sub-networks a smaller scale. If you have a big network, you may very well consider implementing MPLS (even though you may be an enterprise).
    HTH-Cheers,
    Swaroop

  • Using VRF-Lite in 6509 as Really Expensive IPS ByPass

    I have an IPS (Intrustion Prevention) unit that is causing me some problems with some of my servers in my ServerFarm. I would like to route most of my to/from ServerFarm traffic through the IPS, but use some policy-based routing with an ACL (preferably, a policy-based ACL) to allow some servers to bypass the IPS.
    So, I thought of taking my Cisco 6509 and making it into a Really Expensive Optical ByPass switch for this small group of servers. The challenge is that the IPS runs strictly at Layer 2. So if I connect the IPS in a loop to the 6509, I must change the MAC addresses on these interfaces on the 6509 so that each address is unique -- as well as assign unique IPs to each of the two interfaces, but the addresses must share the same L3 subnet. Of course, this leads to overlapping addresses on the 6509, which it does not like. So, I want to see if I can try a little VRF-lite to remove the overlapping address problem.
    To accomplish the bypass segment, I take a piece of fiber and just connect two ports together on the 6509, changing the MAC addresses and assigning the "overlapping" IPs (which is "solved" by placing the different ports in different VRFs, on just one port in the Global table and the other port in a standalone VRF). If I can do this without running this piece of fiber, I'd be welcome to the idea.
    I can fire up OSPF on all of my interfaces, raising the cost of the IPS Bypass link, and use the route-maps to try to route the Bypass traffic correctly. Unfortunately, the route-maps are not behaving. The traffic moves across the two links (one with IPS, one without) assymetrically, which isn't what I want.
    I am uploading a diagram that will show a simplified example of what I am doing. Here is my config below. Does anyone have any ideas on what I am doing wrong, or a better way to do this? (I tried a VACL approach, but I could not redirect the traffic properly):
    ip vrf Srv
    description ServerNets
    rd 65000:10
    object-group ip address IPS-Ignore
    host 192.168.20.2
    interface GigabitEthernet1/3
    ip address 192.168.200.1 255.255.255.0
    ip policy route-map ServerNetIngress
    interface GigabitEthernet1/9
    description ServerNets
    no ip address
    ip flow ingress
    interface GigabitEthernet1/9.20
    description PublicServerNet
    encapsulation dot1Q 20
    ip vrf forwarding Srv
    ip address 192.168.20.1 255.255.255.128
    ip flow ingress
    ip policy route-map ServerNetEgress
    interface GigabitEthernet1/15
    description IPS-ByPass-Global
    mac-address 0015.c7c9.c10f
    ip address 192.168.15.73 255.255.255.252
    ip flow ingress
    ip ospf cost 100
    interface GigabitEthernet1/17
    description IPS-ByPass-Srv-VRF
    mac-address 0015.c7c9.c111
    ip vrf forwarding Srv
    ip address 192.168.15.74 255.255.255.252
    ip flow ingress
    ip ospf cost 100
    interface GigabitEthernet1/19
    description IPS-Scrub-Global
    mac-address 0015.c7c9.c113
    ip address 10.0.0.2 255.255.255.252
    ip flow ingress
    interface GigabitEthernet1/21
    description IPS-Scrub-Srv-VRF
    mac-address 0015.c7c9.c115
    ip vrf forwarding Srv
    ip address 10.0.0.1 255.255.255.252
    ip flow ingress
    router ospf 10 vrf Srv
    router-id 192.168.10.1
    log-adjacency-changes
    capability vrf-lite
    network 192.168.0.0 0.0.255.255 area 0
    router ospf 1
    router-id 192.168.0.1
    log-adjacency-changes
    network 192.168.0.0 0.0.255.255 area 0
    ip access-list extended IPS-Bypass
    permit ip addrgroup IPS-Ignore any
    permit ip any addrgroup IPS-Ignore
    route-map ServerNetIngress permit 100
    description ByPassIPS
    match ip address IPS-Bypass
    set global
    set ip next-hop 192.168.15.74 10.0.0.1
    route-map ServerNetEgress permit 100
    description ByPassIPS
    match ip address IPS-Bypass
    set ip vrf Srv next-hop 192.168.15.73 10.0.0.2
    I obfuscated my addresses, so don't let that throw you off too much.
    Clarke Morledge
    College of William and Mary

    Thank you for the suggestion. Just using the "set ip next-hop" in the respective route-map is sufficient and gets the job done. Unfortunately, my problem is more with how the policy-based ACLs (PBACLs) work; i.e. the lines with the object-group syntax in the config. My contact with the TAC tells me that PBACLs are not really supported to do policy-based routing. So because the PBACL is not working correctly all of the time, things don't get matched properly in the route-map for the policy-based route to get correctly applied.
    This is really too bad since the PBACL looks to be a quite handy feature. In my example -- at least in theory -- I should be able to make but one change to the "object-group" in order to properly handle the policy-based routing involving the two different route-maps. Alas, this is not as easy as I hoped for since making changes to the PBACL apparently produces unpredictable results -- and the TAC just tells me that the feature is not supported for what I want to do.

  • Extending VRF-lite to 6500??

    Hello,
    I have a simple scenario, where there is a 6500 connected to a router (ISP end), which we have planned to implement vrf-lite on.... there are basically 2 VLANs on the LAN, one production and one guest... we need to isolate the routing table instances between the production and guest.. we have planned to configure trunk between the 6500 and PE router at the ISP end. 6500 acts as a CE here.
    Now, I want to extend the VRF information from the PE to the 6500 CE, since the layer 3 VLANs terminate on the 6500. i will define the same VRF information on the 6500 and isolate VRF routing tables for the guest/production vlan on the LAN also.. I know we will require to configure VRF, RD, BGP etc on the PE router and do a "ip vrf forwarding" on the subinterface of the router. What is the configuration required on the 6500 to extend the VRF-lite information to the end vlans ????? does anyone have any sample configs or links to which i can refer ?
    Raj

    Well,
    first a sample config (not from a 6500, but you should be able to get the idea):
    ip vrf Cust1
    rd 65000:1
    ip vrf Cust2
    rd 65000:2
    interface FastEthernet0/0.100
    encapsulation dot1Q 100
    ip vrf forwarding Cust1
    ip address 10.1.1.1 255.255.255.252
    interface FastEthernet0/0.200
    encapsulation dot1Q 200
    ip vrf forwarding Cust1
    ip address 10.1.2.1 255.255.255.252
    interface FastEthernet0/0.300
    encapsulation dot1Q 300
    ip vrf forwarding Cust2
    ip address 10.20.1.1 255.255.255.252
    interface FastEthernet0/0.333
    encapsulation dot1Q 333
    ip vrf forwarding Cust2
    ip address 10.1.1.1 255.255.255.252
    !On a 6500 you could also have:
    interface vlan 400
    ip vrf forwarding Cust2
    ip address 10.1.123.1 255.255.255.252
    router rip
    address-family ipv4 vrf Cust1
    version 2
    network 10.0.0.0
    no auto-summary
    exit-address-family
    address-family ipv4 vrf Cust2
    version 2
    network 10.0.0.0
    no auto-summary
    exit-address-family
    The separation in the control plane (routing etc.) is achieved through the normal VRF configuration. Overlapping IPs and such are supported by having separate IP routing tables per VRF and VRF aware routing protocols like RIP, OSPF, etc.
    In the data plane traffic is sorted by layer2 encapsulation. In the example above, the dot1Q VLAN tag will deliver the same functionality as the MPLS VPN labels. If f.e. an IP packet with destination 10.1.1.1 arrives, the VLAN tag 100 or 333 will allow the VRF-lite CE to determine, whether it belongs to Cust1 or Cust2. The same differentation will take place for traffic from the CE to the PE. So the PE config is practically the same, BUT in addition MP-BGP and route-targets and MPLS towards the core is used.
    So no MPLS is needed on the VRF-lite CE router, no labels will be used, hence VRF-lite.
    The PE will not be the PHP LSR in the MPLS sense, because it is the LAST router in the MPLS network.
    Instead of the FastEthernet also VLAN interfaces can be used. The number of interfaces per VRF or the number of VRFs are limited by memory.
    Hope this helps! Please use the rating system.
    Regards, Martin

  • 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

  • Need help on VRF lite

    I have implement VRF lite feature for one of the customer...it's working fine..But i m not so clear of following command ...........Can any one explane the same.
    router ospf 511 vrf abc
    capability vrf-lite <--------What is use of this command..is this is reletaed to BGP to OSPF redistribution..?

    Hi,
    VRF lite converts the router into multiple virtual routers each one with its separated routing table, interfaces and routing protocols.
    The OSPF Support for Multi-VRF on CE Routers feature provides the capability of suppressing provider edge (PE) checks that are needed to prevent loops when the PE is performing a mutual redistribution of packets between the OSPF and BGP protocols. When VPN routing and forward (VRF) is used on a router that is not a PE (that is, one that is not running BGP), the checks can be turned off to allow for correct population of the VRF routing table with routes to IP prefixes.
    When the OSPF process is associated with the VRF, several checks are performed when link-state advertisements (LSAs) are received. PE checks are needed to prevent loops when the PE is performing a mutual redistribution between OSPF and BGP interfaces. In some situations, performing PE checks might not be desirable. The concept of VRFs can be used on a router that is not a PE router (that is, a router that is not running BGP). With the capability vrf-lite command, the checks can be turned off to allow correct population of the VRF routing table with routes to IP prefixes.
    This command suppresses the Provider Edge (PE) specific checks on a router when the OSPF process is associated with the VRF.
    HTH, please do rate all helpful posts,
    Mohammed Mahmoud.

  • 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 limit on vrf-lite

    Hello guys. i am thinking of using vrf-lite on a CE for IP seperation but i want to know the limit of the number of VRF allowed when using vrf-lite (i am using a 7206 as CE)

    Theoritically yes, but you still will be constrained by how much memory you have in the router and the maximum number of interfaces (both physical and logical) or more accurately, IDB (interface descriptor blocks) supported by the IOS version. Different platforms and different IOS versions have different IDB limits. Every interface is allocated an IDB, either a hardware IDB (for phyical interfaces) or a software IDB (for logical interfaces ie. subinterfaces).
    IDBs consume memory as do routes, as do vrfs, as do different features you turn on.
    Also, IDBs, once allocated, the memory remains allocated until the router is reloaded. That is why subinterfaces aren't completely removed from the router until a reload when you delete them from the config.)
    Depending on the IOS version, you can use the "show idb" to see your IDB allocation on the box. Also, the following link talks about what IDBs are and limits per platform.
    http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_note09186a0080094322.shtml
    Jay

  • 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?

  • IP VRF-Lite

    Hi,
    we had a network with Cat4500 SupV as Core and Cat3750/Cat3750G (not metro!) as Distribution platform.
    I'm finding out if using VRF Lite is possible to separate two entities that use the same physical network and span the whole net to have one, max. two, contact point between these entities...to implement security policy
    Should this work with the platform we had or to implement a VRF network we should have had Cat6500 ???
    If this not work the only solution available is to use RACL at each Distribution node where there are both entitites to separate the traffic
    thanks for any help

    Hello,
    yes what you want to do is possible.
    You will need the "multi-VRF aka VRF lite" where IP routing is performed. So in case the Cat3750 are pure Layer2 switches the VRFs are not needed there.
    Think of a VRF as a sort of virtual router to which certain VLAN/ethernet interfaces are attached.
    To separate two entities you would create two VRFs in the Catalyst 4500 according to "Configuring VRF-lite"
    http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d03c.html#wp1062144
    and also in the Catalyst 3750 along the description in "Configuring Multi-VRF CE"
    http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_guide_chapter09186a00804764c7.html#wp1320198
    Note that there has being a name change from VRF-lite to Multy-VRF. This is however exactly the same feature - afaik marketing wanted the change because it sounds better.
    Did this help? Then please rate the post.
    Martin

Maybe you are looking for