11-04-2018 08:42 AM
Hello,
I made LAB using CSR1000V as PE and 3750 as CE , i configured RIP CE/PE, routing between them is working well, however redistribution is not working
PE configuration :
vrf definition vpn1
rd 100:1
!
address-family ipv4
route-target export 100:1
route-target import 100:1
exit-address-family
-------------
Redistribution
router rip
version 2
!
address-family ipv4 vrf vpn1
redistribute bgp 65500 metric transparent
network 34.0.0.0
no auto-summary
version 2
exit-address-family
------------------
router bgp 65500
bgp log-neighbor-changes
neighbor VPNv4 peer-group
neighbor VPNv4 remote-as 65500
neighbor VPNv4 update-source Loopback0
neighbor 172.16.0.2 peer-group VPNv4
neighbor 172.16.0.5 peer-group VPNv4
!
address-family vpnv4
neighbor VPNv4 send-community extended
neighbor VPNv4 route-reflector-client
neighbor 172.16.0.2 activate
neighbor 172.16.0.5 activate
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute rip
exit-address-family
!
PE1#show ip route vrf vpn1
10.0.0.0/24 is subnetted, 1 subnets
R 10.1.0.0 [120/1] via 34.0.0.1, 00:00:11, GigabitEthernet4
34.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 34.0.0.0/8 is directly connected, GigabitEthernet4
L 34.0.0.2/32 is directly connected, GigabitEthernet4
ping from PE TO CE
PE1#ping vrf vpn1 10.1.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/11 ms
Can someone please tell me what is going wrong. thanks
Solved! Go to Solution.
11-05-2018 05:43 AM - edited 11-05-2018 05:53 AM
Hi MKERKACHE,
Some comments about the information that you have provided:
- As general rule we can say that in order to redistribute routes from one protocol to another protocol those routes must be present in the routing table. In our scenario we are talking about L3VPN, thus at least two things must occur:
1: MP-BGP learned routes must be imported in the vrf (vpn1), check RT values in order to ensure it
2: MP-BGP learned and imported routes must be installed in the vrf (vpn1) rounting table, thus those routes are the best routes.
PE1 does not have any route in the vrf vpn1 routing table learned from MP-BGP. If PE1 does not have any route in the vrf vpn1 routing table learned from MP-BGP PE1 will not redistribute any MP-BGP route.
PE1#show ip route vrf vpn1
10.0.0.0/24 is subnetted, 1 subnets
R 10.1.0.0 [120/1] via 34.0.0.1, 00:00:11, GigabitEthernet4
34.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 34.0.0.0/8 is directly connected, GigabitEthernet4
L 34.0.0.2/32 is directly connected, GigabitEthernet4
Once you fix the previous problem please take into account the redistribution metric adopted at rip:
redistribute bgp 65500 metric transparent
I am sure that you know that but make sure that the MED attribute of the routes learned frm MP-BGP that need to be redistributed into rip is not greater or equal to 15, if that is the case the route will be discarded because max hop will be reached.
Regards,
11-04-2018 11:24 AM
11-05-2018 05:43 AM - edited 11-05-2018 05:53 AM
Hi MKERKACHE,
Some comments about the information that you have provided:
- As general rule we can say that in order to redistribute routes from one protocol to another protocol those routes must be present in the routing table. In our scenario we are talking about L3VPN, thus at least two things must occur:
1: MP-BGP learned routes must be imported in the vrf (vpn1), check RT values in order to ensure it
2: MP-BGP learned and imported routes must be installed in the vrf (vpn1) rounting table, thus those routes are the best routes.
PE1 does not have any route in the vrf vpn1 routing table learned from MP-BGP. If PE1 does not have any route in the vrf vpn1 routing table learned from MP-BGP PE1 will not redistribute any MP-BGP route.
PE1#show ip route vrf vpn1
10.0.0.0/24 is subnetted, 1 subnets
R 10.1.0.0 [120/1] via 34.0.0.1, 00:00:11, GigabitEthernet4
34.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 34.0.0.0/8 is directly connected, GigabitEthernet4
L 34.0.0.2/32 is directly connected, GigabitEthernet4
Once you fix the previous problem please take into account the redistribution metric adopted at rip:
redistribute bgp 65500 metric transparent
I am sure that you know that but make sure that the MED attribute of the routes learned frm MP-BGP that need to be redistributed into rip is not greater or equal to 15, if that is the case the route will be discarded because max hop will be reached.
Regards,
11-06-2018 09:59 PM
Hi,
thanks the issue was fixed
11-08-2018 06:07 AM
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