Showing posts with label bgp neighbor options. Show all posts
Showing posts with label bgp neighbor options. Show all posts

Saturday, November 22, 2008

BGP - Local AS notes

Here is the topology:

R6[AS256]-----R9[AS9999]=====BB3[AS3561]

We will be looking at the BGP tables of R6 and BB3 as we test each option of the local-as neighbor configuration.

1) LOCAL-AS

R9 has local-as configured with as 19999. R6 sees routes as follows, with 19999 in between BB2 and R9 real AS number.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999
R9
#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?


BB3 sees routes from R9 in the same way, as if AS19999 was connected between itself and R9:

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i



2) LOCAL-AS NO-PREPEND

With the no-prepend option, R6 does not see 19999 in the path:

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend
R9#


R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?


This command has no impact on the routes BB3 receives. They look the same.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i



3) LOCAL-AS NO-PREPEND REPLACE-AS

With the Replace-as, everything looks the same as the last command on R6.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend replace-as
R9#


R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?


However on BB3 we now see a difference as 9999 is no longer in the path.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 256 i

Saturday, October 18, 2008

BGP - peer session templates

I had a task to configure bgp timers on R2 for the peering session to R1. I was not to use "timers bgp" or any neighbor commands withe the word "timers". I immediately thought of peer-session templates which was something I came across while reading the DocCD one day. Here is how it works. We are on R2:

R2(config)#router bgp 2456

R2(config-router)#template ?
peer-policy Template configuration for policy parameters
peer-session Template configuration for session parameters

R2(config-router)#template peer-session TEMPLATE-R1

R2(config-router-stmp)#timers 30 90
R2(config-router-stmp)#exit

R2(config-router)#neighbor 150.21.21.1 inherit ?
peer-policy Inherit a peer-policy template
peer-session Inherit a peer-session template

R2(config-router)#neighbor 150.21.21.1 inherit peer-session TEMPLATE-R1


Now we must clear bgp then debug bgp keepalives to verify. Here we can see that R2 is sending keepalives to R1 every 30 seconds, while the other peers are still at 60 seconds.

*Oct 18 18:28:15.486: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:28:15.486: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:28:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:28:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:01.166: BGP: 150.20.25.5 sending KEEPALIVE (io)
*Oct 18 18:29:01.490: BGP: 150.20.25.5 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:09.946: BGP: 150.20.246.4 sending KEEPALIVE (io)
*Oct 18 18:29:09.950: BGP: 150.20.246.4 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:15.654: BGP: 150.20.246.6 sending KEEPALIVE (io)
*Oct 18 18:29:15.654: BGP: 150.20.246.6 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:15.654: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:29:15.654: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:29:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:01.166: BGP: 150.20.25.5 sending KEEPALIVE (io)
*Oct 18 18:30:01.490: BGP: 150.20.25.5 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:09.946: BGP: 150.20.246.4 sending KEEPALIVE (io)
*Oct 18 18:30:09.946: BGP: 150.20.246.4 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:15.654: BGP: 150.20.246.6 sending KEEPALIVE (io)
*Oct 18 18:30:15.654: BGP: 150.20.246.6 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:15.654: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:30:15.658: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:30:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0

BGP - Allowas-in with number of occurrences

I ran into this BGP issue on IPexpert volume 2 Lab 4 today. Cat 1 is in AS 500. There are 3 other ASes, but CAT1 needs to see all of these as AS8888. Confederations right? For 2 of the ASes that is right, but the task says NOT to use a sub-as for AS78. Here is the AS map:

As500----As100----AS2456====AS78

AS2456 has 2 connections (R5 and R6) to AS78 (R7).

On R5 and R6 I have this ( I am allowed to use confederations on AS 2456):

router bgp 2456
bgp confederation identifier 8888
neighbor 150.20.56.7 remote-as 8888


on R7 I have this:

router bgp 78
neighbor 150.20.56.5 remote-as 8888
neighbor 150.20.56.5 local-as 8888
neighbor 150.20.56.5 allowas-in
neighbor 150.20.56.6 remote-as 8888
neighbor 150.20.56.6 local-as 8888
neighbor 150.20.56.6 allowas-in


Works great so far:

