Networking-Blog

My WordPress Blog

Categories

Redistribute Routes into OSPF

1. Use the source route’s cost if from another OSPF process
2. Cost is 1 for routes learned from BGP
3. Cost is 20 for all other routes

External Type 1 OSPF routes have incrementing costs.
External Type 2 OSPF routes maintain the same cost throughout the AS and are the default type when redistributing.

So, for the most part routes will be external type 2 and have a cost of 20 by default unless you are using BGP (say, for either an Internet connection or MPLS configuration),
in which case those routes will have a cost of 1. If you are running two OSPF processes and redistributing between them, then the cost is carried over.

But what if you want to manipulate the cost of those routes? Here area few examples on how to go about doing that.

Set the default for all redistributed routes:

RedistributeRouter(config)# router ospf 1
RedistributeRouter(config-router)# default-metric 37
RedistributeRouter(config-router)# redistribute eigrp 1 subnets

R3#show ip route
…
10.0.0.0/24 is subnetted, 3 subnets
O E2 10.1.10.0 [110/37] via 172.20.0.1, 00:00:50, FastEthernet0/0
O E2 10.1.1.0 [110/37] via 172.20.0.1, 00:00:50, FastEthernet0/0
O E2 10.1.0.0 [110/37] via 172.20.0.1, 00:00:50, FastEthernet0/0
Notice the metric is set to the cost of 37 configured above instead of 20. This would apply to any of the routes that are being redistributed into that OSPF process.

Setting the metric for route source :
The alternative to setting metric for all redistributed routes under a process is to specify a metric for the specific source of the routes under the redistribute router subcommand.

router ospf 10
log-adjacency-changes
redistribute eigrp 1 metric 61 subnets
network 172.20.10.0 0.0.0.255 area 1
network 172.20.0.0 0.0.255.255 area 0
default-metric 37

R3#show ip route
…
10.0.0.0/24 is subnetted, 3 subnets
O E2 10.1.10.0 [110/61] via 172.20.0.1, 00:00:04, FastEthernet0/0
O E2 10.1.1.0 [110/61] via 172.20.0.1, 00:00:04, FastEthernet0/0
O E2 10.1.0.0 [110/61] via 172.20.0.1, 00:00:04, FastEthernet0/0
Notice the default-metric 37 subcommand has no effect when the metric keyword is used in the redistribute subcommand.

Setting different metrics for routes learned from a single source :
Using a route-map in the redistribute command gives you very granular control over what metric is set for specific networks. The following example matches one of the three networks being redistributed into OSPF and sets a higher cost for that route. The previous configured metric setting in the redistribute command is still applied to all other routes.

router ospf 10
log-adjacency-changes
redistribute eigrp 1 metric 61 subnets route-map TAG
network 172.20.10.0 0.0.0.255 area 1
network 172.20.0.0 0.0.255.255 area 0
default-metric 37
!

access-list 7 permit 10.1.1.0 0.0.0.255

!
route-map TAG permit 10
match ip address 7
set metric 750
!
route-map TAG permit 20

R3#show ip route
10.0.0.0/24 is subnetted, 3 subnets
O E2 10.1.10.0 [110/61] via 172.20.0.1, 00:00:11, FastEthernet0/0
O E2 10.1.1.0 [110/750] via 172.20.0.1, 00:02:34, FastEthernet0/0
O E2 10.1.0.0 [110/61] via 172.20.0.1, 00:00:11, FastEthernet0/0

Keep in mind, the second statement in the route-map TAG has to be there if you want the remaining routes to be permitted. Not having that line in the route-map has a similar effect as an access control list and Denies all remaining routes that don’t match! Definitely not something to be trying on a production network.

Hopefully these examples help explain the ways to modify the default metric values when redistributing routes into OSPF.

Routing Protocol
No comments yet.

(No tags)

by admin

OSPF Redistribute subnets

If I remember correctly, although OSPF is classless itself, (Cisco) redistribution into OSPF.  The subnets parameter seems to assume classful networks.

For instance, under classful rules, 10.x.x.x is class A network (or /8 VLSM). 10.1.1.0/24, under classful rules is a subnet of the 10.x.x.x class A address. To have (Cisco) redistribute 10.1.1.0/24 into OSPF requires the subnets keyword. To have (Cisco) redistribute 10.0.0.0/8 into OSPF would not.

