All Network segments or prefix used in BGP enabled router should be advertised in IGP or only the selected prefix needs to be advertised in IBGP /EBGP Is there any specific standard for this. There's no standard that I know of, there might be best-practice RFCs out there, however. It just depends on what you are doing. In general, however, within the same Autonomous System (AS), there's rarely a need to have link/loopback address space in both the IGP and iBGP as the IGP will always be used for forwarding. The duplicate route that exist in the BGP table will only be communicated to BGP peers.  You may need to have link/loopback address space when both IGP and eBGP is used and then only in specific scenarios. One example would be Inter-AS  Option C for supporting MPLS-VPNs across carrier networks. Its beyond the scope of this thread, but basically, a PE on one AS needs to know the loopback address of a PE  in another AS. The protocol being used between the two carriers is BGP so you may find the link/loopback addresses of PEs that exists in both ASes in the BGP table that is shared _between_ ASes. Again it depends on your application and the goals you want to achieve. If we dont have a full mesh IBGP topology and if we have not enabled synchronization, will it create routing loops? At the BGP protocol level, no. This is because iBGP requires peers to learn about the prefix directly from the originating router ( which implies a direct BGP session). Whatever prefix that _would_ be learned from a non-iBGP peer is not shared among iBGP peers so you don't have a logical loop to deal with. From a forwarding perspective, also no. Imagine that you redistributed an IGP-learned prefix into BGP. With IGP synch enabled, BGP will not announce the route until the IGP has accepted the route. If IGP no longer uses the route for forwarding, then the route doesn't exist in BGP either ( thus no logical loop). That doesn't mean that you can't have a forwarding loop just that it wouldn't be caused by the conditions of partial iBGP mesh with no synchronization. You could still have a forwarding loop even when you have synch enabled. Even without redistribution, if the IGP decides to install a route in its RIB BGP will announce the route if its covered by a "network" statement. When that happens if other iBGP peers decide that this BGP peer is the best path the traffic will arrive at this BGP peer. When the traffic arrives, the forwarding decision will be determined by what is is the routing table of this peer which could lead to a forwarding loop. Note that this peer will not forward based on BGP and it may not forward based on IGP ( e.g. a static route configured on this local peer) ... or if we have not advertise the prefix in IGP but enabled enabled BGP for that prefix with no sync enabled will it cause problem ? The route has to exist in the routing table in order for BGP to announce it. If it the IGP didn't put it into the routing table, how did it get there? Whether there is a forwarding loop depends on the source of the route (i.e. eBGP peer or static route). An easy way to see this happen is in the A<->B<->C topology. Suppose that router B summarizes the prefixes that exist downstream from Router C...suppose router B then tells router A about the summary only. Suppose Router A tells router B about a default route. In this scenario the prefixes are known to router A via BGP. What happens when Router C goes down? A routing loop.   So the purpose of the synch requirement is really to avoid the case where you blackhole traffic between ASes on the principle that you trust the IGP more than you trust the routing table. Remember the routing table could get a prefix in there via a static route where as the IGP should learn ( and remove) the prefix dynamically. Take a look at the below BGP case study which is could provide more insight into the proper use of BGP synch: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#synch   And without IGP  BGP will not run as it does not estalish TCP sessions right. No. All you need for BGP session establishment is reachability to the remote peer. So you could use a static route to each the remote peer.   Hope that helps Joe **Rate if helpful** ... View more

Jon, No that's a good line of reasoning and I had the same thought and had to think about it more myself. Although a "show ip bgp nei <ip> advertised-routes" on CSR(T) should reveal that behavior because you'd see CSR(1)s next hop on advertisement to CSR(2) and vice versa.   ... View more