R7#show ip bgp sum | be Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
150.10.8.8 4 78 55 64 64 0 0 00:35:46 1
150.20.56.5 4 8888 112 121 64 0 0 00:01:07 5
150.20.56.6 4 8888 109 116 64 0 0 00:01:10 5


But notice the prefix I am learning from R8 (ibgp peer with R7). That prefix does not get installed by R5 and R6 because it has AS 8888 in the path. Here is the debug from R6:

R6#debug ip bgp update
*Oct 18 17:46:11.270: BGP(0): 150.20.56.7 rcv UPDATE about 200.200.200.0/24 -- DENIED
R6(config-rout due to: AS-PATH contains our own AS;


How do we allow R6 and R5 to accept this route? By using "allowas-in" option of the neighbor command. However, because we don't want R6 to learn routes that passed from R5 to R7 we set a maximum on the number of occurrences of the AS, which is 1.

R5 and R6:

router bgp 2456
neighbor 150.20.56.7 allowas-in 1


Now here is the same debug on R6:

*Oct 18 17:56:48.366: BGP(0): Revise route installing 1 of 1 routes for 200.200.200.0/24 -> 150.20.56.7(main) to main IP table

Let's take a look at CAT1 in AS 500

Cat1#show ip bgp | begin Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 78 ?


This is not good! We can get rid of AS 78 by doing this on R7:

R7(config)#router bgp 78
R7(config-router)#neighbor 150.20.56.5 local-as 8888 no-prepend replace-as
R7(config-router)#neighbor 150.20.56.6 local-as 8888 no-prepend replace-as


Now let's take a look:

Cat1#show ip bgp | beg Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 ?

Monday, July 14, 2008

BGP - TTL security

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.

Example:

On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5


After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytes


The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up


In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251
R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5


After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

You can verify like this:

R6#show ip bgp neighbors 172.14.45.5 | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255


I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.

BGP - local-as option

BGP local-as option allows a router to appear as if it is in another AS. Suppose we have a frame-relay cloud with 3 routers all EBGP peers with each other:

R6: 172.14.45.6 (AS 65000)
R5: 172.14.45.5 (AS 65005)
R4: 172.14.45.4 (AS 345)

We can configure R6 to use the local-as option to appear to be from AS 65006 to R5, but remain in AS65000 for R4. Here's how:

R6(config-router)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006


On R5:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65006

Let's take a look at the neighbor summary:

R5# show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 220 221 244 0 0 00:03:39 9

R4#show ip bgp summary | be Ne
172.14.45.6 4 65000 176 146 69 0 0 00:00:08 11


Notice the different AS numbers. Also notice the AS path from R5's view:

R5# show ip bgp | inc 172.14.45.6
*> 6.0.3.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 65000 i


And the AS path from R6's view also includes the local-AS number:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65006 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65006 65005 i


The routes appear to magically pass through 65006. We can prevent R6 from prepending the local-as number on routes received from R6 with the no-prepend option

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend


65006 is no longer in the AS Path:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65005 i


With the replace-AS we can prevent R5's real BGP AS number from appearing in the AS path on routes from R6 to R5:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as


R5# show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 6.0.3.0/24 172.14.45.6 0 0 65006 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 i


Lastly, we can configure R6 to accept connections to either AS 65000 or AS 65006 with the dual-as option:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as dual-as


R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 268 284 343 0 0 00:00:08 9

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65000
R5(config-router)#
.Jul 14 21:34:34.273: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Remote AS changed
R5(config-router)#
.Jul 14 21:34:36.505: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
R5(config-router)#
R5(config-router)#^Z
R5#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 270 286 0 0 0 00:00:09 0

BGP - maximum-prefix command

The network:

[R5]---[R6]

R5 connects to R6 via EBGP
R5 is 172.14.45.5
R6 is 172.14.45.6

R6 is advertising 10 networks to R5:

R5#show ip bgp | inc 45\.6
*> 6.0.0.0/24 172.14.45.6 0 0 65000 i
*> 6.0.1.0/24 172.14.45.6 0 0 65000 i
*> 6.0.2.0/24 172.14.45.6 0 0 65000 i
*> 6.0.3.0/24 172.14.45.6 0 0 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65000 i
*> 6.0.6.0/24 172.14.45.6 0 0 65000 i
*> 6.0.7.0/24 172.14.45.6 0 0 65000 i
*> 6.0.8.0/24 172.14.45.6 0 0 65000 i
*> 6.0.9.0/24 172.14.45.6 0 0 65000 i


I am going to play with a few options of the maximum-prefix command and see the effect. First let's configure a maximum of 8 routes:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8
R5(config-router)#
.Jul 14 20:45:41.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Maximum-Prefix restart timeout
.Jul 14 20:46:10.519: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:46:11.919: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:46:11.927: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:46:11.931: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:46:11.931: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
R5(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0058 0200 0000 1940 0
101 0040 0204 0201 FDE8 4003 04AC 0E2D 0680 0404 0000 0000 1806 0009 1806 0008 1
806 0007 1806 0006 1806 0005 1806 0004 1806 0003 1806 0002 1806 0001 1806 0000


Notice that the nighbor tried to come up after I configured the max. It never tried to come up again after going down the second time. Now the neighbor has the following output (much of the output is omitted):

R5#show clock
.20:50:26.655 UTC Mon Jul 14 2008
R5#


R5#show ip bgp neighbor 172.14.45.6
...
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 8
Threshold for warning message 75%
Reduce the no. of prefix and clear ip bgp 172.14.45.6 to restore peering


We can also configure the router to try and establush the connection again after the max limit is reached and the connection is brought down:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 restart 1


Here is a sample of the output, the connection tries to re-establish but then drops because the max-prefix limit is reached:

R5#
.Jul 14 20:53:16.779: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:53:16.811: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:53:16.819: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:53:16.823: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:53:16.827: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:54:15.999: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:54:16.011: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:54:16.015: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:54:16.023: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:54:16.023: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:55:41.311: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:55:41.355: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:55:41.359: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:55:41.363: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:55:41.367: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes


We can also configure a percentage to give us a warning. Here we configure the percantge to 75 of 8 (6) while disabling 3 of the loopbacks on R6:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 7

.Jul 14 21:00:08.226: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 21:00:08.234: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8


The connection stays up:

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 186 177 224 0 0 00:00:33 7


Lastly, we can configure a warning-only which doesn't bring down the connection:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 75 warning-only

.Jul 14 21:01:53.614: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 8, max 8
.Jul 14 21:02:24.046: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8


The connection stays up:

R5#show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 190 181 226 0 0 00:02:41 9


This was a quick and dirty blog. Hopefully by reading this every now and then you get an idea about how the max-prefix option works.

Friday, July 11, 2008

BGP - prefix-based outbound route filtering

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.

In this example we have EBGP peers R4 and R3:

[R4]---[R3]

R3 is receiving a bunch of routes from R4:

R3#show ip bgp Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i

*> 2.0.1.0/24 172.12.34.4 0 400 65000 i

*> 2.0.2.0/24 172.12.34.4 0 400 65000 i

*> 2.0.3.0/24 172.12.34.4 0 400 65000 i

*> 3.3.3.0/24 0.0.0.0 0 32768 i

*> 4.0.0.0/24 172.12.34.4 0 0 400 i

*> 4.0.1.0/24 172.12.34.4 0 0 400 i

*> 4.0.2.0/24 172.12.34.4 0 0 400 i

*> 4.0.3.0/24 172.12.34.4 0 0 400 i


R3 only wants to receive 3 routes:

1.0.0.0/24
2.0.0.0/24
4.0.0.0/24

R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send

R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receive


Now configure the prefix-list and apply it to the neighbor:

R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24
R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24

R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO in


R3#clear ip bgp * soft in prefix-filter

Here is the final result:

R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i

*> 2.0.0.0/24 172.12.34.4 0 400 65000 i

*> 3.3.3.0/24 0.0.0.0 0 32768 i

*> 4.0.0.0/24 172.12.34.4 0 0 400 i


Here are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?



Restrictions:

I used the bgp upgrade-cli command to configure these neighbors in AF mode.
Also, prefix-lists must be used, not ACL or distribute lists

For more info go here:

BGP Prefix-Based Outbound Route Filtering