Hello, Be aware that there are more things to take into account apart from the failure detection time. When a protocol detects or it is notified about the failure, then it has to notify to the other routers in the network about the failure and also these routers have to propagate (after running BGP Best Path Selection) it and so on. You are right about the keepalive/hold timers and these are 60/180 seconds by default. However, the value is negotiated to the minimum during BGP session establishment. You might verify it with show ip bgp neighbors. In the particular case you are talking about, a physical cut, you are also right that if the interface goes down, by default, the BGP session is automatically brought down by a mechanism called BGP Fast External Fallover, which is enabled by default for eBGP.  Now, let´s suppose that this happens in your end but yo do not know if in the provider end it occurs the same. It will depend if the other end receives the loss of carrier or not. In case there is a direct link between both ends, that will be the case. However, if there is any Layer 2 network between your router and provider router, SP device will have to wait until hold timer expiration to detect the failure. The second part, about failure propagation, there is a timer called Minimum Advertisement Interval (MRAI) that is 30 seconds by default in eBGP. You may also see it with show ip bgp neighbors. It controls the BGP Update propagation. So, if there are several ASN´s between your AS and the destination where you are testing this, it may take more time depending of N upstreams ISP´s convergence time/configuration depending of the MRAI timer. I have omitted other details of convergence time, but the most relevant parts/timers are the failure detection and failure propagation. Best Regards, Jose. ... View more

Hi, more information is needed in order to have a better understanding of the scenario and what you are trying to do. For the configuration of eBGP peering you have three options: disable connected check, eBGP multihop, or TTL Security Check. The drawback of using a VIP as next-hop is that it will work depending of how FHRP is configured to handle failure scenarios. By the way, you have another option here, without using loopbacks, and that would be a single peering session between R1 and the VIP address that share R2-R3. Best Regards, Jose. ... View more

Hello, the reason why you are unable to have reachability between the CE´s is because the MP-BGP session between PE´s is established through their loopbacks, therefore, even though they are directly connected (no P´s in between) the MP-BGP session is not established through their directly attached interfaces. By the way, this is the most common approach (to use the loopback) in SP core networks. You need to enable explicitly MPLS, which will run LDP protocol, in order to have reachability to the next-hop as this will be a labeled-next hop. Remember that the VPN label (assigned by MP-BGP) is what is needed to reach the "VRF" prefixes and the IGP label (assigned by LDP in this case) is what is needed to reach the "Next-Hop" inside the cloud. You could have a working scenario in this case without enabling LDP if you run the MP-BGP session between PE´s thorugh their directly connected interfaces and also add the interface command "mpls bgp forwarding" in these interfaces. Hope this helps, Jose. ... View more

Hi, enter the command: undebug all to disable debugging, then check the CPU usage. Best Regards, Jose. ... View more

You will set the next-hop in the route-map to a dummy route reachable through the dialer interface, in order to do the tracking. Then, in case the tracking fails, you will reach this dummy route (the same) through the Cellular interface. So, you do not need to set the interface in the route-map just this dummy next-hop. ... View more

Hi Neil, you´re right and in order to route to the cellular interface you'll add the same dummy route reachable through the cellular interface with a worse AD: ip route x.x.x.x y.y.y.y Cellular0 50   ... View more

Another option would be to set to a dummy next-hop instead of the dialer interface. This next hop would point to the dialer interface doing tracking in the static route to reach this dummy next hop: ip route x.x.x.x y.y.y.y.y dialer1 track 1    ... View more

Hello Vinit & Peter, nice discussion about this lovely protocol! I respectfully disagree with Vinit:  "Since you know, ATOMIC_AGGREGATE attribute is just a kind of an alert attribute that tells the receiving router that aggregate route might  or might-not not be from the advertising AS." Atomic-Aggregate attribute function is to indicate that loss of information, BGP attributes, has occurred.  As you know, you already have the information about which router performed the aggregation as it is indicated in the optional attribute AGGREGATOR that includes the AS and router-id of the router that did the aggregation. By default, in Cisco, when you configure aggregation without the as-set option, it includes the atomic-aggregate attribute. It creates the summary with the specific prefixes "cleaning" BGP attributes, losing the AS_SET information. Also, if for example there are communities attached in the specific prefixes it will get lost. On the other hand, when you configure aggregation with the as-set option for loop detection, it will include the attributes of the specific prefixes, with the AS_SEQUENCE in the AS_PATH and also, as said, it inherits the attributes of the routes that contribute to generate the aggregate. You may always control or cleaning the attributes of the aggregate with the attribute-map option  By the way, when you use conditional route injection both atomic-aggregate and aggregator attributes are copied to the injected prefix regardless the copy-attributes is used or not. Best Regards, Jose. ... View more

Hi Craig, for this number of sites I recommend you to choose MPLS/VPN instead of VPLS, as it scales much better.  Best Regards, Jose. ... View more

Hi, please, post the configuration. Thanks, Jose. ... View more