I have found that VC3 is very fussy about adding routes. Changing an 
interface and deleting the node followed by recreating it with new 
settings leads to no routing table entries for me.
I have found that the only way to get a correct table is to start from a 
clean format

David

Aubrey Wells wrote:
> It is the next hop. To give you one of the scenarios:
>
> Added 8.17.X.253 /30 to eth0 vif 1180
>
> subnet doesnt show up in vyatta's routing table (show route) but does  
> show up in the system table (route -n) and I can ping the other side  
> (8.17.X.254) both from within xorp and from the unix shell.
>
> So then I add a static route for 3 subnets pointing to the (directly  
> connected) route of the other side of that /30 (8.17.X.254). show  
> route from xorp says its next hop is my default route. show  
> configuration shows that I didnt screw up i did in fact do what i  
> meant to. the system routing table (route -n) says the same thing as  
> the xorp table (that i configured it to be the same as the default  
> route). So the route doesnt work, and what's worse, is if I try to  
> delete it from the config (delete protocols static 216.32.X.0/20 next- 
> hop 8.17.X.254) it tells me I cant delete a non-existant route. If I  
> try to put what it thinks the route is, it says the node doesnt  
> exist. I have to delete the offending line from the config file with  
> vi and reboot (or load config.boot now that I know that) to get it  
> back to a state where I can work with it. And this pesky line shows  
> up in the log. I dont see anything interesting in any other logs that  
> I know about:
>
>   
>> 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
>>     
>
>
> THe other scenario:
> IP 8.17.X.113 /28 exists on eth1 vif 1192. I remove it and commit.  
> Its gone out of both the system and xorp routing tables. i read it as  
> 8.17.X.113 /29 and commit. It doesnt show up in the xorp table, but  
> it is in the system table. I get the same log message as above and my  
> system hates me for it. The route works (i can ping the other side)  
> but I can't configure any services to use it. :-(
>
>
> *sigh* Any ideas?
>
> I searched bugzilla, and only came up with bug 1602, which appears to  
> be the exact opposite of my issue. I'm going to try to reproduce on a  
> dev box and use my subscription support to see if one of you guys can  
> log in to it and poke around.
>
>
> ------------------
> Aubrey Wells
> Senior Engineer
> Shelton | Johns Technology Group
> A Vyatta Ready Partner
> www.sheltonjohns.com
>
>
>
>
> On Nov 6, 2007, at 12:08 AM, Justin Fletcher wrote:
>
>   
>> No problem - I know exactly how you feel some days!
>>
>> And I'd missed the point that it didn't make into the system route  
>> table, so the
>> first question I'd ask is whether the next hop you're specifying is
>> directly connected?
>> If it isn't, try using the IP address of the directly connected  
>> next hop router.
>>
>> If it is, well, there's a bit more to figure out, as I've never seen
>> that behavior.
>>
>> To try a rephrase on the load config command, it'll make your running
>> configuration
>> match the configuration in the file (usually :-) )
>>
>> Justin
>>
>> On Nov 5, 2007 8:52 PM, Aubrey Wells <[EMAIL PROTECTED]> wrote:
>>     
>>> 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
>>>
>>> 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
>
>   

_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users

Reply via email to