Usually when working with (Cisco) OSPF, you’ll want to use the subnets keyword when doing redistribution into OSPF.

If you wanted to redistribute 192.168.1.0/24 into OSPF, since, under class rules, it’s a class C address, you wouldn’t need the subnets parameter. However, 192.168.1.0/25, a class C subnet, you would need subnets parameter.

When working with VLSM/classless, you’ll want to use subnets parameter.)

This output shows an OSPF router redistributing static, RIP, IGRP, EIGRP, and IS-IS routes.

router ospf 1
network 131.108.0.0 0.0.255.255 area 0
redistribute static metric 200 subnets
redistribute rip metric 200 subnets
redistribute igrp 1 metric 100 subnets
redistribute eigrp 1 metric 100 subnets

When there is a major net that is subnetted, you need to use the keyword subnet to redistribute protocols into OSPF. Without this keyword, OSPF only redistributes major nets that are not subnetted.

 

 

Routing Protocol
No comments yet.

Tags: , , ,

by admin

Disable flapping BGP neighbors

BGP protocol specifications require a BGP router to use BGP notification messages to
reject invalid routing updates, updates with incorrect attribute combinations or other
protocol errors (including AS number mismatch and duplicate router ID).

The notification messages cause termination of a BGP session and since the
offending data (or configuration error) is usually not removed from the sending
router, the impacted BGP session flaps continuously until a manual intervention,
causing widespread propagation of unnecessary BGP routing updates.
Solution Embedded Event Manager applet or TCL policy can detect flapping BGP
session and shut down the offending BGP neighbor.

The applets described in this article react to at least three BGP-3-NOTIFICATION
syslog messages per minute.

 

The following EEM applet requires the programming logic and regular expression
 support available in Embedded Event Manager 3.0 (first released with Cisco IOS
release 12.4(22)T).

event manager applet BGPNotification
event syslog occurs 3 pattern “BGP-3-NOTIFICATION” period 300
action 100 regexp “neighbors+([0-9]+.[0-9]+.[0-9]+.[0-9]+)” “$_syslog_msg” match id
action 200 if $_regexp_result eq 1
action 300 info type snmp oid bgp.2.0 get-type exact
action 400 cli command “enable”
action 410 cli command “configure terminal”
action 420 cli command “router bgp $_info_snmp_value”
action 430 cli command “neighbor $id shutdown”
action 500 syslog msg “Shut down BGP neighbor $id”
action 510 info type routername
action 520 mail server $_mail_smtp to $_mail_rcpt from “$_info_routername@$_mail_domain” →
subject “ALERT: BGP neighbor $id shutdown due to excessive notifications” body “n$_syslog_msg”
action 999 end

 

Altenative :

event manager applet BGPNotification
event syslog occurs 3 pattern “BGP-3-NOTIFICATION” period 900
action 100 regexp “neighbors+([0-9]+.[0-9]+.[0-9]+.[0-9]+)” “$_syslog_msg” match id
action 200 if $_regexp_result eq 1
action 300 info type snmp oid bgp.2.0 get-type exact
action 400 cli command “enable“
action 410 cli command “configure terminal“
action 420 cli command “router bgp $_info_snmp_value“
action 430 cli command “neighbor $id shutdown“
action 500 syslog msg “Shut down BGP neighbor $id“
action 510 info type routername
action 600 end

 

BGP
No comments yet.

Tags:

by admin

BGP Route Flap Dampening (RFC 2349)

While reading this tutorial, remember that BGP is a routing protocol. That means BGP
learns and selects the best route to a given destination. Anything that makes a route less
preferred causes the router to stop adding the route to the IP routing table and to stop
advertising the route to neighbors.

What is a Route Flap?

BGP peers exchange routes and send updates not faster than every 90 seconds by default.
When a route is repeatedly advertised and withdrawn, it is considered to be ‘flapping‘.
Flapping routes cause instability in the Internet routing table and Cisco routers running
BGP contain an optional mechanism designed to dampen the destabilizing effect of
flapping routes. When a Cisco router running BGP detects a flapping route it automatically
dampens that route. The route dampening prevents routers from thrashing while trying
to re-calculate a large number of route updates. The overall effect is to produce a more
stable routing table. BGP routes can remain in the routing table for months.

The term route flap is used when a previously advertised route is withdrawn and then
readvertised. Cisco IOS later than 11.0 has a route dampening function built into it.
If you are running BGP version 4, the BGP process assigns a penalty of 1000 to the route
each time it flaps. When the penalty value exceeds the first of two limits, the route is
moved into the ‘historical’ list of routes, dampened, and then is no longer accepted from
other peers or announced to any peers. After the first limit has been exceeded, the timer
which tracks the period for which the route is to be dampened is doubled for each flap.

The suppression half-life is 15 minutes. The maximum suppress limit is four times the
half-life; thus, one hour is the default. The suppression penalty decays at half the half life
(7.5 minutes). So:

BGP Route Dampening Terms:

  • Flap—A route whose availability alternates repeatedly
  • History state—After a route flaps once, it is assigned a penalty and put into history
    state, meaning the router does not have the best path, based on historical information.
  • Penalty—Each time a route flaps, the router configured for route dampening in
    another autonomous system assigns the route a penalty of 1000. Penalties are
    cumulative. The penalty for the route is stored in the BGP routing table until the
    penalty exceeds the suppress limit. At that point, the route state changes from
    history to damp.
  • Damp state—In this state, the route has flapped so often that the router will not
    advertise this route to BGP neighbors
  • Suppress limit—A route is suppressed when its penalty exceeds this limit.
    The default value is 2000
  • Half-life—Once the route has been assigned a penalty, the penalty is decreased by
    half after the half-life period (which is 15 minutes by default). The process of
    reducing the penalty happens every 5 seconds.
  • Reuse limit—As the penalty for a flapping route decreases and falls below this
    reuse limit, the route is unsuppressed. That is, the route is added back to the BGP
    table and once again used for forwarding. The default reuse limit is 750. The
    process of unsuppressing routes occurs at 10-second increments. Every 10 seconds,
    the router finds out which routes are now unsuppressed and advertises them to the world
  • Maximum suppress limit—This value is the maximum amount of time a route can
    be suppressed. The default value is four times the half-life.

You can check for dampened paths by issuing the following command at the command prompt:

router#show ip bgp dampening dampened-paths

This works on Cisco, Juniper, Avici and HP routers.

Configuring Dampening:

  • enable
  • configure terminal
  • router bgp autonomous-system-number
  • address-family ipv4 [unicast | multicast | vrf vrf-name]
  • bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]
  • end

Checking default values:

R1#sh ip bgp dampening parameters
 dampening 15 750 2000 60 (DEFAULT)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750

BGP
No comments yet.

Tags: ,

by admin

Transit vs. Non-Transit Peering

When two autonomous systems (AS) peer, they can provide access to all their other peers
or to none of their peers. This is often established as part of the each autonomous system’s
routing policy.

 

TRANSIT

Transit is when traffic that originates outside your autonomous system, and is destined
for a network outside your AS is permitted to route through your AS. ‘Transit peering‘ is
the term used to describe an arrangement where an eBGP peer is permitted to communicate
with your other eBGP peers. The most common use of this is when an ISP allows their
customers using BGP to access all their other customers using BGP.

For example, let’s say AS 1 wishes to be able to reach AS 5 through AS 4. AS 4 would
accept AS 1’s announcements and then pass the single best route for each destination
on to AS 5. Traffic on AS5, destined for AS 1 may now transit through AS 4. Likewise,
AS1 and AS 4 would need to perform as transit if AS2 wishes to reach AS 5.

2        5
      /
1 — 4
/      
3      6

 
NON-TRANSIT

This is when you are providing one eBGP peer access to your network, but not to any
other eBGP peers you might have. This is useful for when a customer is connected to
two ISP’s networks, and wishes to have each ISP’s customers use their own connections
to reach him. The two ISP’s use a non-transit policy, while providing a transit policy for
all their customers. All customers can reach each other, but the ISPs cannot use the other
ISP to reach another ISP.

BGP
No comments yet.

Tags: ,

by admin

