- CCNP Route - BGP part 1: Internet Connectivity
- CCNP Route - BGP part 2: BGP Intro
- CCNP Route - BGP part 3: eBGP
- CCNP Route - BGP part 4: iBGP
- CCNP Route - BGP part 5: BGP path control
- CCNP Route - BGP part 6: Case Studies, Labs, FAQs
BGP configuration differs slightly when comparing the configuration of an External BGP (eBGP) peer and an Internal BGP (iBGP) peer. Many small differences in operation exist as well.
For eBGP the nexthop is always the IP of the BGP neighbor specified in th neighbor command.
For iBGP, the protocol states that the nexthop advertised by eBGP should be carried into iBGP.
- Routes learned by BGP proccess are propagated by default (but often filtered).
Some of the core operational concepts of BGP mirror those of EIGRP and OSPF:
- BGP first forms a neighbor relationship with peers
- BGP then learns information from its neighbors, placing that information in the BGP table (topology table),
- BGP analyzes the BGP table to choose the best working route for each prefix in the BGP table, placing those routes into the IP routing table.
Auto-summary (BGP)
- if enabled: BGP automatically summarizes routes to classful network boundaries
- route summarization is used to reduce the amount of routing information in routing tables
- Automatic summarization applies to connected, static, and redistributed routes.
- By default, automatic summarization is disabled and BGP accepts subnets redistributed from IGP
- To advertise and carry subnet routes in BGP when auto-summ is enabled, use an explicit network command to advertise the subnet.
- does not apply to routes injected into BGP via the network command or through iBGP or eBGP.
Only synchronized routes with no AS loop (eBGP path does not contain self AS) and a valit nex-hop will be considered for the best path route selection decision.
R&S Quick Notes – BGP http://routing-bits.com/2009/05/19/rs-quick-notes-%E2%80%93-bgp/
- When using Communities, don’t forget “neighbor send-community”
- Know your attributes and the direction which applied, when to used what.
- “aggregate address” needs a more specific prefix in the BGP table for aggregate to be advertised.
- Synchronization issue has 3 solutions, 1- Load BGP on all transit routers, 2- GRE tunnel, 3- Redistribution BGP>IGP.
- “no bgp nexthop trigger” – Disables next-hop tracking between scanner intervals.
- “no bgp fast-ext-fallover” – Force the router to wait for the dead-timer to expire, before generating notification messages , when a connected peer goes down.
- “neighbor fall-over” – Will check neighbor connenctivity between scanner intervals, aka BGP Fast Peering.
- Only the Holdtime is sent in update-msg. Two neighbors will use the lowest holdtime and then calculate the keepalive from that.
- Know your Regular Expressions
- Know the difference between Peer-Groups and Peer-Templates
eBGP Neighbor Configuration
A router participating in BGP needs to configure the following settings:
■ The router’s own ASN (router bgp <asn> global command)
■ The IP address of each neighbor and that neighbor’s ASN (neighbor <ip-address> remote-as <remote-asn> BGP subcommand)
router bgp 11Requirements for Forming eBGP Neighborships
neighbor 10.1.1.2 remote-as 1
neighbor 192.168.1.2 remote-as 3
Routers must meet several requirements to become BGP neighbors:
■ A local router’s ASN (on the router bgp asn command) must match the neighboring router’s reference to that ASN with its neighbor remote-as <asn> command.
■ The BGP router IDs (32-bit router ID, written in dotted-decimal notation) of the two routers must not be the same.
■ If configured, MD5 authentication must pass. (neighbor <neighbor-ip> password <key>)
■ Each router must be part of a TCP connection with the other router, with the remote router’s IP address used in that TCP connection matching what the local router configures in a BGP neighbor remote-as command.
IOS does not require the BGP configuration to explicitly state the source address that router uses when establishing this TCP connection, and if not explicitly configured, IOS picks an IP address on the local router.
By default, IOS chooses its BGP source IP address for a given neighbor as the interface IP address of the outgoing interface of the route used to forward packets to that neighbor.
On the process of BGP peer establishment, several things can prevent a BGP neighborship from correctly being established.
Possible reasons for this issue:
- the neighbor statement is incorrect,
= solution: correct the loopback address in the neighbor statement, or remove the update-source
- no routes to the neighbor address exist , or the default route (0.0.0.0/0) is being used to reach the peer (BGP will not form peering if only default route is present),
= solution: include a route to the next hop in the BGP neighbor statement. You can use a static or dynamic route depending on the situation.
Use the neighbor ebgp-multihop command only when the IP address you are peering to on your eBGP peer is not directly connected.
- the update-source command is missing under BGP,
= solution: configure the update-source command on both routers, or remove the update-source command and change the neighbor statement on both routers
- the lack of the ebgp-multihop command is a common mistake that keep peers from appearing,
- wrong IP address in the neighbor statement or the wrong autonomous system number. You need to check your configurations,
- unicast is broken due to one of these reasons:
-- Wrong virtual circuit (VC) mapping in an ATM or Frame Relay environment in a highly redundant network,
-- Access list is blocking the unicast or TCP packet,
-- NAT is running on the router and is translating the unicast packet,
-- Layer 2 is down.
READ MORE @ http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13752-24.html
BGP Router Identifier ( router ID )
For BGP sessions between neighbors to be established, BGP must be assigned a router ID.
The router ID is sent to BGP peers in the OPEN message when a BGP session is established.
BGP attempts to obtain a router ID in the following ways (in order of preference):
- By means of the address configured using the bgp router-id command in router configuration mode.
- By using the highest IPv4 address on a loopback interface in the system if the router is booted with saved loopback address configuration.
- By using the primary IPv4 address of the first loopback address that gets configured if there are not any in the saved configuration.
If none of these methods for obtaining a router ID succeeds, BGP does not have a router ID and cannot establish any peering sessions with BGP neighbors. In such an instance, an error message is entered in the system log, and the show bgp summary command displays a router ID of 0.0.0.0.
After BGP has obtained a router ID, it continues to use it even if a better router ID becomes available. This usage avoids unnecessary flapping for all BGP sessions. However, if the router ID currently in use becomes invalid (because the interface goes down or its configuration is changed), BGP selects a new router ID (using the rules described) and all established peering sessions are reset.
■ Configured: Use the setting of the router subcommand
bgp router-id <rid>■ Highest Loopback: Choose the highest numeric IP address of any up/up loopback interface, at the time the BGP process initializes.
■ Highest other interface: Choose the highest numeric IP address of any up/up nonloopback interface, at the time the BGP process initializes.
Issues When Redundancy Exists Between eBGP Neighbors
If a single Layer 3 path exists between eBGP neighbors - the eBGP configuration can simply use the interface IP addresses on that particular link.
When redundant Layer 3 paths exist between two eBGP neighbors, the use of interface IP addresses for the underlying TCP connection can result in an outage when only one of the two links fails.
TCP uses a concept called a socket (local IP and TCP port ex: 10.0.0.1:1035).
That IP address must be associated with a working interface (UP/UP).
If the interface whose IP address is used by BGP were to fail, then the TCP socket would fail, closing the TCP connection. As a result, the BGP neighborship can only be up when the associated interfaces also happens to be up.
Solutions:
- two neighbor commands on each router (if 2 paths exists, and one fails),
- use loopback interfaces as the TCP connection endpoints. If one of the multiple links fails, the loopback interface does not fail. As long as the two routers have working routes to reach each other’s loopback IP addresses, the TCP connection does not fail.
! neighbor-ip must be learnt by - IGP or just configure staticExample config
neighbor <neighbor-ip> update-source <loopback-ip-address>
neighbor <neighbor-ip> update-source <loopback-interface>
R1(config)# int lo0
R1(config-if)# ip add 2.2.2.2 255.255.255.0
! This command specifies that the TCP connection with the specified external peer should be established using the address on the loopback interface.
R1(config-router)# neighbor 10.1.1.2 update-source lo0
! This static route ensures that the remote peer address used for peering is reachable.
R2(config)# ip route 2.2.2.2 255.255.255.255 10.10.10.2
! eBGP update IP packets by default have TTL=1, so need to increase this value as neighbor is more then 1 hop away
R2(config-router)# neighbor 2.2.2.2 ebgp-multihop 10
eBGP Multihop Concepts
By default, when building packets to send to an eBGP peer, IOS sets the IP Time-To-Live (TTL) field in the IP header to a value of 1.
With this default action, the eBGP neighborship fails to complete when using loopback interface IP addresses. The reason is that when the packet with TTL=1 arrives at the neighbor, the neighbor discards the packet.
neighbor <neighbor-ip> ebgp-multihop <hops>BGP authentication
You can configure BGP neighbor authentication on a router so that the router authenticates the source of each routing update packet that it receives.
BGP supports message digest 5 (MD5) neighbor authentication. MD5 sends a “message digest” (also called a “hash”), which is created using the key and a message.The message digest is then sent instead of the key. The key itself is not sent, preventing it from being read by someone eavesdropping on the line while it is being transmitted.
MD5 authentication must be configured with the same password on both BGP peers. Otherwise, the connection between them will not be made.
neighbor{ip-address| peer-group-name} password string
string - Case-sensitive password of up to 25 characters. The first character cannot be a number. The string can contain any alphanumeric characters, including spaces. You cannot specify a password in the format number-space-anything. The space after the number can cause authentication to fail.
router bgp 65000
neighbor 10.64.0.2 remote-as 65500
neighbor 10.64.0.2 password v61ne0qke1336
router bgp 65500
neighbor 10.64.0.1 remote-as 65000
neighbor 10.64.0.1 password v61ne0qke1336
If a router has a password configured for a neighbor, but the neighbor router does not have a password configured, a message such as the following will appear on the console when the routers attempt to send BGP messages between themselves:
%TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236)Similarly, if the two routers have different passwords configured, a message such as the following will appear on the screen:
%TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179)
BGP Internals and Verifying eBGP Neighbors
Similar to OSPF, the BGP neighbor relationship goes through a series of states over time.
Although the Finite State Machine (FSM) for BGP neighbor states has many twists and turns, particularly for handling exceptions, retries, and failures, the overall process works as follows:
1) A router tries to establish a TCP connection with the IP address listed on a neighbor command, using well-known destination port 179.
2) When the three-way TCP connection completes, the router sends its first BGP message, the BGP Open message, which generally performs the same function
as the EIGRP and OSPF Hello messages. The Open message contains several BGP parameters, including those that must be verified before allowing the routers to become neighbors.
3) After an Open message has been sent and received and the neighbor parameters match, the neighbor relationship is formed, and the neighbors reach established state.
 |
| BGP FSM |
BGP States are:
1 – Idle - The BGP process is either administratively down or awaiting the next retry attempt (ConnectRetry timer - 60sec )
2 – Connect - The BGP process is waiting for the TCP connection to be completed (cannot determine in this state whether the TCP connection can complete.)
3 – Active - The TCP connection has been completed, but no BGP messages have been sent to the peer yet
4 – OpenSent - The TCP connection exists, and a BGP Open message has been sent to the peer, but the matching Open message hasn't yet been received from neighbor.
5 – OpenConfirm - An Open message has been both sent to and received from the other router. The next step is to receive a BGP Keepalive message (to confirm all neighborrelated parameters matched) or BGP Notification message (to learn there is some mismatch in neighbor parameters)
6 – Established - All neighbor parameters match, the neighbor relationship works, and the peers can now exchange Update messages.
 |
| BGP states |
http://www.itcertnotes.com/2012/01/bgp-finite-state-machine.html
BGP FSM
- IDLE - Router is searching routing table to see whether a route exists to reach the neighbor.
- CONNECT - Router found a route to the neighbor and has completed the three-way TCP handshake.
- OPEN SENT - Open message sent, with parameters for the BGP session.
- OPEN CONFIRM - Router received agreement on the parameters for establishing session.
- ACTIVE - Router didn't receive agreement on parameters of establishment.
- ESTABLISHED - Peering is established; routing begins.
Verifying eBGP Neighbor Status
The two most common commands to display a BGP neighbor’s status are
show ip bgp summary
show ip bgp neighbors <neighbor-id>
show tcp brief
E1# show ip bgp summaryAdministratively Controlling Neighbor Status
BGP router identifier 11.11.11.11, local AS number 11
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 60 61 26 0 0 00:45:01 6
192.168.1.2 4 3 153 159 26 0 0 00:38:13 1
E1# show ip bgp neighbors 1.1.1.1
BGP neighbor is 1.1.1.1, remote AS 1, external link
BGP version 4, remote router ID 1.1.1.1
BGP state = Established, up for 00:45:08
Last read 00:00:02, last write 00:00:38, hold time is 180, keepalive intervalis 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
...External BGP neighbor may be up to 2 hops away.
Local host: 11.11.11.11, Local port: 179
Foreign host: 1.1.1.1, Foreign port: 28995
E1# show tcp brief
TCB Local Address Foreign Address (state)
66D27FE0 192.168.1.1.179 192.168.1.2.16489 ESTAB
66D27378 11.11.11.11.179 1.1.1.1.28995 ESTAB
Cisco IOS provide possibility to administratively disable any BGP neighbor.
R1(config-bgp)# neighbor <neighbor-ip> shutdowndebug ip bgp - you can bring down neighbors and see the somewhat-readable BGP messages.
R1(config-bgp)# no neighbor <neighbor-ip> shutdown
BGP Message Summary
BGP EIGRP equivalent MeaningBGP Timers
Open Hello - Used to establish a neighbor relationship and exchange basic parameters (ASN and MD5 auth values)
Keepalive Hello - Sent on a periodic basis to maintain the neighbor relationship.
The lack of receipt of a Keepalive within the negotiated Hold timer causes BGP to bring down the neighbor connection.
Update Update - Used to exchange PAs and the associated prefix/length (NLRI) that use those attributes.
Notification N/A - Used to signal a BGP error; typically results in a reset to the neighbor relationship.
- KeepAlive Timer (def: 30s) How much time between sending keepalive packets to the hosts bgp peer. It does this to let the neighbor that it is alive and well.
- Hold Time Timer (def: 90s) The number of seconds this BGP speaker waits for a keepalive, update, or notification message before deciding that the peer is dead, and terminating its connection. This is normaly set to 3 times the keepalive time, so that the peer is given three chances to recieve a keepalive message before assuming the peer is dead.
Keepalive messages have a length of 19 bytes. Other messages may be between 19 and 4096 bytes long.
Configuring a new timer value for the hold-down timer will take effect only after the session has been (hard) reset. So, it is not possible to change the configuration of the holddown timer to avoid resetting the BGP session.
Verifying the BGP Table
To learn routes, an Enterprise BGP router does not need additional configuration beyond the configuration of eBGP neighbors.
To advertise routes to eBGP peers, particularly the public IP prefix(es) used by that Enterprise, the Enterprise BGP router needs some additional configuration.
Note: BGP also uses the term Network Layer Reachability Information (NLRI) to describe the IP prefix and length. This book uses the more familiar term prefix .
The BGP Update Message
BGP is an application layer protocol that uses TCP as its transport layer protocol – TCP Port number 179, which provides connection-oriented reliable delivery of packets. BGP assumes that its communication is reliable, and does not implement any fragmentation, retransmission, acknowledgment, sequencing, and error-recovery mechanisms as like EIGRP. BGP information is encapsulated inside TCP segments, which are then encapsulated inside IP packets. BGP is the only IP routing protocol that uses TCP as its transport layer.
BGP messages are carried within TCP segments. The minimum and maximum message sizes are 19 and 4096 octets or bytes respectively. All BGP messages share a common header. A data portion might or might not follow the header depend upon the message type.
 |
| BGP Header (from http://www.itcertnotes.com ) |
2) Length is a 2-byte field that indicates the total length of the message including the header, in octets.
3) Type is a 1-byte field that specifies the message type.
BGP uses the Update message to both announce and withdraw routes.
For example, when a router realizes that a route in the router’s BGP table has failed, that router withdraws that route by sending a BGP Update to its neighbors, listing the prefix in the list of withdrawn routes. When a router receives an Update that lists a prefix as withdrawn, that router knows that the route has failed. (Note the field near the top of the Update message that lists withdrawn routes.) That same Update message may contain other announced prefixes later in the Update message.
 |
| BGP Update packet (from http://www.itcertnotes.com ) |
Analyze BGP table
Router# show ip bgp
BGP table version is 22, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.1/32 0.0.0.0 0 32768 i
*>i 10.2.2.2/32 172.16.1.2 0 100 0 i
*bi10.9.9.9/32 192.168.3.2 0 100 0 10 10 i
*> 192.168.1.2 0 10 10 i
* i172.16.1.0/24 172.16.1.2 0 100 0 i
1) BGP show commands list the AS_Path with the first-added ASN on the right (closer to destination) and the last-added ASN on the left. BGP uses this convention because when BGP adds an ASN to the AS_Path, BGP prepends the ASN to the list, causing the new ASN to show up as the leftmost ASN in the AS_Path.
2) Origin
Origin codes: i - IGP, e - EGP, ? - incomplete (redistributed)
">" - Best route
By default, all the routes in show ip bgp are eBGP routes due to the absence of the letter i in the third character of possible output.
show ip route 192.135.250.0 255.255.255.240
check source protocol (known via ...)
Viewing Subsets of the BGP Table
When accepting full or partial BGP updates, the sheer number of BGP table entries can be much too large for the show ip bgp command to be useful:
- look at BGP table entries for specific prefixes, including the default route prefix of 0.0.0.0/0
- see routes per neighbor, and see which routes were heard from that neighbor–and which of those routes passed through any inbound route filters to make it into the BGP table
- verify whether neighboring ISPs sent full or partial updates
! List the neighbors and the number of prefixes learned per neighbor.
show ip bgp summary
!
! List possible default routes
show ip bgp 0.0.0.0 0.0.0.0
!
! List possible routes, per prefix.
show ip bgp prefix [subnet-mask]
!
! List routes learned from one neighbor, before any inbound filtering is applied.
show ip bgp neighbors <neighbor-ip-address> received-routes
!
! List routes learned from a specific neighbor, after passed any inbound filters.
show ip bgp neighbors <neighbor-ip-address> routes
!
! Lists routes advertised to a neighbor after applying outbound filtering.
show ip bgp neighbors <neighbor-ip-address> advertised-routes
Injecting Routes into BGP for Advertisement to the ISPs
Routes advertise:
There are multiple ways in which a prefix is added to a BGP table and announced to peers:
Transit routes - automatically announced (configured router is transitioning routes):
- Propagate (automatically) BGP routes learned from other iBGP or eBGP peers. (Only the best paths received from BGP peers are propagated)
Refer to BGP Best Path Selection Algorithm for more information on best path selection.
-
bgp> network - used to originate BGP routes from the autonomous
system (AS). (network
command section of
BGP
Case Studies 1 for more information)
- bgp> redistribute - Interior Gateway Protocol (IGP) or a static routes redistribution.
- bgp> aggregate-address - Understanding Route Aggregation in BGP for more information (Aggr works only if routes exist in BGP table. Aggr routeif forward if at least one more specific route exist in BGP table).
! http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html
- Redistributing from an IGP is dangerous as it increases the likelihood of flapping and instability.
- Redistributing static is more stable, but requires the CPU to peruse the routing table at a set interval to capture any changes.
- The network statement, combined with a null route, is the least expensive (in terms of CPU utilization) and most reliable (in terms of stability) option.
Default route advertise:
- bgp > network 0.0.0.0 or redistribution - will inject the default route into BGP only if the default route is currently present in the routing table, and additionally in the case of redistribution, if learned by a specific source protocol we are redistributing from.
- bgp > default-information originate - causes the default route to be artificially generated and injected into the BGP RIB, regardlessly of whether it is present in the routing table.
- bgp > neighbor x.x.x.x default-originate - does advertise the default route to the specific neighbor (only and not to all existing BGP neighbors) whether it is present in BGP or not. The default route will not be present in the BGP RIB of the router that is configured with the neighbor x.x.x.x default-originate command and so it won't be generally advertised to all BGP neighbors. At the same time, this command is similar to the default-information originate in that the default route is artificially generated and does not need to be present in the routing table.
I) Injecting Routes Using the network command
The BGP network router subcommand differs significantly from the network command used by IGPs.
For OSPF and EIGRP, the networkcommand lists parameters that the router then compares to all its interface IP addresses. If matched, the router enables the IGP routing protocol on those interfaces.
BGP does not use the network command to enable BGP on interfaces – in fact, BGP has no concept of being enabled on interfaces at all.
network 128.107.0.0 mask 255.255.224.0The BGP network command does:
- look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if a route for that exact prefix/length exists, put the equivalent prefix/length into the local BGP table.
(adds this prefix to the BGP table only if the exact prefix with that same mask exists in Router routing table).
In some cases, the Internet-connected router may not have a single route for the entire public prefix (Router might see routes for 128.107.1.0/24, 128.107.2.0/24, and so on but no route for 128.107.0.0/19 - BGP will not add this prefix to the BGP table even if routes for subsets of this range exist).
Solution:
- configure a static route for the entire range, with outgoing interface null0, on the Internet facing router,
(null0 - discard route should not cause routing problems on the local router, because of the more specific routes for subnets inside the same range of addresses.)
- use IGP route summarization to create a summary route for the entire prefix with IGP.
network command use the mask parameter, but if omitted, IOS assumes a classful network mask
network 9.0.0.0
! assumes a Class A default mask of 255.0.0.0
network 145.1.0.0
! assumes a Class B default mask of 255.255.0.0
The Effect of auto-summary on the BGP network Command
As of Cisco IOS version 12.3 mainline, BGP defaults to a setting of no auto-summary, if the configuration is changed to auto-summary, then IOS makes a small change in how it interprets the network command.
When the network command refers to a Class A, B, or C network, with no mask parameter configured, and with auto-summary configured, the router adds a route for that classful network to the BGP table:
- If the exact classful route is in the IP routing table,
- If any subset routes of that classful network are in the routing table.
! regardless of the auto-summary setting, if a route to 9.0.0.0/8 exists, the router adds 9.0.0.0/8 to the BGP tableBGP "no sync" and "no auto-summary"
network 9.0.0.0
!
! if only a subset route exists (ex: 9.1.1.0/24), but no route for exactly 9.0.0.0/8 exists,
! then the router still adds a route for the classful network(9.0.0.0/8) to the BGP table
network 9.0.0.0
auto-summary
Two first things that are considered the "BGP configuration best practice" are to disable the SYNCHRONIZATION and disable the Auto Summarization. Why?
1) Auto-summary - to enable the CLASSLESS BGP behavior
(config-router)#no auto-summary2) Synchronization - it's an old loop prevention mechanism that is no longer used, so there is no need to have it enabled. In the newer versions of IOS it's disabled by default. It was originally created to preven the BLACK HOLE Advertising. Basically the SYNC Logic is: Do not consider an iBGP route in the BGP table BEST unless the EXACT PREFIX was learned via IGP and is currently in the routing table.
R2(config-router)#no synchronization*TIP: When using OSPF and BGP in the same Network - use the same Router ID due to the Sync Logic! (link)
Network command options:
ip route 192.168.0.0 255.255.0.0 null0
router bgp 123
network 192.168.0.0
auto no-auto
mask if same-mask in static -> BGP-OK if same-mask in static -> BGP-OK
no mask any mask in static: diff mask -> NOT in BGP
/17 in static -> BGP-OK /17 same mask -> BGP-OK
/25 in static -> BGP-OK /24 Classful
II) Injecting Routes Using Redistribution
Instead of using a BGP network command to add routes to the BGP table, the Enterprise BGP routers can instead redistribute routes from an IGP into BGP:
- Inject the public address range, but not the private IP address range, into the BGP table.
- Advertise one route for the public address range, instead of any individual subnets of the range.
redistribute command to the BGP configuration to redistribute that route (ex: 128.107.0.0/19), and only that route, into BGP. If only subset routes exist, one of several additional steps need to be taken to meet the design goal to inject one route for the entire public address range.
Sample configuration with redistribute
router bgp 11To announce only 128.107.0.0/19:
redistribute ospf 1 route-map only-128-107
!
route-map only-128-107 permit
match ip address prefix 128-107
!
ip prefix-list 128-107 permit 128.107.0.0/19 le 32
E1# show ip route 128.107.0.0 255.255.224.0 longer-prefixes
128.107.0.0/24 is subnetted, 3 subnets
O 128.107.3.0 [110/3] via 10.1.1.66, 00:05:26, FastEthernet0/0
O 128.107.2.0 [110/3] via 10.1.1.66, 00:05:26, FastEthernet0/0
O 128.107.1.0 [110/3] via 10.1.1.66, 00:05:36, FastEthernet0/0
E1# show ip bgp 128.107.0.0/19 longer-prefixes
Network Next Hop Metric LocPrf Weight Path
*> 128.107.1.0/24 10.1.1.66 3 32768 ?
*> 128.107.2.0/24 10.1.1.66 3 32768 ?
*> 128.107.3.0/24 10.1.1.66 3 32768 ?
- Use IGP route summarization to create the route for the entire prefix.
- Configure a null static route (a discard route) for the entire prefix on the Internet-connected router.
- Configure BGP route summarization to make BGP advertise only the entire prefix
Aggregate - there does not have to be a exact match (ex:10.1.0.0/16), but rather as long as one of the subnets (ex: 10.1.1.0/24) is the routing table, it will be advertised.
E1(config)# router bgp 11summary-only keyword in the aggregate-address command tells IOS to suppress the advertisement the subset routes, as noted by the code “s” beside the other three routes listed at the end of the example.
E1(config-router)# aggregate-address 128.107.0.0 255.255.224.0 summary-only
E1# show ip bgp 128.107.0.0/19 longer-prefixes
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Network Next Hop Metric LocPrf Weight Path
*> 128.107.0.0/19 0.0.0.0 32768 i
s> 128.107.1.0/24 10.1.1.66 3 32768 ?
s> 128.107.2.0/24 10.1.1.66 3 32768 ?
s> 128.107.3.0/24 10.1.1.66 3 32768 ?
Before aggregate-address command was introduced the only way to create an aggregate address was:
ip route 155.4.0.0 255.255.0.0 null0Aggregate-address command creates an aggregate when at least one component route is in the BGP table by a network or by redistribution of an IGP (it is a form of route summarization).
router bgp xx
network 10.4.0.0 netmask 255.255.0.0
R4#sh ip int br | exc downDebug ip bgp updates
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 34.34.34.4 YES NVRAM up up
Loopback1 10.10.0.1 YES manual up up
!
router bgp 4
! Only applying aggregate-address command, BGP will NOT announce any routes, because in BGP topology there are none
aggregate-address 10.10.0.0 255.255.224.0
!
! What is needed
redistribute connected
R4# sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/24 0.0.0.0 0 32768 ?
*> 10.10.0.0/19 0.0.0.0 32768 i <--- originated as IGP
*> 34.34.34.0/24 0.0.0.0 0 32768 ?
!
! If summary-only is in eefect, more specific route will be suppresed
R4(config-router)# aggregate-address 10.10.0.0 255.255.224.0 summary-only
R4(config-router)#do sh ip bgp
Network Next Hop Metric LocPrf Weight Path
s> 10.10.0.0/24 0.0.0.0 0 32768 ?
*> 10.10.0.0/19 0.0.0.0 32768 i
*> 34.34.34.0/24 0.0.0.0 0 32768 ?
*Apr 29 21:42:49.675: BGP(0): route 10.10.0.0/24 upRoute origination comparison
*Apr 29 21:42:49.675: BGP(0): created aggregate route for 10.10.0.0/19
*Apr 29 21:42:49.679: BGP(0): nettable_walker 10.10.0.0/24 route sourced locally
*Apr 29 21:42:49.679: BGP(0): Revise route installing 1 of 1 routes for 10.10.0.0/19 -> 0.0.0.0(main) to main IP table
R4(config-if)#
*Apr 29 21:43:03.087: BGP(0): 34.34.34.3 send UPDATE (format) 10.10.0.0/24, next 34.34.34.4, metric 0
*Apr 29 21:43:03.087: BGP(0): 34.34.34.3 NEXT_HOP is set to self for net 10.10.0.0/19,
*Apr 29 21:43:03.091: BGP(0): 34.34.34.3 send UPDATE (format) 10.10.0.0/19, next 34.34.34.4, metric 0
R4(config)#int lo 3
R4(config-if)#ip add 2.2.2.2 255.255.255.0
R4(config-router)# redistribute connected
!
R3#bgp
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 34.34.34.4 0 0 4 ?
R4(config-router)# network 2.2.2.0 mask 255.255.255.0
!
*Apr 29 22:00:42.819: BGP(0): 23.23.23.2 rcvd UPDATE w/ attr: nexthop 23.23.23.2, origin i, localpref 100, metric 0, merged path 1, AS_PATH
*Apr 29 22:00:42.823: BGP(0): 23.23.23.2 rcvd 1.1.1.0/24
*Apr 29 22:00:42.823: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.0/24 -> 23.23.23.2(main) to main IP table
!
R3#bgp
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 34.34.34.4 0 0 4 i