Avatar
BGP synchronization assumed an older approach of BGP deployment for a transit autonomous system. In this approach, BGP would be configured only on ASBRs, not on internal routers. The ASBRs would have eBGP peerings with outside autonomous systems, and they would also have iBGP peerings to each other. Internal routers, however, would not be running BGP.
Naturally, this constellation would result in blackholing traffic because while the ASBRs know all routes thanks to their eBGP and iBGP peerings, any internal router would have no idea about external networks. So as an additional step, the BGP routes were redistributed into the internal routing protocol. The full reachability would be therefore gained by combining the BGP on and between the ASBRs, and the redistribution of BGP routes into IGP within an AS. The internal routers are therefore spared the need to run full BGP.
Now, an ASBR can know about an external network from another iBGP peer via iBGP and theoretically, it can immediately install it into its routing table and advertise it to further eBGP neighbors. However, if the internal protocol, say, EIGRP, does not yet have that route fully advertised to all internal routers, advertising the route to eBGP neighbors would be futile: the traffic would be still misrouted or blackholed inside our AS until the EIGRP has truly advertised the network.
This is where BGP Synchronization comes in. An ASBR can know about a route via iBGP peering with another ASBR. However, it will not consider that route as valid until the same route comes through an IGP, say, EIGRP, and gets installed in the routing table. Seeing the route learned via iBGP installed as an IGP route means that the neighboring ASBR has redistributed the route correctly into EIGRP and that it is already known to all internal routers between that ASBR and your ASBR, and that means that the path is truly valid - each router on the path between you and the neighboring ASBR knows how to route packets to that destination.
So the state of seeing an iBGP-learned route as IGP-learned in your routing table means that the route itself is synchronized. Only now, you can consider the route as valid, subject it to BGP bestpath algorithm and advertise it to eBGP peers - not sooner.
"I already understand that Sync. must be disabled in case if i have a full meshed IBGP in order for IBGP routes to be entered in the IGP routing table."
iBGP peers must always be fully meshed (let us ignore route reflectors and confederations for now). However, the BGP synchronization should be deactivated if all your routers within an AS are BGP speakers and are supposed to learn the external routes via BGP. In such case, you would never redistribute BGP-learned routes into an IGP (there would be no sense in doing that as all routers speak BGP already) but the activated synchronization would prevent these routers from treating these iBGP-learned routes as valid.
In other words, the BGP Synchronization must be deactivated in all iBGP scenarios where BGP routes are not redistributed into IGP protocol. Otherwise, an iBGP speaker will wait for an iBGP-learned route to be also learned via IGP - which will never happen.
Please feel welcome to ask further!
Best regards,
Peter
https://supportforums.cisco.com/thread/2107257
:)
[ view entry ] ( 1918 views ) | print article
Routers become OSPF Neighbors if they have an interface connected on a common network. For example, two routers connected on a point-to-point serial link could be neighbors.
An Adjacency is required for two ospf routers to exchange route updates. Not all neighbor routers will form adjacencies.
https://learningnetwork.cisco.com/thread/2010
[ view entry ] ( 1442 views ) | print article
Common LSAs:
[ view entry ] ( 1370 views ) | print article
Consider only synchronized routes with no AS loops and a valid next hop, and then:
1.- Prefer highest weight (local router).
2.- Prefer highest local preference (global within AS).
3.- Prefer route originated by the local router (next hop: 0.0.0.0).
4.- Prefer shortest AS path.
5.- Prefer lowest origin code (IGP<EGP<Incomplete).
6.- Prefer lowest MED (metric, exchanged between autonomous systems).
7.- Prefer eBGP path over iBGP path.
8.- Prefer the path through the closest IGP neighbor (IGP cost).
9.- Prefer oldest route for eBGP paths.
10.- Prefer the path with the lowest BGP neighbor's Router ID.
11.- Prefer the path with the lowest neighbor IP address.
[ view entry ] ( 1803 views ) | print article
R1(config)#router ospf 20
R1(config-router)#area 1 virtual-link 10.30.30.30
R2(config)#router ospf 20
R2(config-router)#area 1 virtual-link 10.50.50.50
[ view entry ] ( 1519 views ) | print article
In IP-based computer networks, Virtual Routing and Forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other.
[ view entry ] ( 1340 views ) | print article
Credits to Keith!
[ view entry ] ( 1356 views ) | print article
First, the latest releases of switch software have adopted a new naming convention:
a)ipbase (Formerly SMI): Cisco IOS IP base image and device manager files. This image has Layer 2+ and basic Layer 3 routing (Static, RIP) features.
b)ipservices(Formerly EMI): Cisco IOS IP services image and device manager files. This image has Layer 2+ and full Layer 3 features.
c)ipbasek9: Cisco IOS IP base cryptographic image and device manager files. This image has the Kerberos, Secure Shell (SSH), Layer 2+, and basic Layer 3 routing features.
d)ipservicesk9: Cisco IOS IP services cryptographic image and device manager files. This image has the Kerberos, SSH, Layer 2+, and full Layer 3 features.
http://www.cisco.com/en/US/products/hw/ ... 98851.html
The 3560/3570 switches also have an advipservices image that supports a subset of IPv6.
http://www.cisco.com/en/US/products/hw/ ... 7459b.html
-----------------------------------------
https://supportforums.cisco.com/thread/143438
[ view entry ] ( 1469 views ) | print article | related link
Other solutions:
CBAC
Reflexive ACLs
[ view entry ] ( 1357 views ) | print article
ip inspect command
----------------------------------
Alternative to Reflexive ACLs. Reflexive ACLs came out first.
[ view entry ] ( 1560 views ) | print article
<<First <Back | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | Next> Last>>