12-02-2011 03:41 AM - edited 03-04-2019 02:29 PM
Hello,
how to route between vrf interface and non vrf interface? BGP is active on non vrf interface, OSPF on vrf interface. Need that LAN, which is under "vrf local" should be able to reach outside network (non vrf) and vice versa. Please be free to ask more details.
Thank you.
12-02-2011 03:55 AM
Topology is this: http://donatas.net/vrf-to-non-vrf.jpg
Everything works if I use BGP in vrf global and vrf global is imported in vrf local. If I migrate vrf global BGP session to non-vrf everything goes down.
12-02-2011 06:05 AM
Donatas,
Would you mind posting the working configuration when two VRFs, local and global, are used?
Best regards,
Peter
12-02-2011 06:58 AM
My configuration:
R2:
ip vrf global
rd 1:1
route-target export 1:1
route-target import 1:2
route-target import 1:1
!
interface FastEthernet0/0
ip vrf forwarding local
ip address 50.50.50.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
router ospf 1 vrf local
router-id 2.2.2.2
log-adjacency-changes
redistribute bgp 1 subnets
network 50.50.50.1 0.0.0.0 area 0
default-information originate always
!
router bgp 1
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 200.200.200.0
neighbor 10.0.0.2 remote-as 2
no auto-summary
!
address-family ipv4 vrf local
redistribute ospf 1 vrf local
no synchronization
exit-address-family
!
address-family ipv4 vrf global
no synchronization
network 200.200.200.0
exit-address-family
!
From R2 I can ping R6, but from R7 can't. Looks like it doesn't route between global and vrf tables.
12-02-2011 01:22 PM
Donatas,
The configuration you've posted is not complete, is it? The definition of VRF "local" is missing.
Still, you are saying that from R2, you can ping R6, however, it is not possible from R7. So, a couple of classic questions follow - please be so kind to answer them all:
Thank you!
Best regards,
Peter
12-03-2011 10:27 AM
Okey, I will ask simplier: how to import vrf routes into global routing table? ;-)
12-03-2011 10:38 AM
Hi Donatas,
Hey, I haven't expected that kind of back-off Are there any problems in answering my questions?
To my best knowledge, for the VRF-to-global routing table redistribution, there are no automatic mechanisms available in Cisco IOS. There is a support for the opposite direction: to import prefixes from the global routing table into a VRF but that is probably not what you asked for.
Nevertheless, I encourage you once more to try to go over my questions. With static routes, it may be possible to achieve what you need but I need more information about how your network works before I can come up with a suggestion.
Best regards,
Peter
12-05-2011 12:33 AM
Hi, Peter,
here is detailed topology: http://donatas.net/vrf-to-non-vrf.jpg
R2#sh ip vrf
Name Default RD Interfaces
global 1:1 Se0/0
local 1:2 Fa0/0
1. Yes, it has default route from R2:
R7#sh ip route | begin Gateway
Gateway of last resort is 50.50.50.1 to network 0.0.0.0
C 200.200.200.0/24 is directly connected, Loopback0
50.0.0.0/30 is subnetted, 1 subnets
C 50.50.50.0 is directly connected, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 50.50.50.1, 00:18:17, FastEthernet0/0
2. R2 doesn't have on global routing table 50.50.50.0/30 network, also 200.200.200.0/24
R2#sh ip route | begin Gateway
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 1 subnets
B 100.100.100.0 [20/0] via 10.0.0.2, 00:10:03
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/1
192.168.1.0/30 is subnetted, 1 subnets
B 192.168.1.0 [20/0] via 10.0.0.2, 00:10:03
R2#sh ip route vrf local | begin Gateway
Gateway of last resort is not set
O 200.200.200.0/24 [110/11] via 50.50.50.2, 00:27:04, FastEthernet0/0
50.0.0.0/30 is subnetted, 1 subnets
C 50.50.50.0 is directly connected, FastEthernet0/0
R2#sh ip route vrf global | begin Gateway
Gateway of last resort is not set
B 200.200.200.0/24
[20/11] via 50.50.50.2 (local), 00:30:46, FastEthernet0/0
50.0.0.0/30 is subnetted, 1 subnets
B 50.50.50.0 is directly connected, 00:30:46, FastEthernet0/0
20.0.0.0/30 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Serial0/0
Traceroute, doesn't know how to get back (I guess so):
R7#traceroute 100.100.100.1
Type escape sequence to abort.
Tracing the route to 100.100.100.1
1 50.50.50.1 48 msec 40 msec 12 msec
2 50.50.50.1 !H
3. No one reach R6 at all.
4. R6 doesn't have routes about 50.50.50.0/30, also 200.200.200.0/24.
R2 configuration:
ip vrf global
rd 1:1
route-target export 1:1
route-target import 1:2
route-target import 1:1
!
ip vrf local
rd 1:2
route-target export 1:2
route-target import 1:2
route-target import 1:1
!
interface FastEthernet0/0
ip vrf forwarding local
ip address 50.50.50.1 255.255.255.252
duplex auto
speed auto
!
interface Serial0/0
ip vrf forwarding global
ip address 20.0.0.1 255.255.255.252
clock rate 2000000
!
interface FastEthernet0/1
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
router ospf 1 vrf local
router-id 2.2.2.2
log-adjacency-changes
redistribute bgp 1 subnets
network 50.50.50.1 0.0.0.0 area 0
default-information originate always
!
router bgp 1
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 200.200.200.0
neighbor 10.0.0.2 remote-as 2
no auto-summary
!
address-family ipv4 vrf local
redistribute ospf 1 vrf local
no synchronization
exit-address-family
!
address-family ipv4 vrf global
neighbor 20.0.0.2 remote-as 2
neighbor 20.0.0.2 shutdown
neighbor 20.0.0.2 activate
no synchronization
network 200.200.200.0
exit-address-family
!
12-06-2011 11:39 PM
Hi Donatas,
Your depiction of the topology is not entirely correct: the non-vrf interface is the Fa0/1 on R2, not the S0/0 as the exhibit suggests. Also, the exhibit is lacking any addressing information, forcing me guess what the addresses behind R5 and R3 may be.
The VRF "local" on R2 is missing the route towards 100.100.100.1 (assuming 100.100.100.1 is R6). Hence the unreachable response from R2 while tracerouting. This problem can be remedied in many ways, either by setting up a static route or by importing the routes from the global routing table into the "local" VRF.
Solving this issue is one half of this problem. The other half of this problem is making sure that the replies from R6 reach R7. So far, you have indicated that R6 has no clue about the existence of the 50.50.50.0/30. Logically, then, it can not respond. Even if it responded, we would need to know through which interface on R2 the replies come in, because the routing table associated with this ingress interface would then need to also contain the route towards 50.50.50.0/30 (a inter-VRF route).
Your setup is quite unusual and so far, strongly incomplete. Can you perhaps explain in more detail why do you want to set up your network this way?
Best regards,
Peter
07-23-2020 08:23 AM
I like it, too the point. I'm now finding myself asking or wanting to know the same thing. It's just that simple isn't it. All we are asking for is how it's done, what the secret sauce is with whatever type of routing is being done.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide