redistribute static subnets command is used to redistribute static routes in OSPF, However static default route (ip route 0.0.0.0 0.0.0.0…) is not injected in to OSPF topology database. IF you want to redistribute static route in OSPF, following command should be used with in the router ospf configuration.
default-information originate always
Incase you issue above command without static route being configured, router will inject type 5 LSA for the default route in OSPF topology database.
what cisco simulator !!! Are you crazy… No I am not!
My frenz never believed me that I am using a cisco simulator for my CCIE lab practice. My simulator can support direct images of 7200 and now 3600 series. Hard to believe!
check this out
A pretty useful document for better understanding of BGP.
Introduction
This document contains frequently asked questions (FAQs) about Border Gateway Protocol (BGP).
Q. How do I configure BGP with the use of a loopback address?A. The use of a loopback interface ensures that the neighbor stays up and is not affected by
malfunctioning hardware.
BGP uses the IP address configured on the physical interface directly connected to the BGP
peer as the source address when it establishes the BGP peering session, by default. Issue the
neighbor <ip address> update−source <interface> command in order to change this
behavior and configure the BGP that speaks to the router to establish peering with the use of a
loopback address as the source address.
Refer to Sample Configuration for iBGP and eBGP With or Without a Loopback Address for
more information.
Q. What is the order of preference of attributes when some or all are
applied to one neighbor in BGP?
A. The order of preference varies based on whether the attributes are applied for inbound
updates or outbound updates.
For inbound updates the order of preference is:
route−map 1.
filter−list 2.
prefix−list, distribute−list 3.
For outbound updates the order of preference is:
prefix−list, distribute−list 1.
filter−list 2.
route−map 3.
Note: The attributes prefix−list and distribute−list are mutually exclusive, and only one command (neighbor prefix−list or neighbor distribute−list) can be applied to each inbound
or outbound direction for a particular neighbor.
Q. What does a next hop of 0.0.0.0 mean in the show ip bgp command
output?
A. A network in the BGP table with a next hop address of 0.0.0.0 means that the network is
locally originated via redistribution of Interior Gateway Protocol (IGP) into BGP, or via a
network or aggregate command in the BGP configuration.
Q. What are the well known communities of the BGP community
attribute?
A. The community attribute is a transitive, optional attribute designed to group destinations in
a certain community and apply certain policies (such as accept, prefer, or redistribute). This
table shows the well known BGP communities.
| Community | Description |
|---|---|
| Local-AS | Use in confederation scenarios to prevent sending packets outside the local autonomous system (AS). |
| no-export | Do not advertise to external BGP (eBGP) peers. Keep this route within an AS. |
| no-advertise | Do not advertise this route to any peer, internal or external. |
| none | Apply no community attribute when you want to clear the communities associated with a route. |
| internet | Advertise this route to the internet community, and any router that belongs to it. |
.
Q. What formats can I use to configure the BGP community attribute?
A. In Cisco IOS® Software release 12.0 and later, you can configure communities in three
different formats called decimal, hexadecimal, and AA:NN. By default, IOS uses the older
decimal format. In order to configure and display in AA:NN, where the first part is the AS
number and the second part is a 2−byte number, use the ip bgp new−format global
configuration command.
Note: Although the community attribute can be represented in decimal, hexadecimal, or
AA:NN, it is still a 32−bit number. For example, any of these three configuration commands
specify the community 30:20 (AS 30, number 20):
set community 30:20 ¨
set community 0x1E0014 ¨
set community 1966100 ¨
Regardless of which command you use, the community displayed in the router configuration
file and the BGP table is 30:20.
Refer to the Community Attribute section of BGP Case Studies, and Using BGP Community
Values to Control Routing Policy in Upstream Provider Network for more information.
Q. How does BGP behave differently with auto−summary enabled or
disabled?
A. Auto−summary behavior has changed across Cisco IOS releases. Initially, auto−summarywas enabled by default. However, with Cisco bug ID CSCdu81680 ( registered customers only)
this behavior has changed. In the latest Cisco IOS, auto−summary is disabled by default.
When auto−summary is enabled, it summarizes the locally originated BGP networks to their
classfull boundaries. (Auto−summary is enabled by default in BGP). When auto−summary is
disabled, the routes introduced locally into the BGP table are not summarized to their
classfull boundaries. When a subnet exists in the routing table and the following three
conditions are satisfied, then any subnet of that classfull network in the local routing table
will prompt BGP to install the classfull network into the BGP table.
Classfull network statement for a network in the routing table ¨
Classfull mask on that network statement ¨
Auto−summary enabled ¨
For example, if the subnet in the routing table is 75.75.75.0 mask 255.255.255.0, and you
configure network 75.0.0.0 under the router bgp command, and auto−summary is enabled,
BGP introduces the classfull network 75.0.0.0 mask 255.0.0.0 in the BGP table.
If these three conditions are not all met, then BGP does not install any entry in the BGP table
unless there is an exact match in the local routing table.
Note: If the AS that performs BGP does not own the complete classfull network, Cisco
recommends that you disable auto−summary using the no auto−summary command under
router bgp.
Q. How can I verify if a BGP router announces its BGP networks and
propagates them to the global BGP mesh?
A. Use these commands to check if the IP blocks are announced to the directly connected
ISP:
The show ip bgp neighbors [address] advertise−routes command shows which
messages are being sent.
¨
The show ip bgp neighbors [address] routes command shows which messages are
being received.
¨
Note: The show ip bgp neighbors [address] advertise−routes command does not take into
account any outbound policies you may have applied. In future Cisco IOS versions the
command output will be changed to reflect the outbound policies.
In order to verify how the IP blocks get propagated to the global BGP mesh via the directly
connected ISP, log onto a route server on the Internet and look for the BGP entries of the
prefix in the route server.
Q. When and how should I reset a BGP session?
A. Clear a BGP session when you change the inbound/outbound policy for this session. Use
the clear ip bgp x.x.x.x soft out command to clear a BGP session in order to bring outboundpolicy changes into effect. Use the
clear ip bgp x.x.x.x command in order to clear a BGP
session to bring inbound policy changes into effect. If the neighbor has the soft
reconfiguration capability, you can use the clear ip bgp x.x.x.x soft in command.
Note: With Cisco IOS Software Release 12.0 and later, a new BGP Soft Reset Enhancement
feature is introduced. Refer to BGP Soft Reset Enhancement for more information.
Q. When I perform MD5 Authentication for BGP through a PIX, is there
anything special that needs to be done on the PIX?
A. Yes. When a BGP ‘neighbor … password …’ is configured, MD5 authentication is used on
the TCP psuedo−IP header, TCP header, and data (refer to RFC 2385 ). TCP uses this data,
which includes the TCP sequence and ACK numbers, and the BGP neighbor password, to
create a 128−bit hash number. The hash number is included in the packet in a TCP header
option field. By default, the PIX offsets the sequence number by a random value per TCP
flow. On the sending BGP peer, TCP uses the original sequence number to create the 128−bit
MD5 hash number and includes this hash number in the packet. When the receiving BGP peer
gets the packet, TCP uses the PIX modified sequence number to create a 128−bit MD5 hash
number and compares it to the hash number included in the packet. Because the TCP
sequence value was changed by the PIX, the hash is differentTCP on the BGP neighbor
drops the packet and logs an MD5 failed message similar to this:
%TCP−6−BADAUTH: Invalid MD5 digest from 10.28.0.9:1778 to 10.156.50.10:179
Use the norandomseq keyword to solve this problem and stop the PIX from offsetting the
TCP sequence number with this command:
static (inside,DMZ−ICE) 10.0.0.0 10.0.0.0 netmask 255.0.0.0 norandomseq
Q. What is an autonomous system (AS) number and how do I obtain
one?
A. AS numbers are globally unique numbers that are used to identify ASes, and which enable
an AS to exchange exterior routing information between neighboring ASes. An AS is a
connected group of IP networks that adhere to a single and clearly defined routing policy.
There are a limited number of available AS numbers. Therefore, it is important to determine
which sites require unique AS numbers and which do not. Sites that do not require a unique
AS number should use one or more of the AS numbers reserved for private use, which are in
the range from 64512 to 65535. Access the AS Number Registration Services Website to
obtain an AS number.
Q. What is the BGP path selection criteria?
A. BGP path selection criteria is documented in BGP Best Path Selection Algorithm.
Q. What is the difference between always−compare−med and
deterministic−med?
A. A complete explanation of the differences between these commands is documented in
How the bgp deterministic−med Command Differs from the bgp always−compare−med
Command.
Q. Do internal BGP sessions modify the next hop?
A. Internal BGP (iBGP) sessions preserve the next hop attribute learned from eBGP peers.
This is why it is important to have an internal route to the next hop. The BGP route is
otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the
network that the next hop belongs to in the IGP or use the next−hop−self neighbor command
to force the router to advertise itself, rather than the external peer, as the next hop. Refer to
the BGP Nexthop Attribute section of BGP Case Studies for a more detailed explanation.
Q. Do eBGP sessions between confederations modify the next hop?
A. No, eBGP sessions between confederation sub−ASes does not modify the next hop
attribute. All iBGP rules still apply to have the whole AS behave as a single entity. The
metric and local preference values also remain unaltered among confederation eBGP peers.
Refer to the BGP Confederation section of BGP Case Studies for more information about
confederations.
Q. In eBGP sessions, which IP address is sent as the next hop?
A. In eBGP peering, the next hop is the IP address of the neighbor that announces the route.
However, when the route is advertised on a multi−access media (such as Ethernet or Frame
Relay), the next hop is usually the IP address of the router interface connected to that media,
which originated the route. Refer to the BGP Nexthop Attribute of BGP Case Studies for a
more detailed explanation.
Q. Does the route reflector change the next hop attribute of a reflected
prefix?
A. By default, the next hop attribute is not changed when a prefix is reflected by route reflector. However, you can use the neighbor next−hop−self command to change the
attribute of the next hop for prefixes reflected from an eBGP peer to any route reflector client.
Q. How can I announce a prefix conditionally to one ISP only when I lose
the connection to my primary ISP?
A. BGP advertises routes from its BGP table to external peers by default. The BGP
conditional advertisement feature provides additional control of route advertisement
depending on the existence of other prefixes in the BGP table. Normally, routes are
propagated regardless of the existence of a different path. The BGP conditional advertisement
feature uses the non−exist−map and advertise−map configuration commands to track routes
by the route prefix. If a route prefix is not present in the non−exist−map command, the routespecified by the
advertise−map command is announced. Refer to the Configuring BGP
Conditional Advertisement section of Configuring BGP for more information.
Q. How much memory should I have in my router to receive the
complete BGP routing table from my ISP?
A. The amount of memory required to store BGP routes depends on many factors, such as the
router, the number of alternate paths available, route dampening, community, the number of
maximum paths configured, BGP attributes, and VPN configurations. Without knowledge of
these parameters it is difficult to calculate the amount of memory required to store a certain
number of BGP routes. Cisco typically recommends a minimum of 128 MB of RAM in the
router to store a complete global BGP routing table from one BGP peer. However, it is
important to understand ways to reduce memory consumption and achieve optimal routing
without the need to receive the complete Internet routing table. Refer to Achieve Optimal
Routing and Reduce BGP Memory Consumption for more detailed information.
Q. What are the benefits of configuring BGP peer groups?
A. The major benefit of specifying a BGP peer group is that it reduces the amount of system
resources (CPU and memory) used in an update generation. It also simplifies BGP
configuration since it allows the routing table to be checked only once, and updates to be
replicated to all other in−sync peer group members. Depending on the number of peer group
members, the number of prefixes in the table, and the number of prefixes advertised, this can
significantly reduce the load. Cisco recommends that you group together peers with identical
outbound announcement policies. Refer to BGP Peer Groups for more detailed information.
Q. What is synchronization, and how does it influence BGP routes
installed in the IP routing table?
A. If your AS passes traffic from another AS to a third AS, BGP should not advertise a route
before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates
the route within the AS and then advertises it to external peers. A BGP router with
synchronization enabled does not install iBGP learned routes into its routing table if it is not
able to validate those routes in its IGP. Disabling synchronization using the no synchronization command under router bgp prevents BGP from validating iBGP routes in
IGP. Refer to BGP Case Studies: Synchronization for a more detailed explanation.
Q. How do I know which Cisco IOS software release supports a
particular BGP feature?
A. Use the Cisco IOS Software Advisor ( registered customers only) to quickly find which Cisco
IOS software release supports your feature.
Q. How can I set the Multi Exit Discriminator (MED) value on prefixes
advertised to eBGP neighbors to match the IGP next hop metric?
A. The set metric−type internal route−map configuration command causes BGP to
advertise a MED that corresponds to the IGP metric associated with the next hop of the route.
This command is available in Cisco IOS Software Release 10.3 and later.
Q. What is the default BGP ConnectRetry timer, and is it possible to tune
the BGP ConnectRetry timer?
A. The default BGP ConnectRetry timer is 120 seconds. Only after this time passes does the
BGP process check to see if the passive TCP session is established. If the passive TCP
session is not established, then the BGP process starts a new active TCP attempt to connect to
the remote BGP speaker. During this idle 120 seconds of the ConnectRetry timer, the remote
BGP peer can establish a BGP session to it. Presently the Cisco IOS ConnectRetry timer
cannot be changed from its default of 120 seconds.
Q. What does r RIB−Failure mean in the show ip bgp command output?
R1> show ip bgp
BGP table version is 5, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i − internal,
r RIB−failure
Origin codes: i − IGP, e − EGP, ? − incomplete
Network Next Hop Metric LocPrf Weight Path
r> 6.6.6.0/24 10.10.13.3 0 130 0 30 i
*> 7.7.7.0/24 10.10.13.3 0 125 0 30 i
When BGP tries to install the bestpath prefix into Routing Information Base (RIB) (for
example, the IP Routing table), RIB might reject the BGP route due to any of these reasons:
Route with better administrative distance already present in IGP. For example, if a
static route already exists in IP Routing table.
¨
Memory failure. ¨
The number of routes in VPN routing/forwarding (VRF) exceeds the route−limit
configured under the VRF instance.
¨
In such cases, the prefixes that are rejected for these reasons are identified by r RIB Failure in the show ip bgp command output and are not advertised to the peers. This
feature was first made available in Cisco IOS Software Release 12.2(08.05)T.
Q. How can I redistribute internal BGP (iBGP) learned default−route
(0.0.0.0/0) route into EIGRP/OSPF/IS−IS?
A. The redistribution of iBGP routes into Interior Gateway Protocol (IGP)Enhanced Interior
Gateway Routing Protocol/Open Shortest Path First/Intermediate System−to−Intermediate
System (EIGRP/OSPF/IS−IS)can cause routing loops within the Autonomous System,
which is not recommended. By default, iBGP redistribution into IGP is disabled. Use the bgpredistribute−internal command to enable redistribution of iBGP routes into IGP.
Precautions should be taken to redistribute specific routes using route−maps into IGP. A
sample configuration for redistributing a iBGP learned default route 0.0.0.0/0 into EIGRP is
shown in this output. Configurations for OSPF/IS−IS are similar.
router bgp 65345
[…]
bgp redistribute−internal
!
router eigrp 10
[…]
redistribute bgp 65345 route−map check−def
!
ip prefix−list def−route seq 5 permit 0.0.0.0/0
!
route−map check−def permit 10
match ip address prefix−list def−route
There are three most important keywords which we should have in mind while setting up BGP neighbor relationship. Even sometimes when we have successful BGP relationship, we are not able to see routes in the routing table. Following are the three important keywords.
1)ebgp-multihop :- In EBGP, neighbor relationships are only formed if we have directly connected networks. We would require to use ebgp-multihop keyword with neighbor statement so that neighbors which are not directly connected can form relationship with each other. We need to specify a number with ebgp-multihop keyword, number can be between 1-255. This number represents how many hop counts is the router away.
2)update-source. We need to specify the interface which will be used to update neighbor table incase routers are not directly connected. Without update-source we will not be able to form BGP neighbor relationships. update-source keyword will update the interface which will be used to form neighbor relationship. see configuration example below for better understanding.
3) next-hop-self:- When ebgp relation replicates , next hop always changes.IBGP routers only connected with other ibgp routers in same AS will not be able to talk with routers outside the AS, if they are not directly connected with each other. We would require a next-hop-self keyword in the ibgp router which is directly connected with ebgp neighbor so that other router in same AS (IBGP) can talk with ebgp routers. Refer to configuration examples below:-
Lets assume that we have three routers and we have to setup a ebgp relationship in between them. Router A ( AS :- 34 Serial0 192.168.1.1 , loopback0 1.1.1.1) , RouterB ( AS 34, loopback0 2.2.2.2 , Serial0 192.168.1.2 , Serial1 172.16.1.1), RouterC ( AS 400 , loopback0 3.3.3.3, Serial0 172.16.1.2)
Lets start configuring Router A
router BGP 34 –> As soon as we type 34 BGP process will start in the background
neighbor 192.168.1.2 remote-as 34 –> Bgp will know that this is IBGP looking at AS
Router B
router BGP 34
neighbor 192.168.1.1 remote-as 34
neighbor 172.16.1.2 remote-as 400 –> neighbor relationship with ebgp peer.
neighbor 3.3.3.3 remote-as 400
neighbor 3.3.3.3 ebgp-multihop 255 –> 255 is number of hops that neighbor is away. we can use any number from 1-255, it can be more specific by using 1 or 2 but my personal fav is 255 as it avoids confusion.
neighbor 3.3.3.3 update-source loopback 0 –> Here is the idea, when its sourcing the packets its sourcing it from serial interface, we need to inform the otherside that source interface is not serial interface, it is looback interface so that it cann match ip ip’s with the right interface and form neighbor relationship.
we would require to do similar configuration on router c
router bgp 400
neighbor 172.16.1.1 remote-as 34
neighbor 2.2.2.2 remote-as 34
neighbor 2.2.2.2 ebgp-multihop 255
neighbor 2.2.2.2 update-source loopback 0
Now after forming the neighbro relationships we’ll use network commands to add neighbors in routing table. Network command in BGP is bit different then Network command in other routing protocols. we ‘ll need to define mask keywork with network command in order to advertise clasless network where as if it is using a default mask we can ignore the same.
Example
Router C
router bgp 400
neighbor 172.16.1.0 mask 255.255.255.0
note:- i cannot use network 172.16.0.0 command without mask keyword as it will treat this as class B network. For any customised subnetting scheme we ‘ll need to specify subnet mask with mask keyword in network command.
Even after configuring above, Router A will not be able to talk with Router C. If we will use show ip bgp command on Router A. we’ll see that it has a valid route for Router C but it will not be able to ping router c. This is because next hop will be 3.3.3.3 which is not directly connected with Router A. . First thing which will come in our mind is that rule of synchronisation has taken in to effect but even after disabling synchronisation between router a and router B, Router C will not be reachable. we would need a special command on Router B so that all IBGP peers of AS 34 can talk with AS 400
To troubleshoot this we can use “debug ip bgp updates” but before using this debug we should use ” clear ip bgp *” command. We’ll see that it will show us that there is no valid path for networks in Router C. Next hop should be Router B but in the updates it will show next hp as router c. to avoid the we will use next-hop self keyword in Router B.
Router B
router bgp 34
neighbor 192.168.1.1 next-hop-self
When Router B is sending an update to Router A it is sending the update without changging its next hop so router A will receive next hop as Router C which is not directly connected. To avoid this we will use next-hop-self command in Router B so that router A should receve valid route.
At last i have made up my mind to sit for ccie R&S written by early August. I am starting a tips & tricks section for dynamic routing protocols. I will start with EIGRP and then gradually move towards OSPF & BGP.
–EIGRP uses DUAL ( Diffused update algorithm). Now what is DUAL? This fancy name is being used by cisco as a kind of marketing tool. Cisco calls EIGRP as a hybrid protocol. It has features of both distance vector & link state protocol. EIGRP topology table will always keep a feasible successor. Feasible successor is nothing but a backup route.
Lets say we have two links. One is 56k & other is a T1 link. Now EIGRP topology table will contain t1 as a primary route and 56k link as a feasible route. The difference between EIGRP and other dynamic routing protocols is that due to the feaible successor already in the topology table,Convergence time is very fast.
Incase of T1 link failiure, in fraction of seconds 56k link will become a primary route for EIGRP. This is the magic of DUAL, in other protocols like OSPF it will take atleast 50 secs to converge as it has to do everything from the scratch.
-EIGRP route metrics :- All of us have known about k values in EIGRP. but what are ‘k’ values?K values are the meterics being used in EIGRP to influence routes. routes in EIGRP can be influenced with 5 different ‘k’ values. k1,k2,k3,k4 & k5. Bandwidth and delay are the default metrics in EIGRP but we have load, reliability and MTU which can also influence routes in EIGRP. Cisco doesn’t recommend enabling other ‘k’ values like load. the reason behind that is that it can increase cpu cycles and thus can slow down the whole process.
IF we have two links with equal cost (bandwidth), both eigrp & ospf will automatically load balance between the two links. Incase we need to prefer one link over other, we will have to change the bandwidth statement ( i.e. we ‘ll lie to the router) to a lower bandwidth so that the other link will be preffered over this link. This practice will definitely resolve our routing problem but it can lead to other problems. bandwidth statement is not only used by routing protocols but also used by qos for evaluating/priortizing traffic. changing bandwidth can have adverse effects.
In eigrp we have a feature called delay we can simply go under interface configuration mode and change delay. its a cool feature as even if bandwidth is same for 2 interfaces, delay will help us in making one link as primary and other secondary by simply increasing value of delay.
Now its a time for EIGRP tip. Not many people know about this command but using this command we can really do wonders in EIGRP.
metric weights tos k1 k2 k3 k4 k5
where k1 is bandwidth, k2 is load, k3 is delay, k4 is reliability and k5 is MTU. This command is used under router configuration mode.
default usage of this commmand is meteric weights 0 1 0 1 0 0. by default only bandwidth and delay is accounted for metric calculation.
Use this command to alter the default behavior of EIGRP routing and metric computation and allow the tuning of the EIGRP metric calculation for a particular type of service (ToS).
If k5 equals 0, the composite EIGRP metric is computed according to the following formula:
metric = [k1 * bandwidth + (k2 * bandwidth)/(256 – load) + k3 * delay]
If k5 does not equal zero, an additional operation is performed:
metric = metric * [k5/(reliability + k4)]
Bandwidth is inverse minimum bandwidth of the path in BPS scaled by a factor of 2.56 * 1012. The range is from a 1200-bps line to 10 terabits per second.
Delay is in units of 10 microseconds. The range of delay is from 10 microseconds to 168 seconds. A delay of all ones indicates that the network is unreachable.
The delay parameter is stored in a 32-bit field, in increments of 39.1 nanoseconds. The range of delay is from 1 (39.1 nanoseconds) to hexadecimal FFFFFFFF (decimal 4,294,967,040 nanoseconds). A delay of all ones (that is, a delay of hexadecimal FFFFFFFF) indicates that the network is unreachable.
–Troubleshooting EIGRP
Cisco has set of flow charts which I have personally found the best way to troubleshoot EIGRP.
–Summarising EIGRP routes:-
We can use following command to summarise EIGRP routes. Under interface config mode, issue following command
ip summary address eigrp x.x.x.x subnet-mask.
–EIGRP or OSPF
EIGRP has a faster convergence time as compare to OSPF. Administrative distance for internal EIGRP is 90 and that of external EIGRP is 170.
OSPF is still widely used dynamic protocol as compare to EIGRP, this is because EIGRP is cisco properietory and thus runs only on cisco routers where as OSPF is vendor independent routing protocol.
There are times when route propagated in BGP doesn't exist. As we know that even in link down situation, BGP takes its own sweet time to converge. In this kind of scenario we need to clear advertised routes and in some cases we use the following command
clear ip bgp *
You can also verify the advertised routes with following command
sh ip bgp neighbors A.B.C.D advertised-routes
Even in cases when you change the inbound/outbound policy , you need to reset your BGP session.But using clear ip bgp * can impact all other links as BGP will create routing table from scratch. This is as good as rebooting the router. To minimise impact we can use following command.
clear ip bgp A.B.C.D soft out –> When you make changes in outbound policy
and use
clear ip bgp A.B.C.D soft in –> When you make changes in inbound policy .
There is a way to tag a route advertisements with additional information. you can tag route using bgp communities. A community defines a property of a prefix, in such a way that a router can be configured to treat all prefixes with a certain community in a certain way, for example, to give those a higher preference. This way, one does not have to build an access list to match all the prefixes explicitly. A prefix can be tagged with multiple communities, and a community can be attached to multiple prefixes.RFC1997 gives you more details on BGP communities.
Most important communities are NO_ADVERTISE and NO_EXPORT, indicating that a prefix should not be re-advertised beyond the router or the autonomous system receiving the prefix respectively. The latter is useful if you want to announce a more-specific prefix to one of your upstreams without polluting the global routing table.
One application of communities is described in RFC 1998. This RFC describes a scenario in which two ISPs provide each other with backup connectivity. Using communities, they can tag the prefixes for which they provide backup routing. The upstream provider can then apply a lower local preference to these routes so that in the normal case traffic is not routed via the backup path. Of course, this assumes some cooperation of the upstream provider, but the level of cooperation is less than would be required if the usptream provider would have to create explicit access lists for the prefixes or ASes involved.
WARNING: Setting the no-export, no-advertise, or no-export-subconfed communities can have the (possibly unwanted) side effect that no routes are announced, even if there are other routes that would otherwise be eligible for announcement.
For instance, if we have 2 ISP's ISP A and ISP B,if you set the no-advertise community on routes announced to ISP B, other customers of ISP Bwon't see these routes because they aren't advertised. This is as intended. But routes with the same NLRI that ISP B has learned from ISP A will not be advertised either, because ISP B considers the directly received routes with the no-advertise community best, and only the best route is eligible for further announcement over BGP.
Lot of organizations has a problem of using BGP for load balancing. Well, the question here is whether you require BGP or not. Some organistations with multiple links to the single service provider doesn't use BGP because of unawareness of RFC2270.
Border Gateway Protocol (BGP) is mainly used by ISP's and enterprises for connecting their autonomous systems (AS) to multiple upstream providers, peers, and customers. An organization wishing to obtain better connectivity can do so by connecting to more than one upstream provider (multi-homing) and announcing its address space using BGP.When using more than one connection to the same upstream provider, BGP is a logical choice for the routing protocol, since it supports load balancing and redundancy, and provides a clear separation between responsibilities and administrative domains of the provider and the customer, unlike an IGP would. However, the AS allocation guidelines (described in RFC 1930) preclude the use of a dedicated AS number for an organization connected in that way, since there is no need to exchange routing information with more than one party, i.e., there is no separate routing policy.RFC 2270 proposes to use a single AS number for all customers multi-homed to the same (single) provider, preferably one of the private AS numbers, 64512 to 65535. In this way, there is no unnecessary use of AS numbers by organizations who do not strictly need them. The customer can use BGP to announce its address space, which will then be announced to the rest of the world by its provider. Despite the non-unique (and possibly private) AS number, one still has the advantages of BGP such as a fine grained control over routing announcements and preferences.The RFC also describes some of the implications of using this scheme, such as the need to announce a default route to the customer AS, effects of changes in connectivity, as well as points regarding aggregation and registering routes in a registryHere is a detailed config.
If you are a network engineer working for a backbone ISP team, you would always like to know which autonomous system (AS) announces a given IP address. One way to do this is by querying the whois server of a routing registry such as RADB or RIPE, and looking for the origin attribute of a route object. However, not all networks properly register their route objects, so the information might not be available or may be outdated.
Another method is by looking at the actual BGP route table for the origin AS of a prefix. You could do this on your own BGP speaking routers or on a public route server with the "show ip bgp" command (or equivalent), or by using one of the public looking glasses on the web. However, this method is cumbersome, especially if you want to quickly look up something or if you have a large number of addresses that you want to analyze with a script.
Yet there is another service which was announced by the RIPE RIS project. Their whois server can be queried using "whois -h riswhois.ripe.net", and returns results in RPSL like format (as used by the RIPE whois database itself). The data is gathered from route collector boxes in various locations. For more information about this service, see this web page
Many of the newbies get confused while configuring OSPF network statements. Wild card masks are sometimes a pain. Although I have already covered wild card masks usage in my earlier post. Here is an example in lieu to OSPF.
OSPF usage
router ospf process id
network x.x.x.x wildcardmask area area-id
Example:-
interface serial0
ip address 172.30.105.86 255.255.255.252
To add serial0 in OSPF, command will be
router ospf 100 —-> 100 is a process id
network 172.30.105.84 0.0.0.3 area 0
Here we have used wild card mask. but you know we can accomplish the same task with following:-
router ospf 100
network 172.30.105.86 0.0.0.0 area 0
Here we are directly advertising interface address rather then network. This is a convenient method as you don't have to always worry abt wild card masks.
Cisco Tips & Tricks 