RIBS AND FIBS (AKA IP ROUTING TABLE AND CEF TABLE)

Every now and then, I’m asked about the difference between Routing Information Base (RIB),
also known as IP Routing Table and Forwarding Information Base (FIB), also known as CEF
table or IP forwarding table.

Let’s start with an overview picture (which does tell you more than the next thousand
words I’ll write):

 

A router has numerous ways of learning the best paths toward individual IP prefixes:
they might be directly connected, configured as static routes or learned through dynamic
routing protocols.

Each dynamic routing protocol (including RIP) has its own set of internal data structures,
known as OSPF/IS-IS database, EIGRP topology table or BGP table. The routing protocol
updates its data structures based on routing protocol updates exchanged with its neighbors,
eventually collecting all the relevant information.

Throughout this article we’ll work with 10.0.1.1/32 learned through OSPF and 10.0.11.11/32
learned through BGP, so let’s inspect the relevant OSPF/BGP data structures.
! 

RR#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
r>i10.0.1.1/32 10.0.1.1 0 100 0 i
r>i10.0.1.2/32 10.0.1.2 0 100 0 i
*>i10.0.11.11/32 10.0.1.1 0 100 0 i

!
RR#show ip ospf database router 10.0.1.1

OSPF Router with ID (10.0.1.5) (Process ID 1)
 

Router Link States (Area 0)

LS age: 1612

Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.1.1
Advertising Router: 10.0.1.1
LS Seq Number: 80000003
Checksum: 0xC764
Length: 60
Number of Links: 3

Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.0.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.0.1.6
(Link Data) Router Interface address: 10.0.7.9
Number of MTID metrics: 0
TOS 0 Metrics: 64

Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.7.8
(Link Data) Network Mask: 255.255.255.252
Number of MTID metrics: 0
TOS 0 Metrics: 64

reachable through that routing protocol and IP next hops that should be used to reach them.
You can view the results of these route selection algorithms with protocol-specific show
commands (for example, show ip bgp prefix for BGP and show ip ospf rib prefix
for OSPF).

