I am facing two issues in BGP and i need someone to help on this. Please see both the topology and Config files.
Because the link between Vail and Telluride runs iBGP, both routers will learn about the networks in AS 300 and AS 400 through native BGP only and both AS's do reach each other. Both routers are also running OSPF with Aspen and BGP routes are redistributed into OSPF domain. Now, Aspen knows about the networks in AS 300 and AS 400. Now suppose the link between Vail and Telluride fails, both AS 300 and AS 400 can't reach each other anymore. The only solution to this is to redistribute OSPF routes to BGP on Vail and Telluride. But when i did this, only routes with "O" learned by Tahoe and Alta. In other words, Tahoe sees only 192.168.1.220, 192.168.1.196 and Alta sees only the same routes.
Why the redistribution from OSPF to BGP didn't advertise the O E2 routes?
This actually was discussed before but i still can't get it. It is not an actual issue.
It is about "Syncronization".
I know that we've said many times to turn on Sync. when we do redistribution from BGP to an IGP to make sure that the routes are installed correctly in the IGP routing table. However, as you notice in the configuration, i didn't enable Sync. on Vail and Telluride for a long time and redistribution still works fine.
So what in heaven is the benefit of Sync.? ... I know that we discussed this before but practically everything works. The thing is that i don't feel it.
A router running Cisco IOS Release 12.0 or later does not select or use an iBGP route unless both of the following are true:
•The router has a route available to the next-hop.
•If synchronization is enabled, the router has received synchronized routes from an IGP.
BGP bases it's decision first on whether a path is loop free, then on the policies indicated by the path attributes along with the policies configured on the router. The following summarized how BGP chooses the best path to a given destination.
1 If the next hop is not reachable through an IGP route installed in the routing table, do not consider this prefix for installation in the routing table.
If the only route you have to the next hop indicated in the NEXT_HOP attribute of a prefix is learned through iBGP, the route will oscillate in the routing table. It will be installed by BGP, then removed about 60 seconds later, only to be reinstalled momentarily after it is deleted.
2 If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider the route."
I.e., imagine in your case:
The line between Vail and Telluride fails.
Your Telluride router would receive an iBGP prefix for some AS 300 from Vail.
It would forward a packet to Aspen (the direct line to Vail is down).
In a case the Aspen router does not know the AS 300 prefix, it would drop the packet with AS 300 destination address.
When BGP synchronization is ON, the Telluride router will not use the iBGP prefix until it receives the same prefix via OSPF. Then it is sure the IGP router(s) know how to route to the AS 300 destination.
And only after that it will aslo advertise the AS 300 prefix to the eBGP neighbor Alta.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...