Thanks for the response - sorry for my impatience. :-)
I dont mind the viewing discrepancy, its the fact that vyatta doesn't
recognize the existance of the routes - so I can't do anything with
them. So you're saying load config.boot should fix the problem? Will
that cause any downtime while it rereads the config, or should it be
seamless?
Also... maybe its just because its been a really long day, but this
sentence doesn't make any sense:
"it'll remove everything that's not in the current configuration
that's in the config file, and add the new commands from the config
file."
Could you possibly rephrase for me? :-)
------------------
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
404.478.2790
www.sheltonjohns.com
On Nov 5, 2007, at 11:31 PM, Justin Fletcher wrote:
Good questions - I think you're just seeing a synchronization issue.
If you see it in the system route table ("route -n" from the Linux
shell or "show route system forward" from the CLI) it's really in the
system RIB as the forwarding information base is updated from the RIB.
However, "show route" looks at a different table, and can be somewhat
out of sync.
So - if you see the route from "show route system forward" it made it
into the route tables correctly - you're just seeing a viewing
discrepancy issue.
Also, you can load the configuration using "load config.boot" in
config mode; it'll remove everything that's not in the current
configuration that's in the config file, and add the new commands from
the config file.
Best,
Justin
On Nov 5, 2007 8:08 PM, Aubrey Wells <[EMAIL PROTECTED]> wrote:
Anyone? :-(
------------------
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
404.478.2790
www.sheltonjohns.com
On Nov 3, 2007, at 10:16 PM, Aubrey Wells wrote:
Hi,
I'm having this really frustrating problem where occasionally I
will add an
ip/network to vyatta, or delete an ip and readd it to the same
interface
with a different prefix-length or move it to a different interface
(with a
commit in between) and vyatta will not recognize that the ip/
network has
been added.
For instance, this evening, I was attempting to add 8.17.X.253 /30 to
interface eth1 on vif 1180. If i look at the system routing table,
it is
added on the correct interface and traffic passes to the host on
the other
side. But if I do a "show route" in vyatta the subnet is not there
and as
such, if I try to point a static route at it, the route instead
gets added
to whatever my default route is. for example:
set protocols static route 1.2.3.0/8 next-hop 8.17.X.254
that gets added to the config file fine, but a "show route" shows
it having
a next hop of my default route. The system routing table does the
same.
Also, I cannot delete this route from the config without doing it
by hand
with VI and rebooting (says the route doesnt exist).
Also, I tried to remove 8.17.X.113 /28 and readd it as 8.17.X.113 /
27. I
removed the ip, commited, and readded it. The subnet didnt show up
in the
vyatta routing table after a commit but it was in the system
routing table
(route -n). Traffic passed just fine.
When I commit those changes, I see this in the messages log:
Nov 4 01:49:47 vyatta xorp_fea: [ 2007/11/04 01:49:47 WARNING
xorp_fea FEA
] Got update for address no in lib
feaclient tree: eth0.1180/eth0.1180/8.17.X.253
Nov 4 01:49:47 vyatta xorp_fea: [ 2007/11/04 01:49:47 WARNING
xorp_fea FEA
] Got update for address no in lib
feaclient tree: eth1.54/eth1.54/8.17.X.113
If I save the config, and reboot the box, the configuration loads
up just
fine and all my subnets/routes are correct. This is not a
solution, as this
is my core router in a fast-growing network and I cant go around
rebooting
it every time I add a subnet.
I'm running the last VC3 beta. (I havent upgraded to VC3 release
because I
didnt want to reboot the box without scheduling a window.... heh)
This also happened in VC2.2. I'm not 100% sure about weather or
not it
happens on a PHY, but I think it did, although most of my stuff is
on VIFs.
Please help!
Oh, and is there a way to get it to dump and reload the config
from scratch
without rebooting? These DELL's have a horrendous POST time
because of the
RAID, DRAC, and BMC BIOSes that all have to load (plus the
overhead of
checking 8G of memory)!
------------------
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
A Vyatta Ready Partner
www.sheltonjohns.com
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
