VRF basics

HI,
I was recommended to start using vrf's to separate networks defined on my switches but I am not sure what is the added value of using vrf's.
how is it different than having different vlans and controlling access with acl's? do all switches support vrf's?
we have many sites connected over a wan, is that a viable solution or vlans is ok as well?
if you know of some explanation and sample config i would love that.
thank you

Lo,
A VRF provides Layer3 speration. This is done by a creating seperate table per VRF to the global tables.
A VLAN provides layer2 seperation. A SVI is a layer3 interface for a VLAN on a given switch.
When one switch has two SVI's on the same switch the prefixes of the SVI's would be present in the same routing table. Depending how Gateway/routing was setup, routing (layer3) between the SVI is possible. To illustrate this, trying to configure two SVI with the same IP prefix will produce an error.
Where a VRF in the switching world might add benfit in certain designs, is by seperating the layer3 table on the same switch. Considering the above example where one switch has two SVIs configured, and each SVI is configured within its own VRF, The prefixes from the SVI would be contained in SEPERATE routing tables. Routing between the two VRFs (although still possible) is not native enabled. Now since there is Layer3 seperation the same IP prefix could be configured on both SVI's.
Lastly another difference between a VRF and a VLAN.
A VRF is local to a router/switch, where the membership of a VRF is determine by the input interface.
A VLAN is comunicated between device by encapsulating frame leaving the device. A VLAN membership is determined by the information in the encapsulation of the arriving frame.
Lastly to address the MPLS side. The VRF functionality operate indepently of MPLS. MPLS protocols leverage of a VRF for the mentioned seperation. VRFs are however mostly used in MPLS network, but not required by MPLS.
HTH

Similar Messages

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!

Back to Back VRF on same AS number possible?

Hi experts,
I am studying this B2B VRF thing and I built this lab and the diagram is attached.
Basically R101 should learn the prefix 123.123.123.10/32 on R10 through both VPNv4 and B2B VRF. Sorry if I am using the wrong terminology here but hopefully you can understand me...
So with only the VPNv4 peering ping works between R101 and R10 on their lo100 interfaces. R2 doesn't run BGP. It only handles labels. R4 is the RR. R101 and R3 build peering with R4.
However the B2B vrf setup doesn't work. R4 can't learn the prefix from R101. The peering between R1 and R101 on the B2B VRF setup is on directly connected interface, not through loopback 0 interfaces like other BGP VPNv4 peering. R1 learned the prefix 123.123.123.101/32 from R101 fine. It also advertised to R4.
Here are status on R1
R1#sho bgp vpnv4 unicast vrf TEST 123.123.123.101/32
BGP routing table entry for 65001:10:123.123.123.101/32, version 265
Paths: (1 available, best #1, table TEST)
Advertised to update-groups:
     1
Refresh Epoch 1
Local, (Received from a RR-client)
    172.20.0.2 from 172.20.0.2 (10.135.0.101)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:65002
      mpls labels in/out 26/nolabel
R1#sho bgp vpnv4 un all neighbors 10.135.0.4 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:10 (default for vrf TEST)
*>i 123.123.123.101/32
                       172.20.0.2               0    100      0 i
However R4 is getting this error with "debug bgp updates" turned on so it is not accepting it
*Jul 2 15:52:10.168: %BGP-3-INVALID_MPLS: Invalid MPLS label (15)
             received in update for prefix 59648:0:175864699:101.0.0.0/8 from 10.135.0.1
Please note that the number 175864699 is actually A7B7B7B and 7B is 123. I have a feeling that the R4 is interpreted it incorrectly so it doesn't recognize the prefix. Is it because the B2B VRF setup won't work with iBGP peering?
Thanks!

That doesn't do it.
I have used the page up key to skip back to the top, but why should we have to do that when most other forums I post on have a "to the top" button?
It is a little thing, but when they can't even keep the darn servers in sync, or even up at all for that matter, it seems huge.

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

Vrf routes into global route table

Dear All
I am stuck with a design I am trying to come up with for our EDGE network and looking for ideas from the community.
It is similar to what is described here:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/ServEdge.html#wp86450http://www.cisco.com/en/US/docs/solutions/Enterprise/Network_Virtualization/ServEdge.html#wp86904
In short we have a multi-context FWSM at 2 sites creating an EDGE network, each site operate independently. The sites are linked internally in a single routing domain using OSPF. Each of the outside networks are in seperate VRFs, single-tier model.
I need to find a way to:
1) link the 2 sites (currently is done with a GRE tunnel between the site vrfs, looking at replacing this with mp-bgp and l3vpn encapsulation)
2) redistribute routes from each of the vrf into the common global route table (running ospf)
1 is working nicely with mp-BGP peer between the sites and routes distributed between, however I am stuck on how to achieve 2.
The only way I can see is to change the global route table to a vrf, then use rt import/export. This is commonly described as shared services. When I did that I got stuck with how to do the BGP peering as the loopback I was using for the peering is inside the new vrf.
Basically I want dynamic routing from the global route table to learn routes from each of the sites vrf. Then if a particular site's vrf is unavailable, it can pick up the other site's route.
Am I missing something here? The document linked makes it sound incredibly easy yet I am struggling with how to implement it.
Any advice is much appreciated