@Jon Marshall "Your router is not strictly advertising a route it learnt from a peer back to that same peer. What it is doing, I think, is advertising a route it learnt from one peer to the other peer and vice versa. The fact that it is actually the same route should stop it from advertising it but that doesn't seem to be the case here." I don't think this applies. In order for CSR(T) to tell CSR(1) about the path through CSR(2), it would have had to select CSR(2) as the best path. If it selected CSR(2) as the best path, by definition, it hasn't selected CSR(1)...ergo CSR(2) would not get the same announcement for a path through CSR(1). BGP will announcing only a single best-path, unless BGP add-path feature is in use. There will never be a legitimate reason to advertise a route back to the peer that the route was learned from.  I agree in general this is true. Given that BGP is policy driven, I don't think its a problem BGP needs to solve as you can eliminate this behavior by applying outbound route filter policy.  That said. I'm interested as well to see Cisco's take on it.       ... View more

Hi,   Seems like your issue is related to the VPN. Seems like your VPN is timing out and bringing down the tunnels..this may explain why initiating a ping from the server restores reachability. You have site-to-site VPN between HQ and Branch VPN routers? I don't see any VPN config in your "hq_vpn_router" config so I assume your firewall is actually serving as the VPN Hub?   Let me know... Joe ... View more

Let's take this in parts:   Could anyone please explain why we use IGP,IBGP and EBGP in a same Network topology. Depends on the network in terms of scope ( i.e. Internet connected vs internal only vs carrier), scale ( number of routers and number or routes), and administrative preference ( strict separation of routing domains). You couldn't literally write a book to answer this question ( and many smart people have). The short run is if you have a small network ( less than 10-20 routers) and a few hundred routes-- just run an IGP...especially if that network isn't connected to the internet. Event if that network is connected to the internet, running BGP is largely driven by whether you take full/partial routes--some carriers make you run BGP ( even for a default, even though static routing works just fine). Still, in the case of MPLS-VPN (L3VPN), you need to run BGP as a PE-CE protocol so that the carrier knows about your organizations routes.  What is the use of running IGP in BGP topology. Also related to the answer above. But more to the point, you need IGP so that BGP can establish a session. Remember, BGP is TCP based and for two peers to talk, they need a way to get to the remote peer...there's where the IGP comes in. Typically, you advertise the link and loopback IP addresses into the IGP-- this way a remote peer that is several hops away from me knows how to get to me and vice versa. Synchronization rule in BGP says never use or advertise a route learned from IBGP unless same route is learned from IGP. I've yet to see the case where people turn BGP synchronization on. This is largely because in a carrier environment, I don't have or need this restriction. This is due to the fact that in a carrier environment, BGP is being used to transport reachability information ( routes ) around the network. My BGP routing domain may have customer routes ( L3VPN /L2VPN) or transit routes ( from other ASes)-- none of which need to be in the IGP routing information base ( RIB ). BGP Synch could be useful in some failover scenarios. Imagine you have a topo like this A<->B<->C. Imagine that Router B is your router and its learning routes via IGP from Router C. You may want Router B to only tell Router A about routes downstream from Router C if and only if Router B actually can get to the routes downstream from Router C. BGP Synch to the rescue. Again, you have to take scope into context: If I'm Amazon, with a Global network, I'd much rather have Router B blackhole the traffic ( because Router C is down) then to have to wait for the Global internet to reconverge because Router B stopped announcing the routes to Router A ( due to synch rule). Some people would differ on this preference.   Really really great questions. Keep them coming! Joe Rate if Helpful!   ... View more

Hi, This may be covered in the thread @Milan referred to, however. I don't think eBGP has any split horizon mechanism preventing this kind of route reflection ( not like iBGP--don't advertise iBGP learned routes to iBGP peers). So it seems like this behavior is legitimate. Whether CSR(T) advertises the routes back to CSR(1) and CSR(2) isn't really that big of a deal because both CSR(1) and CSR(2) should drop those routes due to AS_PATH loop. From an administrative perspective, CSR(T) shouldn't announce routes that it hasn't originated. This is an "administrative type" restriction because eBGP peers are allowed to announce routes they don't originate (i.e. eBGP learned routes)--you would like to limit that behavior. You probably want to add an outbound route-map to CSR(T) for both CSR(1) and CSR(2) eBGP peers to limit the announcement to just the 192.168.1.0/24 network.   ... View more

