Networking-Blog

Tags: bgp, path selection

by admin

Influencing BGP path selection with the extcommunity cost attribute

Many of you out there should be familiarized with the BGP path selection process,
but I bet some of you (as me, until I recently found out) didn’t knew that by using the
extcommunity cost attribute, we might be able to somehow modify the BGP path
selection algorithm.

So what is the extended community cost attribute?.

The BGP Cost Community feature introduces the cost extended community
attribute. The cost community is a non-transitive extended community
attribute that is passed to internal BGP (iBGP) and confederation peers but
not to external BGP (eBGP) peers. The cost community feature allows you to
customize the local route preference and influence the best path selection
process by assigning cost values to specific routes.

This next diagram will be the topology I’ll be working on to demonstrate how this
could be done:

Network Topology BGP

First, we build a basic BGP configuration on every router according to the diagram
above. After that is done, if we take a look on R1 BGP table it should look like this:

R1#sh ip bgp
BGP table version is 2, local router ID is 192.168.123.1
Status codes: s suppressed, d damped, h history, * valid, > best, 
i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i10.10.10.0/24    192.168.123.3            0    100      0 400 i
*>i                 192.168.123.2            0    100      0 400 i

R1#sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0xA60
  Not advertised to any peer
  400
    192.168.123.3 from 192.168.123.3 (192.168.123.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  400
    192.168.123.2 from 192.168.123.2 (192.168.123.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

We can see that both paths for prefix 10.10.10.0/24 (a loopback interface on R4)
have the same attributes. If we follow the steps in the BGP path selection algorithm,
we can deduce that the next hop 192.168.123.2 is being chosen as the best path
because it’s the path announced by the router with the lowest router-id, in this
case R2.

Imagine you are in the lab, and they give you a task stating something like

“Make R1 to prefer the route to 10.10.10.0/24 through R3 but, without modifying
local preference, weight, as-path, bgp router-id or IGP metric to next-hop”
(evil I know ). This is one case when the extcommunity cost could result useful.

Let’s do the configuration, we need to make R1 and R3 send community values:

R1(config)#router bgp 123 
R1(config-router)#neighbor 192.168.123.3 send-community both
!
R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 send-community both

Then on R3, we build a route-map, where the extcommunity cost setting will take place:

R3(config)#ip prefix-list TRICKY-TASK permit 10.10.10.0/24 
R3(config)#route-map TASK permit 10 
R3(config-route-map)#match ip add prefix-list TRICKY-TASK 
R3(config-route-map)#set extcommunity cost 1 100 
R3(config-route-map)#exit 
!
R3(config)#route-map TASK permit 20 
R3(config-route-map)#exit

And then we apply the route-map in R3 for the R1 neighbor relationship,
and clear the BGP process for that neighbor:

R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 route-map TASK out 
R3(config-router)#do clear ip bgp * soft out

That’s it, now we need to verify. To do that, we take a look at R1’s BGP table so we
can see the effect of the route-map in the route:

R1#sh ip bgp 10.10.10.0

BGP routing table entry for 10.10.10.0/24, version 5 
Paths: (2 available, best #1, table Default-IP-Routing-Table) 
Flag: 0xA60 Not advertised to any peer 400
    192.168.123.3 from 192.168.123.3 (192.168.123.3) 
Origin IGP, metric 0, localpref 100, valid, internal, 
best Extended Community: Cost:igp:1:100
  400 192.168.123.2 from 192.168.123.2 (192.168.123.2) 
Origin IGP, metric 0, localpref 100, valid, internal

September 20, 2012 1:00 pm

Tags: bgp, community, excommunity

by admin

BGP ROUTE-MAP SET MED

In the following example,

route map freddy marks all paths originating from autonomous system 690 with a Multi Exit Discriminator
(MED) metric attribute of 127. The second permit clause is required so that routes not matching autonomous system path list 1 will still be sent to neighbor 1.1.1.1.

router bgp 100
neighbor 1.1.1.1 route-map freddy out
!
!
route-map freddy permit 10
match as-path 1
set metric 127
!
route-map freddy permit 20
match as-path 2
!
!
ip as-path access-list 1 permit ^690_
ip as-path access-list 2 permit .*

February 20, 2012 9:40 pm

Tags: bgp med

by admin

BGP Path Filtering by Neighbor

The following is an example of BGP path filtering by neighbor. The routes that pass as-path access list 1
will get weight 100. Only the routes that pass as-path access list 2 will be sent to 193.1.12.10.
Similarly, only routes passing access list 3 will be accepted from 193.1.12.10.

router bgp 200
neighbor 193.1.12.10 remote-as 100
neighbor 193.1.12.10 filter-list 1 weight 100
neighbor 193.1.12.10 filter-list 2 out
neighbor 193.1.12.10 filter-list 3 in
!
!
ip as-path access-list 1 permit _109_
ip as-path access-list 2 permit _200$
ip as-path access-list 2 permit ^100$
ip as-path access-list 3 deny _690$
ip as-path access-list 3 permit .*

February 20, 2012 9:15 pm

Tags: bgp filtering

by admin

BGP SET AS-PATH

In the following example, the route map called set-as-path is applied to outbound updates to the
neighbor 200.69.232.70.

The route map will prepend the autonomous system path “100 100” to routes that pass access list 1.
The second part of the route map is to permit the advertisement of other routes.

router bgp 100
network 171.60.0.0
network 172.60.0.0
neighbor 200.69.232.70 remote-as 200
neighbor 200.69.232.70 route-map set-as-path out
!
route-map set-as-path 10 permit
match address 1
set as-path prepend 100 100
!
route-map set-as-path 20 permit
match address 2
!
access-list 1 permit 171.60.0.0 0.0.255.255
access-list 1 permit 172.60.0.0 0.0.255.255
!
access-list 2 permit 0.0.0.0 255.255.255.255

February 19, 2012 11:23 pm

Tags: bgp as-path

by admin

BGP – Configuring Route Reflectors

Router reflection is an alternative to confederations as a strategy to reduce IBGP meshing.
BGP specifies that a BGP speaker cannot advertise routes to an IBGP neighbor if the speaker learned the
route from a different IBGP neighbor.

A route reflector is a BGP speaker that advertises routes learned from each of its IBGP neighbors to its
other IBGP neighbors; routes are reflected among IBGP routers that are not meshed. The route reflector’s neighbors are called route reflector clients.
The clients are neighbors only to the route reflector, not to each other. Each route reflector client
depends on the route reflector to advertise its routes within the AS; each client also depends on the
route reflector to pass routes to the client.

A route reflector and its clients are collectively referred to as a cluster. Clients peer only with a
route reflector and do not peer outside their cluster. Route reflectors peer with clients and other
route reflectors within the cluster; outside the cluster they peer with other reflectors and other routers
that are neither clients nor reflectors. Route reflectors and nonclient routers must be fully meshed.

Clients and nonclients have no knowledge of route reflection; they operate as standard
BGP peers and require no configuration.

Route reflectors advertise routes learned from:

A nonclient peer only to clients
A client peer to all nonclient peers and to all client peers except for the originator of the route
An EBGP peer to all nonclient peers and all client peersIllustrates a simple route reflection setup.Configured as a route reflector, Router Harvard reflects routes among its
clients within Cluster 23: Routers Plymouth, Westford, and Acton.
These route reflector clients see router Harvard and each other simply as IBGP neighbors.
Router Newport in AS 325 and router Mason in AS 413 see router Harvard simply as
an EBGP neighbor in AS 29.
To configure router Concord as a route reflector:
router bgp 29
neighbor 10.7.1.3 remote-as 29
neighbor 10.7.1.3 route-reflector-client
neighbor 10.7.1.4 remote-as 29
neighbor 10.7.1.4 route-reflector-client
neighbor 10.7.6.2 remote-as 29
You do not configure a cluster ID, because router Concord is the only route reflector in this cluster.
To configure router Acton :
!
router bgp 29
bgp cluster-id 23
neighbor 10.3.1.1 remote-as 29
neighbor 10.3.1.1 route-reflector-client
neighbor 10.1.2.3 remote-as 29
neighbor 10.1.2.3 route-reflector-client
neighbor 10.3.3.4 remote-as 29
neighbor 10.2.5.1 remote-as 29
You must configure a cluster ID, because router Acton and router Harvard are both route reflectors
in this cluster.
To configure router Harvard as a route reflector:
!
router bgp 29
bgp cluster-id 23
neighbor 10.3.1.2 remote-as 29
neighbor 10.3.1.2 route-reflector-client
neighbor 10.1.2.1 remote-as 29
neighbor 10.1.2.1 route-reflector-client
neighbor 10.3.3.2 remote-as 29
neighbor 10.2.5.2 remote-as 29
!
You must configure a cluster ID, because router Harvard and router Acton are both route reflectors
in this cluster.
bgp client-to-client reflection
- Use to reenable the reflector to reflect routes among all clients.
- Client-to-client reflection is enabled by default. If the route reflector’s clients are
  fully meshed, you can disable reflection because it is not necessary.
- If client-to-client reflection is enabled (the default), clients of a route reflector
  cannot be members of a peer group.
- Example
```
no bgp client-to-client reflection 
```
- Changes apply automatically to any routes received after you issue the command.
  To advertise or withdraw routes that are already present in the BGP RIB, you
  must use the clear ip bgp command to issue a hard clear or an outbound
  soft clear.
- Use the no version to disable route reflection; use only if the route reflector’s clients are fully meshed.
bgp cluster-id
- Use to configure a cluster ID on the route reflectors if the BGP cluster has more than one
  route reflector. For clusters with a single reflector, the cluster ID
  is the reflector’s
  router ID and does not have to be configured.
- You specify a cluster ID number or an IP address of a router acting as a route reflector.
- The new cluster ID is used in update messages sent after you issue the command.
  To force BGP to resend all routes with the new cluster ID, you must use the clear ip bgp
  command to perform a hard clear or a soft clear.
- Use the no version to cause BGP to use the router ID as the cluster ID.
neighbor route-reflector-client
- Use to configure the local router as the route reflector and the specified neighbor as one
  of its clients. The reflector and its clients constitute a cluster. BGP neighbors that
  are not specified as clients are nonclients.
- Route reflectors pass routes among the client routers.
- Route reflection eliminates the need for all IBPG peers to be fully–meshed.
  The members of a cluster do not have to be fully meshed, but BGP speakers outside
  the cluster must be fully meshed.
- If client-to-client reflection is enabled (the default), clients of a route reflector cannot
  be members of a peer group.
- If you specify a BGP peer group by using the peerGroupName argument,
  all the members of the peer group inherit the characteristic configured with this command.
  You cannot override this inheritance for a peer group member.
- Changes apply automatically to any routes received after you issue the command.
  To advertise or withdraw routes that are already present in the BGP RIB, you must use
  the clear ip bgp command to issue a hard clear or an outbound soft clear.
- Use the no version to indicate that the neighbor is no longer a client. Use the default version
  to remove the explicit configuration from the peer or
  peer group and reestablish inheritance of the feature configuration.

February 15, 2012 10:20 pm

Tags: Route Reflectors

by admin

BGP – Managing a Large-Scale AS

BGP requires that IBGP peers be fully meshed, creating significant routing overhead as the number of
peers increases. The number of IBGP sessions increases rapidly with the number of routers:

BGP provides two alternative configuration strategies to reduce the number of fully meshed peers.

You can either:

Configure confederations.
Configure route reflectors.

Both of these strategies are complex and can create their own problems. Neither strategy is typically
used unless the mesh of IBGP peers approaches 100 sessions per peer.

Configuring a Confederation

IBGP requires that BGP speakers within an AS be fully meshed. You can reduce the IBGP mesh
inside an AS by subdividing the AS into a confederation of sub-ASs. Each sub-AS must be fully meshed
internally, but the sub-ASs do not have to be fully meshed with each other. Confederations are most useful when the number of IBGP speakers within an AS increases to the
point that each router has about 100 peering sessions.

AS 29 consists of 10 fully meshed IBGP peers (for clarity, only the BGP sessions are shown).
Border router Salem has an EBGP session with a neighbor in AS 325.
Border router Boston hasan EBGP session with a neighbor in AS 413.

Illustrates how you can create three sub-ASs within AS 29 to greatly reduce the number of
peering sessions. According to common practice, use a number from the private range of AS numbers

—from 64512 to 65535—to identify each sub-AS. AS 29 is now a confederation of
three sub-ASs: AS 64720, AS 64721, and AS 64722. Each sub-AS consists of fully meshed IBGP peers.

A slightly modified version of EBGP runs between the sub-ASs: It acts like IBGP within an AS
because the local-pref, MED, and next-hop attributes are preserved across the sub-AS boundaries.
To the external neighbors, AS 29 appears the same as it ever was.

The following commands partially configure router Salem:

router bgp 64720
bgp confederation identifier 29
bgp confederation peers 64721 64722
neighbor 10.2.25.4 remote-as 64720
neighbor 10.2.25.8 remote-as 64721
neighbor 10.2.25.2 remote-as 325

The bgp confederation identifier command establishes router Salem as a member of Confederation 29.
The bgp confederation peers command specifies that sub-AS 64721 and sub-AS 64722 are members
of the same confederation as the sub-AS that includes router Salem.

The neighbor remote-as commands specify the IBGP connection with a neighbor in sub-AS 64720
and the EBGP connections with neighbors in sub-AS 64721 and outside the confederation in AS 325.

Similarly, the following commands partially configure router Harvard:

router bgp 64721
bgp confederation identifier 29
bgp confederation peers 64720 64722
neighbor 10.2.25.7 remote-as 64720

From router Newport’s perspective, router Salem is simply a member of AS 29:

router bgp 325
neighbor 10.2.25.6 remote-as 29

From router Mason’s perspective, router Boston is simply a member of AS 29:

router bgp 413
neighbor 10.3.3.2 remote-as 29

bgp confederation identifier

Use to establish a router as a member of the specified BGP confederation.
To systems outside the confederation, the confederation appears as an autonomous system
with an AS number the same as the confederation identifier.
The new confederation identifier is used in open messages and in the AS path in update messages
that are sent after you issue the command.

To force sessions that are already up to use the new confederation identifier, you must use the clear ip bgp command to perform a hard clear.

bgp confederation peers

Enables EBGP sessions with routers in the peer sub-ASs; the EBGP sessions preserve local-pref,
MED, and next-hop attributes.
You can specify one or more individual sub-AS numbers, or you can issue the filter-list keyword
and an AS-path access list (which is based on regular expressions) to specify a list of sub-AS numbers.
If the remote AS of a peer appears in the specified list of sub-ASs or is identified by the
filter list, then the peer is considered to be in the same confederation.
This command takes effect immediately and bounces only those sessions whose peer type
changed as a result of issuing the command.

February 15, 2012 9:42 am

Tags: bgp confederation

by admin

Cisco: Troubleshooting OSPF and BGP

This document shows how to redistribute Internal BGP routes into OSPF process. Like in other
IGP to IGP redistribution the behavior is different when redistributing IBGP into OSPF.
IBGP learned routes are not forwarded to an IGP routing protocol through the redistribute command.

Use command “bgp redistribute-internal” under the BGP process on the redistributing router.

In the scenario depicted here, router R1 and R2 are running IBGP and router R2/R3 running
OSPF Area 0. R1 is advertising two routes (1.1.1.1 /32 and 172.16.0.0 /16) through network command.
R2 is redistributing BGP into OSPF area 0. It is required to redistribute selected internal routes
(172.16.0.0 /16). The task is achieved by making use of prefix-list and route-map.

A prefix-list, named B2O, is configured on R2 to match the prefix 172.16.0.0

ip prefix-list B2O seq 5 permit 172.16.0.0/16
A route-map, named BGP-To_OSPF, is configured on R2

route-map BGP-To_OSPF permit 10
match ip address prefix-list B2O

In the vrification section, please check the output of “show ip route” command on R3.

Router R1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 172.16.1.1 255.255.0.0
!
interface Serial1/0
ip address 192.12.12.1 255.255.255.0
serial restart-delay 0
!
router bgp 100
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
network 172.16.0.0
neighbor 192.12.12.2 remote-as 100
no auto-summary

Router R2

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Serial1/0
ip address 192.12.12.2 255.255.255.0
serial restart-delay 0
!
interface FastEthernet2/0
ip address 192.23.23.2 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute bgp 100 metric 100 metric-type 1 subnets route-map BGP-To_OSPF
network 192.23.23.2 0.0.0.0 area 0
!
router bgp 100
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
bgp redistribute-internal
neighbor 192.12.12.1 remote-as 100
no auto-summary
!
ip prefix-list B2O seq 5 permit 172.16.0.0/16
!
route-map BGP-To_OSPF permit 10
match ip address prefix-list B2O

Router R3

interface FastEthernet1/0
ip address 192.23.23.3 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 192.23.23.3 0.0.0.0 area 0

‘show ip route’ on R3 :

O E1 172.16.0.0/16 [110/101] via 192.23.23.2, 00:57:55, FastEthernet1/0

192.23.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.23.23.0/24 is directly connected, FastEthernet1/0

February 14, 2012 12:48 am

Tags: ospf redistribute

by admin

BGP Configuring Peer Groups

You will often want to apply the same policies to most or all of the peers of a particular BGP speaker.
Update policies are usually defined by route maps, filter lists, and distribution lists.

You can reduce the configuration effort by defining a peer group made up of these peers.

A peer group is defined relative to a particular BGP speaker. Two peer groups, eastcoast and leftcoast.
Each of these peer groups is defined for router Chicago, the hub router. Routers Boston, NY, and Miami
have no knowledge of being members of Router Chicago’s eastcoast peer group.

Similarly, routers SanFran, LA, and SanDiego have no knowledge of being members of router
Chicago’s leftcoast peer group.

The following commands configure the eastcoast peer group on router Chicago:

host1(config)#route-map wtset permit 10
host1(config-route-map)#set weight 25
!
host1(config)#router bgp 23
!
host1(config-router)#neighbor eastcoast route-map wtset in
!
!
!
host1(config-router)#neighbor eastcoast peer-group
!
host1(config-router)#neighbor 10.6.6.2 remote-as 12
host1(config-router)#neighbor 10.6.6.2 peer-group eastcoast
!
host1(config-router)#neighbor 10.7.3.2 remote-as 12
host1(config-router)#neighbor 10.7.3.2 peer-group eastcoast
!
host1(config-router)#neighbor 10.4.4.2 remote-as 12
host1(config-router)#neighbor 10.4.4.2 peer-group eastcoast

!
!

The following commands configure the leftcoast peer group on router Chicago:

host1(config-router)#neighbor leftcoast peer-group
!
host1(config-router)#neighbor 10.3.3.2 remote-as 78
host1(config-router)#neighbor 10.3.3.2 peer-group leftcoast
!
host1(config-router)#neighbor 10.3.2.2 remote-as 2143
host1(config-router)#neighbor 10.3.2.2 peer-group leftcoast
!
host1(config-router)#neighbor 10.3.1.2 remote-as 136
host1(config-router)#neighbor 10.3.1.2 peer-group leftcoast

neighbor peer-group

Two versions of this command exist. Use to create a BGP peer group or to configure
a BGP neighbor to be a member of a peer group.
!
To create a BGP peer group, specify a peerGroupName for the new peer group.
!
To assign members to a peer group, specify an ip-address and a peerGroupName
of a BGP neighbor that belongs to this group.
!
Most of all :
This command takes effect immediately.

February 8, 2012 5:30 pm

Tags: bgp peer groups

by admin

BGP Support for Fast Peering Session Deactivation

The BGP Support for Fast Peering Session Deactivation feature introduces an event driven notification
system that allows a Border Gateway Protocol (BGP) process to monitor BGP peering sessions on a
per-neighbor basis.

This feature improves the response time of BGP to adjacency changes by allowing :

BGP to detect an adjacency change and deactivate the terminated session in between standard
BGP scanning intervals. Enabling this feature improves overall BGP convergence.

Restrictions for BGP Support for Fast Peering Session Deactivation :

• This feature is not supported under the IPv6 address family.
• A host route must be available for each peering session that is configured to use BGP fast session
deactivation. If a route is aggregated or is an unreachable non-host route (through a loopback interface)
but still available to the peer, this feature will not be able to track the route and will be unable to close the session.

Information About BGP Support for Fast Peering Session Deactivation

•BGP Hold Timer
•BGP Fast Peering Session Deactivation

BGP Hold Timer

By default, the BGP hold timer is set to run every 180 seconds in Cisco IOS software.
This timer value is set as default to protect the BGP routing process from instability that can be
introduced by peering sessions with other routing protocols. BGP routers typically carry large routing tables,
so frequent session resets are not desirable.

BGP Fast Peering Session Deactivation

BGP fast peering session deactivation improves BGP convergence and response time to adjacency
changes with BGP neighbors. This feature is event driven and configured on a per-neighbor basis.
When this feature is enabled, BGP will monitor the peering session with the specified neighbor.
Adjacency changes are detected and terminated peering sessions are deactivated in between the default
or configured BGP scanning interval.

How to Configure Fast Peering Session Deactivation

This section contains the following task:

•Configuring Fast Session Deactivation for a BGP Neighbor

The neighbor fall-over command was introduced to support BGP fast session deactivation.

SHUT DOWN BGP SESSION BASED ON TRACKED OBJECT

I used a creative approach to create a static route that fits the requirements of the
Fast Peering Deactivation: a host route toward the BGP next hop pointing at BGP next hop.

Let’s walk through a lab-tested example:

The router is running BGP in AS#65100 and has an EBGP session with 10.0.7.10 in AS#65000:

router bgp 65100
bgp log-neighbor-changes
network 10.0.1.1 mask 255.255.255.255
neighbor 10.0.7.10 remote-as 65000

First we have to create the track object that will cause the BGP session termination. It can track
anything – you can track interface state, use IP SLA and ping the firewall, or even use EEM to
trigger time-based (or other event-based) session shutdown. I decided to track the state of the LAN interface.
!
track 10 interface FastEthernet0/0 ip routing
carrier-delay

Next, create a host route for the BGP next hop pointing to the next hop itself.
If you use a PPP interface to connect to the BGP next hop, make sure you disable
peer neighbor-route, otherwise the router creates a competing host route for the BGP next hop.

ip route 10.0.7.10 255.255.255.255 Serial1/0 10.0.7.10 track 10
!
interface Serial1/0
description Link to AS65000
ip address 10.0.7.9 255.255.255.252
encapsulation ppp
no peer neighbor-route

We need a prefix-list and a route-map to match the host route toward the BGP next hop:

ip prefix-list BGP_OK seq 5 permit 10.0.7.10/32
!
route-map BGP_OK permit 10
match ip address prefix-list BGP_OK
!
And finally, we can configure the fast BGP session deactivation on the EBGP session:

router bgp 65100
neighbor 10.0.7.10 fall-over route-map BGP_OK

Test#1 – shut down the LAN interface. BGP session is shut down almost immediately
(you can fine-tune the delay with track object parameters).

A1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
A1(config)#int fa 0/0
A1(config-if)#shut
A1(config-if)#
15:27:55.719: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to
administratively down
15:27:56.383: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Up->Down
15:27:56.415: %BGP-5-ADJCHANGE: neighbor 10.0.7.10 Down Route to peer lost
15:27:56.415: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.7.10 IPv4 Unicast
topology base removed from session Route to peer lost
15:27:56.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/0, changed state to down

Test#2 – re-enable the LAN interface. BGP session is reestablished in less than a second. Perfect 😉

A1(config-if)#no shut
A1(config-if)#
15:29:22.211: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
15:29:22.395: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Down->Up
15:29:22.511: %BGP-5-ADJCHANGE: neighbor 10.0.7.10 Up
15:29:23.211: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/0, changed state to up

In Summary :

router bgp 65100
bgp log-neighbor-changes
network 10.0.1.1 mask 255.255.255.255
neighbor 10.0.7.10 remote-as 65000
!
track 10 interface FastEthernet0/0 ip routing
carrier-delay
!
ip route 10.0.7.10 255.255.255.255 Serial1/0 10.0.7.10 track 10
!
interface Serial1/0
no peer neighbor-route
!
ip prefix-list BGP_OK seq 5 permit 10.0.7.10/32
!
route-map BGP_OK permit 10
match ip address prefix-list BGP_OK
!
router bgp 65100
neighbor 10.0.7.10 fall-over route-map BGP_OK

February 8, 2012 4:28 pm