Hello philip,
It is really hard to help you, if you do not provide topology where you would like to implement these changes, so just some thoughts to your points:
2) redistribute routes from each of the vrf into the common global route table (running ospf)
You can use PE - CE design. VRFs are terminated on PE with all routes you need in respective VRFs. On PE, MP-BGP routes are redistributed into respective VRF's OSPF process . PE is connected with CE via separate physical interface for each VRF or you can use one physical interface with dedicated sub-interface for each VRF. PE is peering with CE using OSPF. All routes end up in CE global routing table.
Problems with this design ->
- for each VRF you have to create separate OSPF process on PE and CE, also OSPF process ID has to be unique on PE for each VRF. Also OSPF process ID has to match to establish OSPF neighborship between PE-CE, so on CE you will have to redistribute OSPF routes from each process to your main OSPF process.
other workarounds ->
1) instead OSPF you will use as peering protocol BGP between PE-CE, but you still have to redistribute BGP routes to OSPF on CE
2) you will use different PE to redistribute each VRF -> BGP routes will be redistributed from VRF into OSPF (same process ID as your main OSPF ID). Routes will be advertised via OSPF into CE global routing table.
You will use on PE per VRF to redistribute routes into OSPF with same process ID as your main process ID. Thanks to different PEs, you can have same OSPF process ID, all these PEs will peer with same CE via OSPF.
I hope I made my thoughts understandable, cause its quite hard to explain
When I did that I got stuck with how to do the BGP peering as the loopback I was using for the peering is inside the new vrf.
This should not be a problem. You can have same IP on all VRF and also global table, so peering can still be done. After BGP routes are exchanged you can leak prefixes from one vrf to another or into global table as you need.
Best Regards
Please rate all helpful posts and close solved questions

What is vrf

hi,
can any one tell me what is VRF(virtual routeing and forwarding) ,how its works
Regards,
vishal

Hello Vishal,
Virtual Routing and Forwarding (VRF) is an IP technology that allows multiple instances of a routing table to co-exist on the same router at the same time. Because the routing instances are independent, the
same or overlapping IP addresses can be used without conflict. “VRF” is also used to refer to a routing table instance that can exist in one or multiple instances per each VPN on a Provider Edge (PE) router.
Basically you can have n number of customers and have each customer assigned a VRF with a unique RD. This will create a seperate instance for routing. The benefit for creating VRF would be you can over lapping IP address for your end customers. Internet service providers (ISPs) often take advantage of VRF to create separate virtual private networks (VPNs) for customers; thus the technology is also referred to as VPN routing and forwarding. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other.
HTH,
Nikhil