Hi Ibrahim, See below:   1) Can you elaborate on this a bit? Can you explain, specifically, what your trying to accomplish? I don't think you can get a default route into the OSPF RIB that is not external as the default is injected as a Type-5 LSA (e1 or e2). If your talking about getting a router to use the OSPF learned default over the default router learned via some other source (e.g. static, BGP, etc), then it depends on the source because of the Administrative Distance when comparing the two defaults ( the one default learned via OSPF has AD=110, and the other default is AD=X, where X is the Administrative Distance assigned to the protocol). 2) Use the "default-information originate metric-type 2" command under "router ospf" -- Note this is the default 3) Use the "default-information originate metric-type 1" command under "router ospf" -- Note, you don't need this in Totally Stubby Area. 4) For NSSA area you have to use the "area nssa <area_num> default information-originate metric-type <type>" router subcommand. Note your NSSA should have a Type-7 LSA for the default route   Rate if helpful. Joe ... View more

Hi Femi, Also wanted to point out a few more things regarding my solution: Asymmetric Routing: There will be some Asymmetric routing due to the ASAs use of default routing. Suppose Remote1 has failed its VPN tunnel over to 2.2.2.2 after HO ASA fails to respond on 1.1.1.1 interface (see diagram). Suppose also that HO Router has figured out that it shouldn't use ISP1 as a next hop ( this is one of the routing issues I have not discussed). In this case, HO router will choose from ISP2 or ISP3--suppose ISP3 is chosen as default route, then from Remote1, the VPN is asymmetric ( i.e. Remote->HO takes ISP2 path, but HO->Remote takes ISP3 path). The same applies to all remote sites. This is not strictly a bad thing, but for troubleshooting/maintenance purposes you should be aware of this behavior Bridging ISP to ASA: Strictly speaking, you do not have to use the "encap dot1q x" config on the HO Router interface facing the ISP ( you don't even need to use sub-interfaces there). If you don't bridge the ISP device with the ASA as I described, then the sub-interfaces on the HO router facing the ASA need to be addressed with the IP block given by the ISP. For example, if ISP assigns a 1.1.1.1/30 and a 100.100.100.0/29 block--HO router uses the /30 and the gi0/0.10 interface uses the /29 address space Traffic Engineering: Though you only have 5 sites, you need to think about the volume of traffic you're getting from each site as that is the volume of traffic you will see on the VPN from that site. Given that the HO Router<->HO ASA link is only 1Gbps, you can see how the link could be oversubscribed. Hair-pining VPN traffic: If you need site-to-site connectivity between your remote sites, you can hair-pin the traffic at the HO ASA. To do this, each of your ASA Vlans will be at the same security level. Then you need to enter the "same-security-trafic inter-inteface" configuration ( see reference)   Please let me know your feedback.   ... View more

