|
In a previous article you learned how to build a basic L3VPN for a customer owning two distant sites. In this article we extend the topology by adding a VPNv4 route reflector. We modified a bit the addressing plan according to RFC3021 which allow the use of /31 subnets mask for point-to-point links and RFC6752 which recommand to use officially allocated public addresses for infrastructure links and loopbacks. We assume that we received from our RIR the block 23.0.0.0/8.
Cabling 
Same calbing plan as in the previous article plus a new link between router P and the route reflector (RR).
Point-to-point links are emulated via dedicated VLANs on a vSwitch. For example, link between P (R3) and RR (R6) is emulated via VLAN 50 : 
Addressing
23.0.0.0/24 is dedicated to PE routers and RR loopbacks.
23.0.1.0/24 is dedicated for infrastructure links. 
RR configuration 
In our previous article, PE1 and PE2 were peering VPNv4 routes directly. To support adding multiple VPN PE routers without maintaining a full meshed iBGP network, we add a VPNv4 route reflector in our topology.
On R6 (RR), we configure a peer group including each VPN PE in order to reduce configuration overhead when adding more VPN PE in the future (it's also simplify BGP update message generation on the router). We disable ipv4 peering because we dedicate this router to vpnv4 route reflection. Notice the « route-reflector-client » command under vpnv4 address family :
Interface Loopback0
ip address 23.0.0.3 255.255.255.255
!
! MPLS is not needed on this link as it is not intended that VPN
! traffic will be forwarded by the route reflector
interface GigabitEthernet2
ip address 23.0.1.4 255.255.255.254
negotiation auto
!
router ospf 1
network 23.0.0.0 0.0.0.255 area 0
network 23.0.1.0 0.0.0.255 area 0
!
router bgp 1
bgp log-neighbor-changes
neighbor VPN-PE peer-group
neighbor VPN-PE remote-as 1
neighbor VPN-PE update-source Loopback0
neighbor 23.0.0.1 peer-group VPN-PE
neighbor 23.0.0.2 peer-group VPN-PE
!
address-family ipv4
no neighbor 23.0.0.1 activate
no neighbor 23.0.0.2 activate
exit-address-family
!
address-family vpnv4
neighbor VPN-PE send-community extended
neighbor VPN-PE
route-reflector-client
neighbor 23.0.0.1 activate
neighbor 23.0.0.2 activate
exit-address-family
|
On PE1, we also configure a peer-group including the route reflector for the same reasons as mentioned above in the case we decide to add a second route reflector for redundancy :
router bgp 1
bgp log-neighbor-changes
neighbor VPN-RR peer-group
neighbor VPN-RR remote-as 1
neighbor VPN-RR update-source Loopback0
neighbor 23.0.0.3 peer-group VPN-RR
!
address-family ipv4
no neighbor 23.0.0.3 activate
exit-address-family
!
address-family vpnv4
neighbor VPN-RR send-community extended
neighbor 23.0.0.3 activate
exit-address-family
|
Configuration is similar on PE2.
Verifications :
PE1#show ip route vrf CUSTOMER1
snip
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets
B 172.16.100.0 [20/0] via 192.168.0.0, 23:12:20
B
172.16.200.0 [200/0] via 23.0.0.2, 01:38:46
192.168.0.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.0.0/31 is directly connected, GigabitEthernet2
L 192.168.0.1/32 is directly connected, GigabitEthernet2
B
192.168.0.2/31 [200/0] via 23.0.0.2, 01:38:46
CE1#ping 172.16.200.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/15 ms
|
|
