Can i run bgp without igp

Why because by default your router can't reach the remote router's loopback due to lack of routing information. So we need IGP or static routing in this case. Hi Deepak, I think this is exactly where my confusion is i.

What it can and cannot i. And as jh mentioned that we could use iBGP between peers and they will establish communication but I'm talking about more on the functionality piece. These routes are injected from the routing table of the BGP-speaking router. For this to happen, an exact route for the prefix that needs to be advertised, should be installed in the routing table on the BGP-speaking router. The BGP network command must reference the exact prefix for which a route is currently installed in the routing table of the BGP-speaking router.

When such a route for the exact prefix is not installed in the routing table, a workaround is to use a black hole route outgoing interface null0, in other Vendors context to this prefix. This way, the route in question will be installed in the routing table, it will be injected into BGP table and advertised to BGP peers.

The IGPs bootstrap themselves to the topology and dynamically discover neighbors. In addition, BGP has to wait for a reliable connection to be established before beginning the rest of its session establishment. The reason for this requirement is rooted with enhancements made to BGP to overcome some issues experienced with its predecessor, EGP. More information is here: The specified item was not found. I didn't actually say anything about i BGP. Consider when you have a peering with an ISP, you have your router, they have their router, you peer using BGP, likely the e type and there is likely no IGP involved, there's likely no static route involved, and in fact there could be little more than a cable between the two.

The internal BGP peers must be able to reach each other. If that was achieved with an IGP, with static routing or with fully meshed direct links between the routers is not important as long as each iBGP router can reach any of its BGP neighbors.

Thanks Juergen. Quick follow up. No you do not required redistribution between igp and bgp. BAD Idea! If session is established, BGP route is there. No route, no BGP session. Doyle , Cisco press. This is a very common question that many people ask here. I think the learning path provided by Cisco kind of influences this way of thinking. But you cannot really do that, because BGP is a different type of protocol.

This in turn mandates that within an AS to be able to pass prefixes between the routers, they have to be directly peered. Look at the following example:. Let's say we want to only use BGP in the network.

Next we start advertising network A from R1 to R2. But because of the loop avoidance rule wich is called split horizon, yes, same as in RIP , R2 will not advertise this network to R3. So, to try to solve this problem we create one more peering from R1 to R3. However, it doesn't work by default. OK, that's easy to solve, isn't it? We just start to advertise directly connected networks of R2 to both R1 and R3. This works just fine. R1 learns about the network between R2 and R3.

R3 learns about network between R1 and R2. Everyone is happy. Now R1 advertises network A to both R2 and R3 directly. Although this is typically and appropriately dismissed as a bad idea, few people take the time to examine the reasoning behind the conclusion.

This article discusses five major weaknesses of IBGP as interior routing protocol. It is important to understand that this article does not assert that IBGP cannot function as an interior routing protocol.

Rather, it explains why IBGP is a poor choice for the role given the availability of alternative protocols. One of the major features of all modern interior routing protocols is the ability to automatically discover and form adjacencies with neighboring routers on links with broadcast capability.

BGP, by contrast, requires the explicit configuration of all neighbors. While it may be desirable to always statically configure neighbors in any routing protocol for security reasons, dynamic neighbor discovery is a valuable feature for less hands-on network deployments. IGPs determine the best path for a destination based on relatively simple metrics.

All of these are easily tuned to meet the needs of the network operators. In all cases, the route with the lowest metric wins. BGP, on the other hand, employs a rather complex path selection process to determine the best route for a destination. If IBGP is used as an IGP, this presents severe scaling problems; every router would have to peer with every other router on the network. The full-mesh requirement can be overcome by carefully designating intermediate routers as route reflectors, but we're still left with the issue of excessive route recursion.

Although end-to-end connectivity is achieved, the routing tables on R1 and R4 are needlessly complex. R1's table looks like this:. In order for CEF to resolve the next hop address of, for example, db, it must perform a recursive lookup for every hop in the BGP path. In this case, this requires three lookups:. This recursive resolution is performed only in response to routing updates, not per packet, but it does introduce significant convergence delays. The following output from debug ip cef table shows that routes with next hops which cannot be immediately resolved are queued for later processing.

The example below is from a similar IPv4 topology, as the IPv6 version of the command produced no output. Compare the routing table above to the one produced by OSPFv3 running on the same topology.

Every route is advertised with a directly connected next hop address, removing the burden of route recursion. Configured with its default second hello timer and second dead timer, OSPF will take between 30 and 40 seconds to react to an indirect adjacency failure that is, a failure which does not transition the interface status. BGP's default hello and hold timers are 60 and seconds, respectively; BGP can take up to three minutes to respond to an indirect failure. Although the timers of both protocols may be tuned to much lower values, these default values provide an idea of how quickly either protocol is intended to react.

BGP was intended to function so long as any path to an adjacent router is available; it is not bound to any particular interface. Finally, the right-to-use licensing for router software which supports BGP often costs more than a basic license with only IGP support. This is an especially important decision when implementing a routed access edge. Turn up BFD on the interfaces, set 'fall-over bfd' on the neighbors.

For platforms that don't support BFD, fast peering detection via 'fall-over' is also an option. You can mitigate the configuration scalability issue on your route reflectors with BGP dynamic neighbor discovery, 'bgp listen' on IOS or 'allow' in Junos. Note, the IOS command seems to only be available on higher end platforms - e. Some remarks: 1 "No dynamic discovery" is not really a disadvantage.

But not really the main problem. We can always play with route-reflectors, confederations and next-hop-self. Number 4 convergence is really one of the main reasons. That's clear. BFD isn't enough. So how can i fix this? I know you are supposed to be running an IGP under BGP, but lets just assume that this is not possible in this scenario.

What are my options? You must have a full mesh for iBGP, or you could use a mitigation route reflector or confederations. You could also configure BGP2 as a route reflector. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Asked 2 years, 7 months ago.

Active 2 years, 3 months ago. Viewed times. Given following setup: Configuration of the routers is very straight forward. Router BGP1: interface Loopback0 ip address 1.