09-26-2017 02:12 PM - edited 03-08-2019 12:10 PM
Hi Here is a question. Can you answer it for me?
MPLS topology is like this:
R1(PE1)(1.1.1.1/24) ----------(1.1.1.2/24)R2(CE2)
If R2 run eigrp, then R1 needs to run eigrp and add redistribute eigrp under bgp. Now R2 run eBGP. The configuration is like this:
R1
router bgp 1
address-family ipv4 unicast vrf Cust_A
redistribute conncted
neighbor 1.1.1.2 remote-as 2
neighbor 1.1.1.2 activate
My question is if command "redistribute connected" is required? and how to explain it? Thank you
Solved! Go to Solution.
09-26-2017 02:41 PM
Hello,
Think of this topology:
R2(CE) --- NetX --- R1(PE) --- MPLS CLOUD --- R3(PE) --- NetY --- R4(CE)
R2 and R4 are two locations of the same MPLS L3VPN, and they both run eBGP to R1 and R3, respectively.
Now imagine that you want to ping R4 from R2, or vice versa. That means that the source and destination addresses would be from networks NetX and NetY. However, this will only work if you tell BGP to advertise both these networks - otherwise, they will be unknown, and the ping will fail. The easiest way of doing it is to configure the PEs, R1 and R3, to redistribute all connected networks within the given VRF, so the PEs will take care of advertising the networks on the PE/CE links.
If the PE/CE protocol was EIGRP, then on PEs, simply by configuring redistribute eigrp process-id in BGP would make BGP import both remote networks learned through EIGRP, and directly connected networks on interfaces where this EIGRP process is enabled. This is in fact a general rule in Cisco IOS for IPv4 redistribution: If you redistribute from one interior routing protocol to another routing protocol (IGP or BGP), you will not only retake the remote networks learned from the source IGP, but also the directly connected networks from all interfaces where the source IGP runs. That is why with EIGRP as the PE/CE protocol, it is not necessary to configure redistribute connected in BGP because the redistribute eigrp process-id automatically retakes the directly connected networks over which EIGRP runs.
Note that technically, the advertisement of PE/CE networks in BGP is not really necessary. These are infrastructure networks, and they do not normally need to be advertised because there are no end hosts located in these networks. However, if they are not advertised, it makes the remote management and monitoring of CE devices cumbersome, if not outright impossible. For example, a traceroute from one MPLS VPN site to another would show asterisks anytime the remote CE would be hit; you wouldn't be able to ping the remote CE from a different VPN location, so these would all be confusing things. Therefore, mostly for the comfort and to avoid unnecessary confusion, PE/CE links are advertised in MPLS VPN along with end host networks.
Feel welcome to ask further!
Best regards,
Peter
09-26-2017 05:12 PM - edited 09-26-2017 06:46 PM
Very good explanation on EBGP/EIGRP for PE-CE. And good and clear topology diagram.
In addition to distribute conntected, we also can publish that link address, like network x.x.x.x under bgp address family ipv4 for this issue, right? Thank you.
09-26-2017 05:19 PM
Hi,
Thank you! You are very much welcome.
In addition to distribute conntected, we also can publish that link address, like network x.x.x.x under bgp address family ipv4 for this issue, right?
Absolutely correct. Still, redistribute connected is simpler, as you do not need to list the PE/CE networks by their exact addresses one by one.
Best regards,
Peter
09-26-2017 02:37 PM - edited 09-26-2017 02:48 PM
Hi
I would like to understand the roles for each router, is R2 a PE or P? The PE routers are using MP-BGP to create the VPN in order to connect each PE, now the CE will see that connection as transparent.
No redistribution is required, Im assuming CE2 is running EIGRP as well.
For exampe PE2
router bgp 100
<ommitting the rest of the config>
address-family ipv4 vrf CLIENT1
redistribute EIGRP 100
router eigrp test
address-family ipv4 unicast vrf CLIENT1 autonomous 100
topology base
redistribute BGP 100 metric 10000 10 255 1 1500
exit
network 10.0.0.1 0.0.0.0
int g0/1
description TO-CLIENT
ip vrf forward CLIENT1
ip address 10.0.0.1 255.255.255.252
CE2
int g0/1
description TO-ISP
ip address 10.0.0.2 255.255.255.252
router eigrp 100
net 10.0.0.2 0.0.0.0
You will form EIGRP adjacency through the protocol so you dont need redistribute connected.
Hope it is useful
:-)
09-26-2017 02:41 PM
Hello,
Think of this topology:
R2(CE) --- NetX --- R1(PE) --- MPLS CLOUD --- R3(PE) --- NetY --- R4(CE)
R2 and R4 are two locations of the same MPLS L3VPN, and they both run eBGP to R1 and R3, respectively.
Now imagine that you want to ping R4 from R2, or vice versa. That means that the source and destination addresses would be from networks NetX and NetY. However, this will only work if you tell BGP to advertise both these networks - otherwise, they will be unknown, and the ping will fail. The easiest way of doing it is to configure the PEs, R1 and R3, to redistribute all connected networks within the given VRF, so the PEs will take care of advertising the networks on the PE/CE links.
If the PE/CE protocol was EIGRP, then on PEs, simply by configuring redistribute eigrp process-id in BGP would make BGP import both remote networks learned through EIGRP, and directly connected networks on interfaces where this EIGRP process is enabled. This is in fact a general rule in Cisco IOS for IPv4 redistribution: If you redistribute from one interior routing protocol to another routing protocol (IGP or BGP), you will not only retake the remote networks learned from the source IGP, but also the directly connected networks from all interfaces where the source IGP runs. That is why with EIGRP as the PE/CE protocol, it is not necessary to configure redistribute connected in BGP because the redistribute eigrp process-id automatically retakes the directly connected networks over which EIGRP runs.
Note that technically, the advertisement of PE/CE networks in BGP is not really necessary. These are infrastructure networks, and they do not normally need to be advertised because there are no end hosts located in these networks. However, if they are not advertised, it makes the remote management and monitoring of CE devices cumbersome, if not outright impossible. For example, a traceroute from one MPLS VPN site to another would show asterisks anytime the remote CE would be hit; you wouldn't be able to ping the remote CE from a different VPN location, so these would all be confusing things. Therefore, mostly for the comfort and to avoid unnecessary confusion, PE/CE links are advertised in MPLS VPN along with end host networks.
Feel welcome to ask further!
Best regards,
Peter
09-26-2017 05:12 PM - edited 09-26-2017 06:46 PM
Very good explanation on EBGP/EIGRP for PE-CE. And good and clear topology diagram.
In addition to distribute conntected, we also can publish that link address, like network x.x.x.x under bgp address family ipv4 for this issue, right? Thank you.
09-26-2017 05:19 PM
Hi,
Thank you! You are very much welcome.
In addition to distribute conntected, we also can publish that link address, like network x.x.x.x under bgp address family ipv4 for this issue, right?
Absolutely correct. Still, redistribute connected is simpler, as you do not need to list the PE/CE networks by their exact addresses one by one.
Best regards,
Peter
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