RR#show ip bgp 10.0.11.11
BGP routing table entry for 10.0.11.11/32, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Local
10.0.1.1 (metric 66) from 10.0.1.1 (10.0.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best

RR#show ip ospf rib 10.0.1.1

OSPF Router with ID (10.0.1.5) (Process ID 1)

OSPF local RIB

Codes: * – Best, > – Installed in global RIB

*> 10.0.1.1/32, Intra, cost 66, area 0
SPF Instance 2, age 00:48:15
Flags: RIB, HiPrio
via 10.0.2.1, FastEthernet0/0, flags: RIB
LSA: 1/10.0.1.1/10.0.1.1

Both BGP and OSPF associate IP next hops with IP prefixes, but BGP simply uses the
value of the next-hop attribute attached to the BGP route, whereas OSPF computes
the IP address of the next-hop OSPF router with the SPF algorithm.

The results of intra-routing-protocol route selection are inserted in the IP routing table
(RIB) based on administrative distance (and there are interesting consequences if
two routing protocols have the same AD). Most routing protocols don’t complain
when their routes are not used in the IP routing table; BGP has a special show command
that can display RIB failures.

In our scenario, the 10.0.1.1/32 prefix is received via OSPF and BGP and the OSPF
route wins as OSPF has lower AD than internal BGP route.

RR#show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.0.1.1/32 10.0.1.1 Higher admin distance n/a
10.0.1.2/32 10.0.1.2 Higher admin distance n/a

Ideally, we would use RIB to forward IP packets, but we can’t as some 
entries in it

(static routes and BGP routes) could have next hops that are not directly connected.

Compare an IBGP route in the IP routing table (RIB) with an OSPF route:

RR#show ip route 10.0.11.11
Routing entry for 10.0.11.11/32
Known via “bgp 65000“, distance 200, metric 0, type internal
Last update from 10.0.1.1 00:00:55 ago
Routing Descriptor Blocks:
* 10.0.1.1, from 10.0.1.1, 00:00:55 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none

RR#show ip route 10.0.1.1
Routing entry for 10.0.1.1/32
Known via “ospf 1“, distance 110, metric 66, type intra area
Last update from 10.0.2.1 on FastEthernet0/0, 00:33:47 ago
Routing Descriptor Blocks:
* 10.0.2.1, from 10.0.1.1, 00:33:47 ago, via FastEthernet0/0
Route metric is 66, traffic share count is 1

OSPF route has an outgoing interface; it’s computed by the SPF algorithm 
and transferred in the IP routing table. BGP route has no outgoing 
interface and its next hop is not directly connected; the router has 
to perform recursive lookups to find the outgoing interface (recursive 
lookups are also used to implement EBGP load balancing with loopback 
interfaces).

Early IOS releases performed a recursive lookup on the first packet sent to a new
destination (process switching) and cached the result for subsequent packets
(fast switching). Fast switching worked well in early Internet (with few global IP prefixes),
but as the Internet grew and address-spraying DoS attacks became common, core
routers frequently experienced cachetrashing. Large number of packets were being
process switched, resulting in very high CPU utilization and occasional router meltdown.
It was time to move from cache-assisted forwarding to deterministic forwarding.

Forwarding Information Base (FIB) and Cisco Express Forwarding (CEF) switching
were introduced to make layer-3 switching deterministic. When IP routes are copied
from RIB to FIB, their next hops are resolved, outgoing interfaces are computed and
multiple entries are created when the next-hop resolution results in multiple paths
to the same destination.

For example, when the BGP route from the previous printout is inserted into FIB, its
next-hop is changed to point to the actual next-hop router. The information about the
recursive next-hop is retained, as it allows the router to update the FIB (CEF table)
without rescanning and recomputing the whole RIB if the path toward the BGP next-hop
changes.

RR#show ip cef 10.0.11.11 detail
10.0.11.11/32, epoch 0, flags rib only nolabel, rib defined all labels
recursive via 10.0.1.1
nexthop 10.0.2.1 FastEthernet0/0 label 19

Fully-evaluated FIB (CEF table) can then be used directly for layer-3 switching.

BGP
No comments yet.

(No tags)

by admin

BGP AS-Path Filter Lists

A filter list is a form of route policy that restricts the routes that will be advertised 
or accepted based on the AS-Path of the route. To configure a filter list, you must 
first create an AS-path access list based on the known paths you wish to permit.

as-path access-list xx permit 701
as-path access-list xx permit 701 6461
as-path access-list xx permit 701 6461 3

!
The list above will permit the following AS-paths:

701
701 6461
701 6461 3

To appy this list to a BGP session, use the following command:

neighbor <IP address> filter-list xx in|out

The list can be applied either to the route received (inbound) or the routes advertised
(outbound). Now let us suppose that to adjust the routing, an administrator at MIT
used AS-path-prepending to make routes to one provider more preferred over another.

This new prepended AS-path would look like this:

701 6461 3 3

This path would never be permitted through the AS-path filter because AS 3 appears
twice. Worse, suppose that after the filter was changed to match this, the administrator
at MIT decided to go back to a standard announcement, or decided to prepend twice.
This would mean a headache for the person maintaining the filter and delay needed
changes.

To make the list more flexible, Cisco has enabled the use of regular expressions in an
as-path filter list. The same list above could be rewritten to permit prepends from all
of the providers in the AS path, and even shorten the list:

as-path access-list xx permit ^(_701)+(_6461)*(_3)$

The filter list above would permit the following AS-paths:

701
701 701
701 6461
701 3
701 6461 3
701 6461 6461 3 3 3

Clearly this second list is shorter, and much more flexible.

The characters that are used above are as follows:

Char. Meaning
^ Beginning of character string
_ Any whitespace
( ) Brackets are used to group items together
NNN The numbers represent the number patterns of the AS numbers.
* Zero or more of the previous object
+ One or more of the previous object

 

The list above will permit the following AS-paths:

701
701 6461
701 6461 3

To appy this list to a BGP session, use the following command:

neighbor <IP address> filter-list xx in|out

The list can be applied either to the route received (inbound) or the routes advertised
(outbound). Now let us suppose that to adjust the routing, an administrator at MIT
used as-path-prepending to make routes to one provider more preferred over another.

This new prepended AS path would look like this:

701 6461 3 3

This path would never be permitted throught the AS-path filter because AS 3 appears
twice. Worse, suppose that after the filter was changed to match this, the administrator
at MIT decided to go back to a standard announcement, or decided to prepend twice.
This would mean a headache for the person maintaining the filter and delay needed
changes.

To make the list more flexible, Cisco has enabled the use of regular expressions in an
as-path filter list. The same list above could be rewritten to permit prepends from all
of the providers in the AS path, and even shorten the list:

as-path access-list xx permit ^(_701)+(_6461)*(_3)$

The filter list above would permit the following AS-paths:

701
701 701
701 6461
701 3
701 6461 3
701 6461 6461 3 3 3

Clearly this second list is shorter, and much more flexible.

The characters that are used above are as follows:

Char. Meaning
^ Beginning of character string
_ Any whitespace
( ) Brackets are used to group items together
NNN The numbers represent the number patterns of the AS numbers.
* Zero or more of the previous object
+ One or more of the previous object
BGP
No comments yet.

Tags: , ,

by admin

BGP weight attribute

Note that in the output of “show ip bgp” above, the weights assigned to each route to
192.168.3.0 are 0:

* 192.168.3.0 192.168.0.13 0 65004 65003 i
*> 192.168.0.2 0 65002 65003 i

we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest
(but not always best) way to do this is by using BGP’s weight attribute.

Zero is the default value. When multiple routes to the same destination exist, BGP will
prefer the route with the highest weight. To influence traffic to 192.168.3.0 to take the
path through AS 65004 (R4), we need to modify the weight assigned to the route
received from R4. There are a few ways of doing this, but we’re going to use a route
map (probably the most common method).

Just for verification, let’s look at what is currently in our routing table for 192.168.3.0/24:

R1# show ip route | include 192.168.3.0
B 192.168.3.0/24 [20/0] via 192.168.0.2, 00:17:31

We are, indeed, routing traffic to 192.168.3.0/24 via R2 (192.168.0.2).

Defining an access list

We are actually receiving multiple routes from R4, but only want to influence routing
for one route so we are going to use route maps in conjunction with an IP access list to
achieve our desired outcome. First, we need to define an access list that matches
192.168.3.0/24:

R1# configure terminal
R1(config)# access-list 3 permit 192.168.3.0 0.0.0.255
R1(config)# end

!
Defining a route map

With our access list now matching the networks we want to manipulate, we can now
create our route map (which we’ll call “NET3″). Our route map will be configured to
match traffic defined by access list 3 and will set the weight to 100:

R1# configure terminal
R1(config)# route-map NET3 permit 10
R1(config-route-map)# match ip address 3
R1(config-route-map)# set weight 100
R1(config-route-map)# route-map NET3 permit 20
R1(config-route-map)# end

You may be wondering about the “route-map NET3 permit 20″ statement, since it
doesn’t appear to do anything. From Cisco:

That’s exactly what we did in this case. If we had left out the “route-map NET3 permit
20″ statement, any other routes from R4 would not be accepted. Although we are only
going to be manipulating the route to 192.168.3.0/24 from R4, we still need to accept
all other routes from R4 into our BGP table.

Applying a route map to a neighbor

With our route map configured, we now need to instruct R1 to apply the route-map to
any updates received from our neighbor, R4. Easy enough:

R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# neighbor 192.168.0.13 route-map NET3 in
R1(config-router)# end

We’re pretty much set at this point. The changes won’t take effect immediately,
however. We need to restart the BGP process in order for our changes to take effect.

Let’s restart:

R1# clear ip bgp 65004
If we take a look at our BGP table, we should see that the route for 192.168.3.0/24 that
came from R4 (AS 65004) should now have a weight of 100 assigned to it, and it does:

*> 192.168.3.0 192.168.0.13 100 65004 65003 i

  • 192.168.0.2 0 65002 65003 i

Subsequently, we should see that the “new” route to 192.168.3.0/24 (via 192.168.0.13
 in AS 65004) was installed into our routing table:

R1# show ip route | include 192.168.3.0
B 192.168.3.0/24 [20/0] via 192.168.0.13, 00:01:56

And that’s all there it is to it!

BGP
No comments yet.

Tags:

by admin