bgpipv4
Can somebody provide me with a use case of using BGP in a large private IP network. (as specified in the BGP wiki.
Two follow up questions:
This is most probably because of EBGP split horizon kicking in... i.e. 7204 router receives those prefixes from Quagga, selects best path, and attempts to advertise them. Since the only neighbor is the neighbor the best path was received from, it filters the advertisements. The counter above shows that.
There may be a way to acheive this by exploiting the following BGP next hop rule:
From RFC 4271, 5.1.3 NEXT_HOP:
When sending a message to an external peer, X, and the peer is one IP hop away from the speaker:
- If the route being announced was learned from an internal peer or is locally originated, the BGP speaker can use an interface address of the internal peer router (or the internal router) through which the announced network is reachable for the speaker for the NEXT_HOP attribute, provided that peer X shares a common subnet with this address. This is a form of "third party" NEXT_HOP attribute.
Could you try this:
Remove the OSPF adjacency between Cisco and Mikrotik on network 192.168.2.0/30
Create the OSPF adjacency between the Cisco and Mikrotik routers across the shared network 198.51.100.0/29
Make sure that the routes the Cisco router is learning via OSPF have a next hop of 198.51.100.5
Clear the BGP sessions. The Cisco router should now advertise routes to internal subnets with a BGP NEXT_HOP of 198.51.100.5
This article shows an example:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html
BGP Next Hop (Multiaccess Networks)
This example shows how the next hop behaves on a multiaccess network such as Ethernet.
Assume that RTC and RTD in AS300 run OSPF. RTC runs BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA with regard to 180.20.0.0, RTC uses as next hop 170.10.20.3. RTC does not use its own IP address, 170.10.20.2. RTC uses this address because the network between RTA, RTC, and RTD is a multiaccess network. The RTA use of RTD as a next hop to reach 180.20.0.0 is more sensible than the extra hop via RTC. Note: RTC advertises 180.20.0.0 to RTA with a next hop 170.10.20.3. If the common medium to RTA, RTC, and RTD is not multiaccess, but NBMA, further complications occur.
Best Answer
Our network isn't even all that big and we utilize this network design pattern. It just makes manageability easier. Scale-ability just completely goes away as an issue. And ultimately it becomes a little easier to grok what's going on in the network.
The general idea is that the network infrastructure uses OSPF (or IS-IS, or other sorts of IGP routing information), while "customer" routes are carried by BGP. Where "customer" there could be IP blocks at the edge of the network, routes from upstream providers, routes from 3rd party partners and VPNs. The result being that you can look at the source of the route...if its from an IGP, you know that its describing the internal network topology of your network, and if its a BGP route, you know its a "source" or "destination" network (at least from the perspective of your internal network).
We go so far as to have Quagga or other routing protocol implementations on some of our Linux servers...they're peering using eBGP to their upstream routers (typically 2), and inject routes for IP addresses on their loopback interfaces into BGP. Using BGP allows us to put a lot of policy enforcement on the edge routes to only allow the Linux servers to advertise certain specific IPs.
Overall this use case works extremely well, reliable and hugely scale-able. It does take a bit of mind-set change from typical Enterprise network design, but its well worth it, IMO.