| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 800.1 | | MARVIN::PATEL | | Fri Mar 14 1997 04:52 | 11 |
| What version of the software are you running ? If you are running V2.0 then you can
DTF to trace the packets ( you will need to trace the output interface and filter IP
packets and search for BGP - although the BGP analysis is there in DTF, there are no
BGP tracepoints yet).
Also check what BGP events are being logged - you can either do this by enabling the
BGP events at the console or tracing the ELS tracepoint using DTF).
Can you dump the IP routing tables and post them here ? This is to make sure all the
routes you expect in BGP are actually in the routing tables.
As for the masks I am not aware of any problems with extending it beyond 24 bits.
I think you will need to submit a CLD ( if it is a customer problem ) or a PTR for the
problem to be investigated.
|
| 800.2 | .1 reformatted for the width-impaired (like me) | MARVIN::CLEVELAND | | Fri Mar 14 1997 06:01 | 16 |
|
<<< Note 800.1 by MARVIN::PATEL >>>
What version of the software are you running ? If you are running V2.0
then you can DTF to trace the packets ( you will need to trace the
output interface and filter IP packets and search for BGP - although
the BGP analysis is there in DTF, there are no BGP tracepoints yet).
Also check what BGP events are being logged - you can either do this by
enabling the BGP events at the console or tracing the ELS tracepoint
using DTF). Can you dump the IP routing tables and post them here ?
This is to make sure all the routes you expect in BGP are actually in
the routing tables. As for the masks I am not aware of any problems
with extending it beyond 24 bits. I think you will need to submit a CLD
( if it is a customer problem ) or a PTR for the problem to be
investigated.
|
| 800.3 | 4 net's only 3 announced. | STKHLM::WEBJORN | Gullik Webj�rn Network Advisory | Fri Mar 14 1997 11:34 | 31 |
|
I have upgraded the DecSwitch to 2.0.2. That cured the problem with
not sending subnet mask 192. It now says it announces that net
with mask FFFFFFC0. My ori and send rules say the same.
However, I have 5 nets on the box. On e net is the BGP backbone
(Gigaswitch) and that net is not announced.
The other four nets are
192.121.118.0 255.255.255.0
192.121.119.0 255.255.255.0
192.121.126.0 255.255.255.0
195.54.128.0 255.255.255.192
the net
192.121.126.0 255.255.255.0 is not displayed as announced.
locally I can ping 192.121.126.253 which is the router I/F.(from
the other nets) so it's UP.
It's such a simple config...??
Gullik
|
| 800.4 | Bug is in way BGP destinations are displayed | MARVIN::PATEL | | Fri Mar 21 1997 09:35 | 7 |
| After several mail exchanges with Gullik regarding this note, here is
the final result.
The bug is in the way the destinations for a neighbor are displayed. When
walking the binary tree of routes, the code starts at sequence 1 instead
of sequence 0 and hence always misses out 1 route in the display. There
is no problem with the actual exchange of routes between the BGP
neighbors.
|