Route Exchange
 |
| |
Which unicast routes from the local routing table are reported to the
DVMRP neighbor? By default, only the directly connected routes are reported. For
example, in Figure 8-5, we have a PIM-DM-enabled router connected through a
DVMRP tunnel to an MBONE DVMRP router. The configuration for the PIM router is
given below. |
| |
 |
| |
Figure 8-5: Connecting to the MBONE with a DVMRP
tunnel |
|
 | |
 |
| |
interface Ethernet 0 |
| |
| |
ip address 10.1.1.1 255.255.255.0 |
| |
 |
| |
interface Serial 0 |
| |
| |
ip address 10.1.2.1 255.255.255.0 |
| |
 |
| |
interface Tunnel 0 |
| |
| |
tunnel destination 10.1.1.2 |
| |
 |
| |
The
routing table for the PIM router contains the directly connected routes and any
routes learned through a dynamic unicast IP routing protocol. Assume that for
now the unicast routing table contains only the directly connected routes and
that the DVMRP route advertises two routes: |
| |
 |
| |
144.223.136.0/24 |
| |
 |
| |
Metric = 5 |
| |
|
 |
| |
156.26.31.0/24 |
| |
 |
| |
Metric = 7 |
| |
|
 |
| |
When
the PIM router receives the routes, the metric is increased by one and the
routes are placed in the local DVMRP routing table, which contains |
| |
 |
| |
144.223.136.0/24 |
| |
 |
| |
Metric = 6 |
| |
|
 |
| |
156.26.31.0/24 |
| |
 |
| |
metric = 8 |
| |
|
 |
| |
These routes are then reported back to the DVMRP router and are
oisoned-reversed. The routes from the local DVMRP table sent in the route report
are |
| |
 |
| |
144.223.136.0/24 |
| |
 |
| |
metric 38 |
| |
|
 |
| |
156.26.31.0/24 |
| |
 |
| |
metric 40 |
| |
|
 |
| |
The
routes that are reported from the unicast routing table to the DVMRP router
are |
| |
 |
| |
10.1.1.0/24 |
| |
 |
| |
Metric = 1 |
| |
|
 |
| |
10.1.2.0/24 |
| |
 |
| |
Metric = 1 |
| |
|
 |
| |
Notice that a default metric of one hop is used for the routes
reported from the unicast routing table. How do we advertise non-connected
networks from the unicast routing table? The answer is with the following
interface command on the tunnel interface: |
| |
 |
| |
ip dvmrp metric metric
[list access-list] {[protocol
process-id] |
dvmrp] |
| |
| |
ip dvmrp metric metric
route-map map-name |
| |
 |
| |
metric |
| |
 |
| |
Metric to be used for the routes in the DVMRP route report. The value
can be between 0 and 32. A value of 0 prevents a route or routes from being
advertised. A value of 32 indicates infinity or unreachable. |
| |
|
 |
| |
list access list |
| |
 |
| |
Optional. A standard IP access list can be used to control which
routes are reported. |
| |
|
 |
| |
protocol |
| |
 |
| |
Optional. Unicast routing protocol name (rip, igrp, eigrp, ospf, bgp,
isis, static, or dvmrp). |
| |
|
 |
| |
process-id |
| |
 |
| |
Optional. Unicast routing protocol process ID. |
| |
|
 |
| |
dvrmp |
| |
 |
| |
Optional. Allows routes in the DVMRP routing table to be filtered or
have their metric adjusted. |
| |
|
 |
| |
route-map |
| |
 |
| |
Filter the unicast routes that are reported using a route
map. |
| |
|
 |
| |
map-name |
| |
 |
| |
ip dvmrp metric <metric> |
| |
 |
| |
The
configuration for the DVMRP tunnel would be |
| |
 |
| |
interface Tunnel 0 |
| |
| |
tunnel destination 10.1.1.2 |
| |
 |
| |
What
we have done is make a very serious mistake. The dvmrp metric command applies to
every route in the unicast routing table. This is not too serious, however, if
the unicast routing table is small. If the table is large, on the order of
thousands of routes, then all these routes will be injected in the DVMRP router
and the MBONE. When something like this occurs, we usually need a rule to remind
us not to do it: |
| |
 |
| |
When
using the command ip dvmrp metric, always use an access list. |
| |
 |
| |
Another good rule when connecting PIM and DVMRP is to always use a
tunnel, because a tunnel gives us the maximum DVMRP capability. |
| |
 |
| |
If
we have the routes 172.16.1.0/24 and 202.5.6.0/24 in our routing table, for
example, and we only want to advertise the 172.16.1.0 network, then we could use
the access list shown below: |
| |
 |
| |
access-list 1 permit 172.16.1.0 0.0.0.255 |
| |
 |
| |
The
modified tunnel configuration would now contain |
| |
 |
| |
interface Tunnel 0 |
| |
| |
tunnel destination 10.1.1.2 |
| |
 |
| |
access-list 1 permit 172.16.1.0 0.0.0.255 |
| |
 |
| |
If
the value of the metric is 0, then this means the indicated routes will not be
advertised. Let’s look at some examples to illustrate some of the permutations
of this command. |
| |
 |
| |
ip dvmrp metric 0 |
| |
 |
| |
Do
not advertise any of the routes in the unicast routing table. The same effect
can be achieved by not even using this command. |
| |
|
 |
| |
ip
dvmrp metric 0 list 1 |
| |
 |
| |
Denies routes in list 1 but advertises others with a metric of
one. |
| |
|
 |
| |
ip
dvmrp metric 1 eigrp 100 |
| |
 |
| |
Advertises EIGRP routes in the routing table with a metric of
one. |
| |
|
 |
| |
ip
dvmrp metric 0 dvmrp |
| |
 |
| |
If
your network has more than one PIM-DVMRP boundary router, then you may want to
prevent DVRMP routes learned from one border from being advertised back into the
MBONE by another boundary router. This form of the command will prevent that
from happening. | |
201 times read
|
Related news
|
| No matching news for this article |
|
Did you enjoy this article?
(total 0 votes)
|