This topic is to discuss the following lesson:
Hello Everyone,
I have a question regarding the " Static VRF routes" defined under the MP-BGP section. I believe they should look like this:
ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
Instead of:
ISP(config)#ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
Am I missing something or this is just a typo?
Many thanks!
2 Likes
do you can ping 3.3.3.3 source 1.1.1.1 on router Red1 ? i can not do that
Hello Jose
Yes, you are correct. Rene states that:
Now we can worry about getting the routes into each other’s VRF. For each VRF, I will create a static route that points to the loopback 0 interface of the other VRF:
The commands are correct in the configurations however, so yes, it should be as you suggest. I will let @ReneMolenaar know.
Thanks for catching that!
Laz
Hello Khuat Quang N
There is a typo in the commands in the lesson, so this might be why you’re not able to ping. Take a look at the previous post above. Look at the configurations of each of the routers in the lesson in order to see the correct configuration commands.
I hope this has been helpful!
Laz
You are absolutely correct, not sure how I ended up with that in the configs as the show output does show the correct output. It has been fixed.
1 Like
Actually I got confused after the VRF static change in MP-BGP section.
Why we need VRF static to loopback0 of the other VRF?
How can ISP VRF BLUE reach BLUE1 loopback without redistribute static.
In my mind, before we configure the route leak, ISP BLUE VRF should reach BLUE1 loopback0 via whatever IGP/static we choose. Then the IGP/static routes should be redistributed via its VRF BGP and then leak to to the other VRF via MP-BGP.
If we use
ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
Isn’t it that before MP-BGP leaking routes between VRFs, the VRF itself dose not know how to reach the loopback0 its VRF connecting to?
I am sorry if I understand it incorrectly.
Could someone explain why we need
“For each VRF, I will create a static route that points to the loopback 0 interface of the other VRF”
Thank you in advance.
Hello Zhan
The commands to provide a static route to the loopback of the other VRF are the actual static routes that we want to redistribute. They are the test routes that will be checked to verify that redistribution will take place correctly once the redistribution configuration is complete. These could have been to L1 of each of the routers, it doesn’t really matter.
It can’t. Currently, the loopbacks of BLUE1 cannot be reached via the ISP VRF BLUE because they haven’t been configured. We don’t actually need this connectivity, since the loobacks of BLUE will be reached via the RED VRF and visa versa.
Remember that the goal is to allow 1.1.1.1/32 to communicate with 3.3.3.3/32. By providing routing information to the VRF to reach the loopback of the other VRF, we are achieving that. Once that’s done, and the BGP redistribution is put into place, connectivity is achieved.
I hope this has been helpful!
Laz
Sorry I am confused. Based on the show output can I confirm if the static routes are correct?
ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
!
ISP#sh ip route vrf RED bgp
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (BLUE), 00:04:45
B 192.168.23.0/24 is directly connected, 00:31:16, FastEthernet1/0
ISP#sh ip route vrf BLUE bgp
B 192.168.12.0/24 is directly connected, 00:31:24, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (RED), 00:04:53—EDITED—
This post contains incorrect information, please take a look at this post for clarification!
—END EDIT—
Hello Kenneth
Looking at your output something seems to be a bit off. First of all, is the output copy and pasted exactly as it was from your output? This does not seem to be the case because the sh ip route vrf BLUE bgp output should show the routes in ascending order, so 1.1.1.1 should be first. It seems some manipulation was done. However, having said that, this once again doesn’t match up with the ip route commands shown at the beginning of your post.
Each static route must point to the loopback of the OTHER VRF. What you’ve done is pointed them to the loopbacks of the SAME VRF. It should read:
ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
Once those routes are redistributed using BGP, the show ip route commands should look something like this:
ISP#show ip route vrf RED bgp
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (BLUE), 00:06:41
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.23.0/24 is directly connected, 00:08:20, GigabitEthernet0/2
ISP#show ip route vrf BLUE bgp
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (RED), 00:07:23
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.12.0/24 is directly connected, 00:09:00, GigabitEthernet0/1
I hope this has been helpful!
Laz
Hello Laz
Yes it was copy from my own gns3 output I made changes to the static routes
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
Notice the show results below are different, which i do not understand
ISP#show ip route vrf RED bgp
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (BLUE), 00:08:55
B 192.168.23.0/24 is directly connected, 00:16:11, FastEthernet1/0
ISP#show ip route vrf BLUE bgp
B 192.168.12.0/24 is directly connected, 00:16:23, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (RED), 00:09:07
Red1#ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/40/60 ms
Blue1#ping 1.1.1.1 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/40 msHmm
I’m going to get Rene to take a look at this. Another set of eyes may see something that was missed…
Laz
1 Like
I think MP-BGP part of this section is a little bit tricky.
For ISP router, I think the static route should be point to the same side vrf where it locates. That is, set 1.1.1.1 at vrf RED.
Then we redistribute both 1.static route of loopback and 2.connected next hop address to let it show up on the other side. That is, vrf BLUE learn 1.1.1.1 and 192.168.12.0 from BGP.
My config are as following, note that for RED, 3.3.3.3 and 192.168.23.0 are learned from BGP.
Click to open ISP config with static route on its side
hostname ISP
!
ip vrf BLUE
rd 3:3
route-target export 1:1
route-target import 3:3
!
ip vrf RED
rd 1:1
route-target export 3:3
route-target import 1:1
!
ip cef
no ipv6 cef
!
interface Ethernet0/1
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/2
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-family
no ip http server
**ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1**
**ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3**ISP#show ip route vrf RED
Routing Table: RED
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.12.1
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (BLUE), 00:03:05
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, Ethernet0/1
L 192.168.12.2/32 is directly connected, Ethernet0/1
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.23.0/24 is directly connected, 00:03:05, Ethernet0/2
L 192.168.23.2/32 is directly connected, Ethernet0/2
ISP#show ip route vrf BLUE
Routing Table: BLUE
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (RED), 00:04:31
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.12.0/24 is directly connected, 00:04:31, Ethernet0/1
L 192.168.12.2/32 is directly connected, Ethernet0/1
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.23.0/24 is directly connected, Ethernet0/2
L 192.168.23.2/32 is directly connected, Ethernet0/2
On the other hand, set static route on the other side if I/F is also working. In this case, route of loopback are static config and only next hop address are learned though redistribute connected. Which means that we don’t need redistribute static (I kept it in the following config).
I got same result as Kenneth. Maybe lagapides just forgot to clear ip bgp *?
The configuration and show ip route are as following, note that for RED 3.3.3.3 route are static and next hop 192.168.23.0 are learned from BGP. Also note that the 1.1.1.1 route is also learned from the BLUE side by BGP by redistribute static, which is very annoying.
Click to open ISP config with static route on different side
hostname ISP
!
clock timezone JST 9 0
!
ip vrf BLUE
rd 3:3
route-target export 3:3
route-target import 1:1
!
ip vrf RED
rd 1:1
route-target export 1:1
route-target import 3:3
!
ip cef
no ipv6 cef
multilink bundle-name authenticated
!
!
interface Ethernet0/0
no ip address
shutdown
!
interface Ethernet0/1
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/2
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
interface Ethernet0/3
no ip address
shutdown
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
end
ISP#show ip route vrf RED
Routing Table: RED
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (BLUE), 00:05:55
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, Ethernet0/1
L 192.168.12.2/32 is directly connected, Ethernet0/1
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.23.0/24 is directly connected, 00:05:55, Ethernet0/2
L 192.168.23.2/32 is directly connected, Ethernet0/2
ISP#show ip route vrf BLUE
Routing Table: BLUE
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.12.1
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (RED), 00:06:30
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.12.0/24 is directly connected, 00:06:30, Ethernet0/1
L 192.168.12.2/32 is directly connected, Ethernet0/1
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.23.0/24 is directly connected, Ethernet0/2
L 192.168.23.2/32 is directly connected, Ethernet0/2
By the way, it will be nice if you can add some explaination of how route-target play roles here.
I completely agree with risyou I test it.
Is it vrf route-replication another method to leak routes between Vrfs? I got from your EVN lesson.
Thanks
Regards
Hello Ignacio
Route replication for VRFs is not the same as leaking routes between VRFs. Leaking routes will allow one customer VRF to communicate with another customer VRF. Route replication allows all customer VRFs to communicate with a third VRF in which there may be multiple shared services to be used by all customers. The results are similar, but it is implemented differently. Route replication creates a single VRF to which all (or selected) customers can have access to (one to many( while route leaking requires leaking from one VRF to another (one to one).
I hope this has been helpful!
Laz
1 Like
Hi and thanks for this great lesson.
In the part one with static routes, the following command also works but are more short, no need to add static route in the global routing table. IOS 15.6(2)T
ip route vrf RED 3.3.3.3 255.255.255.255 GigabitEthernet0/2 192.168.23.3 global
ip route vrf BLUE 1.1.1.1 255.255.255.255 GigabitEthernet0/1 192.168.12.1 global
1 Like
Hi Lazaros,
please can you point me to route replication courses ?
Hello Thierry
Yes you are correct that in order to make the lab work, these commands would function correctly without the need for the additional static routes. However, this would still only take care of the specific destinations indicated in the commands. Any traffic destined for other networks such as “The Internet” would not be included, but would be dropped. For this reason, the static default routes are necessary, especially in a real-world environment.
I hope this has been helpful!
Laz
1 Like
Hello Thierry
Route Replication can be found as a section of the following lesson:
I hope this has been helpful!
Laz
2 Likes