From: jsung7 (jsung7@yahoo.com)
Date: Mon Oct 11 2004 - 21:07:41 GMT-3
Hi Tim,
Regarding your second question, I found the following information:
"via 0.0.0.0": the next hop field. In "Troubleshooting Campus Networks"
by Priscilla Oppenheimer and Joseph Bardwell, Page 310:
"...Next hop. Specifies a better next-hop address (if one exists) than
the address of the advertising router. The next hop field indicates a
next-hop address, on the same subnet, that is metrically closer to the
destination than the advertising router. If the field is set to
0.0.0.0, then the address of the advertising router is tbe best
next-hop address. This field is especially useful when RIP is not in
use on all routers in an internetwork. See Appendix A of RFC 1723 for
an exampel..."
The first requestoin, I did some search on the Internet. FYI.
I. At 13:41 9.8.2001,
cisco@groupstudy.com/msg57980.htm">http://www.mail-archive.com/cisco@groupstudy.com/msg57980.htm,
Priscilla:
"...Here are some things to check:
Are both routers using RIPv2?
Is there a split horizon issue that is suppressing the update?
Have you done anything tricky with subnet masks and VLSM?
Is there a summarization issue?
On the router that is sending but then suppressing updates, (serial
interface 70.0.0.2), what is its subnet mask? What is the address and
subnet mask of the router at the other end?
Can you send us your configs?..."
II. A thread in Group Study on Wed, 28 Jun 2000, Omer wrote: Subject:
suppressing null update.
Howard C. Berkowitz wrote:
"Suppressing null update usually means:
Your router has not recognized another router on the subnet in
question, so there is no useful information to send to it.
Your router has recognized another router, but has no useful
information to send to it."
From Michael Fountain:
"Usually you will see this when you have a distribute list in place and
the distribute list is blocking all of the updates. It could also
happen if the router has only one connection active - all of the routes
it knows about would come from that interface so it would supress all
of those routes from going out that interface because of split
horizon."
From: Omer Shommo
"I have found what the problem was. Before I explain what happen,
please examine the configuration of IP RIP and ip
configuration of serial 0 from the output bellow.
R3#sh ip int brief
Interface IP-Address OK? Method Status
Protocol
Serial0 180.180.2.2 YES manual up
up
Serial0.1 160.160.1.1 YES manual up
up
Serial0.2 160.160.2.1 YES manual up
up
Serial1 unassigned YES unset down
down
TokenRing0 unassigned YES unset administratively down
down
R3#sh running-config
router rip
network 180.180.0.0
network 160.160.0.0
!
no ip classless
!
I used the "no network 160.160.0.0" command to remove network
160.160.0.0 from rip update. Although I did not
remove network 180.180.0.0, RIP suppressed update via serial 0
altogether, apparently because network 160.160.0.0 is
configured for a subinterface of serial 0 !!!! "
===============
--- ccie2be <ccie2be@nyc.rr.com> wrote:
> Hi guys,
>
> This is some output from deb ip rip.
>
>
> *Oct 11 15:09:13.623: RIP: build update entries - suppressing null
> update
> *Oct 11 15:09:13.623: RIP: sending v2 update to 224.0.0.9 via
> Loopback0
> (150.3.6
> .6)
> *Oct 11 15:09:13.623: RIP: build update entries - suppressing null
> update
> Rack1R6#
> *Oct 11 15:09:22.347: RIP: received v2 update from 204.12.3.254 on
> FastEthernet1
> /0/0.263
> *Oct 11 15:09:22.347: 30.0.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.347: 30.1.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.347: 30.2.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.347: 30.3.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.347: 31.0.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.351: 31.1.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.351: 31.2.0.0/16 via 0.0.0.0 in 1 hops
> *Oct 11 15:09:22.351: 31.3.0.0/16 via 0.0.0.0 in 1 hops
>
> There are a couple of things I'm not that clear on from the output.
> I'm
> hoping someone can shed some light.
>
> 1) suppressing null update Why is this here and what does this
> really mean?
>
> 2) via 0.0.0.0 Why is 0.0.0.0 being used and not the actual source
> ip address
> shown right above, 204.12.3.254 ?
>
> Thanks, Tim
>
>
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:46 GMT-3