Femi, Your question is really design focused, so I start to address it at the design level. I cannot provide any configuration examples until I know specific environment and have your specific configurations. Please check reference appropriate for your version of ASA/ IOS. Please see the attached solution diagram. This solution does not address tunnel security or routing between sites-- I only attempt to address the VPN aspect given your description and your requirements.   Basically, at the HO site: On the HO ASA, you crate VLAN interfaces and convert the port facing the router into a trunk port ( see reference) The router provides transport by bridging the ISP connections with the ASA. Facing the ISP, you use the "dot1q encap X native" interface command. On the port facing the ASA, you configure sub-interfaces and use the "dot1q encap X" interface command on the sub interface. This allows the router to bridge traffic between the ISP and ASA.  As far as the HO ASA configuration, you need to do the following: In addition to the above, you need to Configure Dynamic IPSec crypto map. Your remote sites probably do not have static IP addresses, this allows their IP address to change while still letting the VPN tunnel come up On the Remote Site ASAs the configuration is reduced to specifying a single Crypto-Map with multiple peers (see diagram): See the "set peer" crypto map reference. Your remote site crypto map needs to set the connection type to "originate-only" in order to use multiple peers with the "set peer" command. You will specify three peers, one for each of the HO ASA VLAN interfaces You can establish an order or preference between peers in the crypto map using the "set peer x.x.x.x default" crypto map command. See reference. In this way, the VPN will fall down the list of configured peers, if the HO ASA fails to reply on one interface ( i.e. ISP is down), it will try another interface (hopefully ISP is up) Now, about DMVPN   You can only use DMVPN with Routers as GRE is not supported on ASA (IIRC). The ASA version of DMVPN is Dynamic IPSec tunnels. From a design perspective, if you used DMVPN on router vs. Dynamic IPSec on ASA, you are just moving the tunnel functionality from one device to the other. In your case, you've already paid for an ASA, might as well use it--DMVPN may require a VPN license on the router which may come as a cost.  Here is an excellent introduction to DMVPN. And and overview as well.    HTH.   Rate if helpful ... View more

Hi Femi, Based on your requirements, a DMVPN setup definitely seems most appropriate. You should look into it as I believe ASA can do DMVPN. Now aassuming all you can do is site to site VPNs, then yes you need to configure multiple tunnels at the remote site. The ASA then would need an IP address on each of the IP blocks assigned from the ISPs at the HO for terminating the VPNs. If you can get your own direct IP allocation then your ASA needs only one IP from your allocation for VPN termination. In this scenario, you could run BGP with the ISP but this may not be strictly necessary (you could get them to just use a stactic route for your allocation with the next hop being your side of the /30 with them). An ASN is required however if you use BGP. If you go with a DMVPN solution, then your HO ASA need only have an IP from each of the ISPs blocks. Your remote sites then just get configured with 3 next hop servers.     ... View more

Hi Femi,   Sounds like you need DMVPN, no? However, DMVPN aside, looks like you only need to do the following: On your router, create 3 IP SLA probes, one tracking each ISPs next hop Create 3 default routes, tie them to the IP SLA probes, set AD corresponding to your order of preference On your ASA, create default route to router   Your VPN is using the router AND the ISPs as transport. If the ASAs at the remote site have public IP addresses, then from the perspective of the local site's VPN, it doesn't matter which ISP ( path) is taken to reach its remote peer. You want to avoid load-balancing between ISPs however, as VPNs are sensitive to latency/packet loss.   HTH Joe   Rate if helpful.   ... View more

Whether you can replace the 891 device with another device boils down to a single question: Do you need to run BGP with the Service Provider in order to use their service. If you need to run a routing protocol with your service provider, your service is likely a L3VPN (IP VPN) solution ( i.e. you inject your site's routes into the providers L3VPN session, they use MP-BGP+VRF for segmentation within their network). If, however, they just drop you a L2 connection and provide L2 emulated services ( e.g. L2VPN or VPLS ) across their network, then your device can be whatever you want it to be. From your device's perspective, it is not VRF aware. That is, it does not know about how the service provider segments your service from another customers. In the L3VPN case, your device is routing-protocol aware. In the L2VPN case, your device is not routing protocol aware and does not need to form adjacency with the service provider's equipment.   HTH.   Rate if helpful. ... View more

You get get this /32s into BGP by either redistributing from some other source ( OSPF or Static ). IF you add a network statement, then the prefix _must_ be in the local routing table in order to be advertised via BGP. So you'll have to add the /32s somewhere ( either on an OSPF speaker, or locally with static routes). In fact, if you added local static routes, you'd still need to redistribute them into BGP OR use network statements. I don't see how adding the /32s is avoidable. ... View more