Leaking subscribers between VRFs

Hi,
I have two VRFs, lets call them internet, and customers_1.
PPPoE, and IPoE subscribers terminate in the customers_1 VRF, I am wanting to leak these addresses into the internet vrf.
I have configured the relevant import and export statements, and see the routes, however the routes are advertised into the internet vrf with a next hop of 0.0.0.0 thus, they do not appear in CEF (seen via sh cef vrf interent), and traffic is not forwarded.
Can anyone let me know how I would achieve this.
here is the customer_1 vrf routing table (partial):
B    3.3.3.0/24 [200/0] via 202.74.33.249 (nexthop in vrf internet), 00:00:08
B    4.4.4.0/24 [200/0] via 202.74.33.249 (nexthop in vrf internet), 00:00:08
S    100.64.0.0/12 is directly connected, 01:11:20, Null0
C    100.64.0.0/17 is directly connected, 1w3d, Loopback2
L    100.64.0.1/32 is directly connected, 1w3d, Loopback2
A   100.64.0.99/32 is directly connected, 1w1d, Bundle-Ether100.1.ip8
B    103.241.56.0/22 [200/0] via 202.74.33.249 (nexthop in vrf internet), 00:00:08
A    116.251.122.4/32 is directly connected, 1w1d, Bundle-Ether100.1.pppoe5
A    116.251.193.254/32 is directly connected, 1w1d, Bundle-Ether100.1.ip7
here is the internet vrf rotuing table (partial)
B    3.3.3.0/24 [200/0] via 202.74.33.249, 00:00:02
B    4.4.4.0/24 [200/0] via 202.74.33.249, 00:00:02
B    100.64.0.99/32 [200/0] via 0.0.0.0 (nexthop in vrf customers_1), 00:47:47, Bundle-Ether100.1.ip8
B    116.251.122.4/32 [200/0] via 0.0.0.0 (nexthop in vrf customers_1), 00:47:47, Bundle-Ether100.1.pppoe5
B    116.251.128.0/18 [200/0] via 202.74.33.249, 00:00:02
B    116.251.192.0/21 [200/0] via 202.74.33.249, 00:00:02
B    116.251.193.254/32 [200/0] via 0.0.0.0 (nexthop in vrf customers_1), 00:47:47, Bundle-Ether100.1.ip7
B    202.74.33.58/32 is directly connected, 00:44:45, Loopback1 (nexthop in vrf customers_1)
the follwoing are the vrf export/import statements - i have no route-maps yet, as am just trying to get basic connectivity going first.
vrf internet
address-family ipv4 unicast
import route-target
   65536:200
   65536:100
export route-target
   65536:200
vrf customers_1
address-family ipv4 unicast
import route-target
   65536:200
   65536:100
export route-target
   65536:100
in BGP i have for the customers vrf:
vrf customers_1
rd 65536:100
address-family ipv4 unicast
   redistribute ospf customers_1 match internal external
   redistribute subscriber
many thanks,
mike

Mike,
I do not have other alternative solutions, the only one i can suggest is by using Access-list forwarding (ABF) on incoming interface from internet. The good thing about this is that you can have one ACE for pool of your customer's ip address. Put summarized destination address and point to the VRF as the destination. It is called ABF VRF select. This cause the ingress packet from internet with destination of vrf customers_1 ip address will be forwarded using VRF customers_1.
regards,
rivalino

Convert HDLC T-1 to sub-if to configure multi-vrf CE

We are converting a small ISP to MPLS and have a quick question-
We have several sites connected using a basic HDLC T-1 from what is going to be the CE to the PE (all isr's running 12.4)
Over this one link we will have MPLS (with the PE's side being in a vrf), and we would like to continue bringing in internet from the PE's global routing table that we are doing now.
I know you can simply use frame relay with sub-interfaces to do this... only we cant provision frame-relay service to these CE's...
Any ideas how we could segment these HDLC's into 2 sub-interfaces (one with private addressing for the MPLS wan) and one with public ip addressing for the internet circuit.
I've been thinking about gre 2 tunnels between the PE/CE just to make this work, with one TUNNEL being in the PE's VRF for the customer, the other remaining in the global routing table.
Oh, and I know you can just route the internet into the VRF on the PE, but that is not desirable here.
Thanks,
Joe

I would say you need to use VRF-lite in order to do this efficiently.
All other solutions will require tunnelling which is not efficient.
One possibility is to have a single site that has the routes to the Internet i.e. a central DC site. This would mean that a default route would take all internet bound traffic to the DC whereby it will be routed to an 'Internet' circuit. This is a common method and usually involves a MPLS L2Transport circuit into the DC site which terminates between an Internet router and a CE/Fw. This will require a L2 protocol that can deliver discreet L2 paths i.e. FR or Ethernet VLANs. The advantage is reduced tunnelling but introduces suboptimal/hairpin routing.
An alternative is L2TPv3 from each CE to an Internet CE

No route after Interface change in VRF

Hi Everyone,
I have had a couple of strange incidents where changing a physical interface or ip address on an interface causes routing problems. We are running ASR9010 on IOS-XR 4.2.3
Case 1:
Changed a physical interface gi0/0/0/1.12 to BE21.12 on a vrf.
I lost static routes and had to remove and re-apply.
Case2:
Changed the IP address to a different network 172.17.254.126/27 to 172.27.254.126/27
ARP OK and ping from VRF or local device in other VRF OK, however host on connected interface cannot be pinged from across MPLS. Connected route is carried across MPLS OK. We will be trying to remove the entire interface and vrf config and re-apply.
EDIT: We re-applied config after removing and commiting. It is now working.
Any ideas or clues?
Cheers
Mike

Thanks,
The basic thing for case 2 is:
Customer --> VRF Gateway- Ping OK
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#ping vrf BACKUP-MANAGEMENT 172.27.254.99
Fri Feb 14 12:42:49.771 EST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.27.254.99, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Server --> MPLS --> VRF Gateway - Ping OK
> ping routing-instance BACKUP_SERVERS 172.27.254.126
PING 172.27.254.126 (172.27.254.126): 56 data bytes
64 bytes from 172.27.254.126: icmp_seq=0 ttl=255 time=1.126 ms
64 bytes from 172.27.254.126: icmp_seq=1 ttl=255 time=1.029 ms
64 bytes from 172.27.254.126: icmp_seq=2 ttl=255 time=1.097 ms
64 bytes from 172.27.254.126: icmp_seq=3 ttl=255 time=0.998 ms
64 bytes from 172.27.254.126: icmp_seq=4 ttl=255 time=1.032 ms
^C
--- 172.27.254.126 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.998/1.056/1.126/0.047 ms
Server --> MPLS --> VRF --> Customer - Destination Unreachable
> ping routing-instance BACKUP_SERVERS 172.27.254.99
PING 172.27.254.99 (172.27.254.99): 56 data bytes
76 bytes from 124.47.128.30: Destination Net Unreachable
Vr HL TOS Len   ID Flg off TTL Pro cks      Src      Dst
4 5 00 0054 940d   0 0000 40 01 3404 172.28.91.252 172.27.254.99
76 bytes from 124.47.128.30: Destination Net Unreachable
Vr HL TOS Len   ID Flg off TTL Pro cks      Src      Dst
4 5 00 0054 a361   0 0000 40 01 24b0 172.28.91.252 172.27.254.99
76 bytes from 124.47.128.30: Destination Net Unreachable
Vr HL TOS Len   ID Flg off TTL Pro cks      Src      Dst
4 5 00 0054 a8ae   0 0000 40 01 1f63 172.28.91.252 172.27.254.99
76 bytes from 124.47.128.30: Destination Net Unreachable
Vr HL TOS Len   ID Flg off TTL Pro cks      Src      Dst
4 5 00 0054 ad11   0 0000 40 01 1b00 172.28.91.252 172.27.254.99
76 bytes from 124.47.128.30: Destination Net Unreachable
Vr HL TOS Len   ID Flg off TTL Pro cks      Src      Dst
4 5 00 0054 b5ab   0 0000 40 01 1266 172.28.91.252 172.27.254.99
--- 172.27.254.99 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#ping vrf BACKUP-MANAGEMENT 172.27.254.99
Fri Feb 14 12:42:49.771 EST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.27.254.99, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#    sh arp vrf M2MGMT23509001
Fri Feb 14 12:56:57.313 EST
0/1/CPU0
Address         Age        Hardware Addr   State      Type Interface
172.27.254.99   00:14:08   0050.5682.66c0 Dynamic    ARPA Bundle-Ether2.12
172.27.254.124 03:08:07   0050.5682.565c Dynamic    ARPA Bundle-Ether2.12
172.27.254.126 -          6c9c.ed03.8eb2 Interface ARPA Bundle-Ether2.12
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#    sh arp vrf M2MGMT23509001
Fri Feb 14 12:57:25.328 EST
VRF Gateway --> MPLS --> Server - Ping OK
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#ping vrf M2MGMT23509001 172.28.91.19
Fri Feb 14 13:00:13.402 EST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.28.91.19, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#sh run router bgp 17477 vrf M2MGMT23509001
Fri Feb 14 13:02:11.425 EST
router bgp 17477
vrf M2MGMT23509001
rd auto
label-allocation-mode per-vrf
address-family ipv4 unicast
   redistribute connected
RP/0/RSP0/CPU0:macq-syd-intel2-asr9010-01#sho route vrf M2MGMT23509001
Fri Feb 14 13:03:46.700 EST
Codes: C - connected, S - static, R - RIP, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G - DAGR
       A - access/subscriber, - FRR Backup path
Gateway of last resort is not set
B    10.117.24.0/23 [20/0] via 172.27.0.110 (nexthop in vrf BACKUP-MANAGEMENT), 1d01h
B    10.135.0.0/24 [20/0] via 172.27.0.110 (nexthop in vrf BACKUP-MANAGEMENT), 1d01h
B    10.135.2.0/24 [20/0] via 172.27.0.110 (nexthop in vrf BACKUP-MANAGEMENT), 1d01h
C    172.27.254.96/27 is directly connected, 2d02h, Bundle-Ether2.12
L    172.27.254.126/32 is directly connected, 2d02h, Bundle-Ether2.12
B    172.28.1.240/28 [200/0] via 125.7.35.120 (nexthop in vrf default), 6d22h
B    172.28.91.0/24 [200/0] via 125.7.35.120 (nexthop in vrf default), 6d22h
B    172.28.92.0/24 is directly connected, 1d01h, Bundle-Ether4 (nexthop in vrf BACKUP-SERVER)

FlexVPN with F-VRF and multiple tunnels

Hi There,
I have a burning question and initially need to understand the possibility of the following scenario, below is a diagram of a single point-to-point connection used for proof of concept. The Hub router acts as a local RADIUS and is to issue IP addresses for both the client tunnel interfaces.
Two separate tunnels are required, one between Virtual-template 1 and tunnel 1 and one between Virtual-template 2 and tunnel 2, hence they are within a separate VRF on both routers.
Basically I am wondering if this is possible as getting this to work is a struggle.. I am currently using PSK authentication, though also wondering if there would be issues using certificates, i.e. the hub would effectively receive two separate SAs with the same certificate.
The flex client and hub have separate profiles keyrings etc for each connection...
Has anyone got this working before??
Any help or suggestions/pitfalls would be appreciated.

Hi Olpeleri,
Many thx for the reply,
I have tried using two interfaces on the Hub, though no joy so far..... I want to have the hub tunnel end points in different VRFs, hence I have tried with two virtual templates A and B and interfaces A and B in different VRFs to each other.
i.e, looking at just one tunnel to start with,
HUB
interface Virtual-Template1 type tunnel
ip vrf forwarding VRF_A
ip unnumbered Loopback20
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE
end
interface e0/0
ip vrf forwarding VRF_A
ip address 172.16.0.2 255.255.255.0
Is this config correct, I have tried using a front door VRF for each interface also, though the tunnel fails to build when both interfaces are there
The profile looks like this repeated for each interface with different names and virtual template etc..
crypto ikev2 profile default
match fvrf any
match identity remote fqdn domain cisco.com
identity local fqdn Hub1.cisco.com
authentication remote pre-share
authentication local pre-share
keyring ALL
pki trustpoint cisco
dpd 10 2 periodic
aaa authorization group psk AUTHOR_LIST AUTHOR_POL
virtual-template 1
Thanks,

Multi-VRF

Hi.
I intend to understand what a multi-vrf is, but the bottm line is, I don't seem to understand them very well.
I was asked about it and I was surprised that I was not able to find an easy way to explain them.
If you are to explain what a multi-vrf is, how would you do it?
What are the basic ups and downs?
Thanks

Hello Jayson,
a Multi-VRF CE is a device that has multiple VRFs and is shared between different customers and is generally owned and managed by the service provider.
From a technical point of view the multi-VRF CE has a subset of the features of an MPLS PE.
It has the capability to segregate traffic of different customers and to support address overlapping but:
there is no support of MPLS forwarding so there are only VRF access links both to the customer both to the real MPLS PE.
There is no support/need of the MP-BGP for address-family Vpnv4.
The uplink is usually made with an high speed 802.1Q trunk where each vlan carried is mapped to a different VRF/Customer.
The customer benefits are the sharing of the CE device and of the high speed uplink(s).
Scalability is the issue in comparison with a real PE:
a PE with N VRFs can use N+1 interfaces (N access links + 1 MPLS backbone link)
a multi VRF CE with N VRFs needs 2*N interfaces (for each VRF one link towards the customer and one towards the SP PE)
The same is true for the routing relationships: on each VRF a different routing relationship exist with PE (it can be eBGP in VRF or IGP OSPF or EIGRP in VRF) while a real PE has one/two BGP relationships with the RRS and this is enough for all defined VRFs.
Often a Multi-VRF CE is a multilayer switch that can offer high port density at a cheap price.
Hope to help
Giuseppe

MPLS / VRF

Hello,
how is it possible that VRF can be routed from one site to another site by the core routers?
It is clear that the VRF must be configured and each interface is to be assigned.
In addition, the IGP / redistribution between PE-CE and MP-BGP is to be configured.
I found the following configurations in the documentation to configure the PE-Routers in the Core:
(Configuring MP-BGP):
PE 1:
router bgp 1
x.x.x.x neighbor remote-as 1
x.x.x.x neighbor update-source loopback0
address-family vpnv4
neighbor x.x.x.x activate
x.x.x.x neighbor send-community Both
exit-address family
PE 2:
router bgp 1
x.x.x.x neighbor remote-as 1
x.x.x.x neighbor update-source loopback0
address-family vpnv4
neighbor x.x.x.x activate
x.x.x.x neighbor send-community Both
exit-address family
What additional commands are required that a router from one location can ping a router to another location in the same VRF successful?
Thanks for your help!

Hello,
From the above configuration it looks like that you have configured MP-BGP. This is important for VRF to VRF communication over MPLS enabled backbone (MPLS VPN) since MP-BGP propagates virtual routing and forwarding (VRF) reachability information to all members of a VPN community. MP-BGP peering must be configured on all PE devices within a VPN community.
Below are 2 links which clearly suggests what all things are required for VRF to VRF communication and reason for it.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-bgp-mpls-vpn.html
http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/13733-mpls-vpn-basic.html
HTH,
Nikhil

Simple VRF+BGP lab not working

I have set up a simple lab:
router A - 7200 IOS 12.2(27) JS
router B - 2611
There is a serial link between A and B.
On A the serial interface is in VRF.
The B router has no VRF - just ordinary IP.
I am trying to set up eBGP between them.
But the session does not start.
The A config:
ip vrf v2
rd 7:2
route-target export 7:2
route-target import 7:2
ip cef
interface Serial2/0
ip vrf forwarding v2
ip address 192.168.25.5 255.255.255.0
router bgp 65005
no synchronization
bgp log-neighbor-changes
no auto-summary
address-family ipv4 vrf v2
neighbor 192.168.25.2 remote-as 2
neighbor 192.168.25.2 activate
no auto-summary
no synchronization
network 192.168.6.0
exit-address-family
I have done some tests:
Ping from B to A works.
Ping vrf from A to B works as well.
telnet from B to A on port 179 gets RST.
telnet /vrf from A to B on port 179 works.
Debug on B shows session establishment attempts, but
with TCP RST response.
Debug on A shows the neighbor is Idle - no attempts.
On A:
sh ip bgp nei
BGP neighbor is 192.168.25.2, vrf v2, remote AS 2, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle
Last read 02:03:54, hold time is 180, keepalive interval is 60 seconds
Connections established 0; dropped 0
Last reset never
No active TCP connection
I know, that I am new to the VRF stuff, but it is very basic case. What am I doing wrong?
Michal

I have solved the problem.
The keyword is "bgp router-id".
I had no "normal" interfaces, all were VRF ones.
IOS apparently uses by default only IP address
from "normal" interface as a bgp router ID, so:
#sh ip bgp vpnv4 vrf v2
BGP table version is 1, local router ID is 0.0.0.0
As I have forced the ID (bgp router-id ...) all the sessions got up.
Interesting case.

Deny traffic by vrf - acl?

Hello,
I have a service provider network with multiple public vrfs and some private vpns also. We liked the design of this it seemed to keep the public routing completely separate from the core routing. However it seems there is an awkward do to shut, as if we set a public addressed sub-interface for a customer ssh access is available. We want to keep ssh access around out network, so have filtered out who can access using acl on the vty, say to 10.x.x.x
However we also have some private vpns, so I could quite easily set 10.x.x.x addressing which would allow people to attempt ssh access.
So basically, what is the best way to completely drop all telnet/ssh access to sub-interfaces on a per vrf basis, i.e. if you are in this vrf, regardless of IP, you cannot ever see telnet/ssh ports filtered/closed or otherwise?
Many thanks
Nicholas

Hello,
Many thanks for the reply. Unfortunately this will restrict telnet through the interface - we want to allow our customers to use any application through our router. So we can do:
10 deny tcp any 10.x.x.x eq telnet
20 permit ip any any
And apply this to the interface. However if we give a customer a couple of private vpn to route between, we need a sub-interface which could overlap with this address, so be of security interest, and also presumably is open to spoofing.
What I am looking for, if it exists, is to completely disable telnet/ssh services on an interface, not necessarily by ip access list.
Many thanks
nicholas

Some basic problems with multicast, IGMP & NLB

Hi out there
We have two DC's with 10G interconnection in between - these connections are run as L2 links - put into a set of nexus 5000 (the old nx5020) - acting access-switches - and uplinked to a set of nexus 7009 which act as L3 switch for us.
We have a cluster of vmware boxes in each site and are running MS windows 2008 machines with MS NLB for TerminalServices - in IGMP multicast mode - in VLAN 21.
Now I looked in the log of the nexus 7000 and found that the PIM DR is "flapping" between the two sites from time to time:
2013 Nov 25 22:50:58 ve-coresw-01 %PIM-5-DR_CHANGE: pim [26128] DR change from 172.21.159.253 to 172.21.144.3 on interface Vlan21
2013 Nov 25 22:51:54 ve-coresw-01 %PIM-5-DR_CHANGE: pim [26128] DR change from 172.21.144.3 to 172.21.159.253 on interface Vlan21
2013 Nov 25 23:26:07 ve-coresw-01 %PIM-5-DR_CHANGE: pim [26128] DR change from 172.21.159.253 to 172.21.144.3 on interface Vlan21
2013 Nov 25 23:26:10 ve-coresw-01 %PIM-5-DR_CHANGE: pim [26128] DR change from 172.21.144.3 to 172.21.159.253 on interface Vlan21
I am not that familiar with multicast but the basic concepts are there - in the vrf I have defined
ip pim ssm range 232.0.0.0/8
the vlan is defined as:
vlan configuration 21
layer-2 multicast lookup mac
vlan 2001
under the SVI interface vlan 21 I have also defined - and there is a sample showning the nlb
interface Vlan21
vrf member DMZ_21
no ip redirects
ip address 172.21.144.3/20
ip pim sparse-mode
ip arp 172.21.149.19 0100.5E7F.9513
these flapping should only occur if the keep-alives between the two sites are missed 3 times
The uplinks to the nexus 5000 are defined as mrouters
vlan 21
ip igmp snooping mrouter interface port-channel5
ip igmp snooping mrouter interface port-channel16
SW5020-01# sh ip igmp snooping vl 21
IGMP Snooping information for vlan 21
IGMP snooping enabled
IGMP querier present, address: 172.21.144.3, version: 2, interface port-channel5 -> the DR on the nx7k
Switch-querier disabled
IGMPv3 Explicit tracking enabled
IGMPv2 Fast leave disabled
IGMPv1/v2 Report suppression enabled
IGMPv3 Report suppression disabled
Link Local Groups suppression enabled
Router port detection using PIM Hellos, IGMP Queries
Number of router-ports: 3
Number of groups: 3
VLAN vPC function enabled
Active ports:
    Po10        Po15    Eth1/3 Eth1/11
    Eth1/12     Eth1/13 Eth1/14 Eth1/15
    Eth1/16     Eth1/17 Eth1/18 Eth1/19
    Eth1/20     Eth1/25 Eth1/26 Eth1/27
    Eth1/28     Eth1/29 Eth1/30 Eth1/31
    Eth1/32     Po16    Po5
The link between the two sites - and boxes - is running error-free. As far as I can see there hasn't been any problems in that vlan since ??
If I look at f.ex spanning-tree the topology hast changed for long time in that vlan (2 weeks).
Could I harden the igmp multicast setup?
What is happening when a DR is changing? Will the multicast stop work or what happens?
As far as I understood the DR is the service which forwards the multicast traffic to the groups so if suddenly some re-negotiation occurs I would expect that the active traffic will be interrupted.
here the actual MS NLB clusters adresses:
SW5020-01# sh ip igmp snooping groups vl 21
Type: S - Static, D - Dynamic, R - Router port
Vlan Group Address      Ver Type Port list
21 */*                -    R     Po10 Po16 Po5
21 239.255.149.19     v1   D     Eth1/14 Eth1/19 Eth1/32
21 239.255.149.24     v1   D     Eth1/12 Eth1/15 Eth1/16
                                    Eth1/26 Eth1/31
21 239.255.255.250    v2   D     Po15 Eth1/11 Eth1/28
                                    Eth1/29
SW5020-01#
Any suggeestions?

What Is OneClickStarter.exe?
OneClickStarter.exe is a type of EXE file associated with TuneUp Utilities 2013 developed by AVG Technologies for the Windows Operating System. The latest known version of OneClickStarter.exe is 13.0.4000.189, which was produced for Windows.
This EXE file carries a popularity rating of 1 stars and a security rating of "UNKNOWN".
Sounds like you have some misbehaving software on your system. I would suggest a clean install to see if you still have all the problems you are reporting.

VRF basics

Similar Messages

Maybe you are looking for