FW: router startup behavior
Forwarded to the list: -----Original Message----- Subject: RE: router startup behavior On Tue, 15 Jan 2002, Borchers, Mark wrote: Mark, I don't have nanog post so, if you could pass this along for me, I believe that it may be "obvious" advice and it seems that the obvious is what escapes us most often.
Yeah, (c) seems most likely to me. Ratul, a script like this or some variant could cause what you are seeing:
config-router# no neighbor <a> config-router# no neighbor <b> config-router# no neighbor <c> (script to rewrite filters executes) config-router# neighbor <a> remote-as <x> config-router# neighbor <b> remote-as <y> config-router# neighbor <c> remote-as <z> (sessions start coming up) config-router# neighbor <a> route-map <A> out config-router# neighbor <b> route-map <B> out config-router# neighbor <c> route-map <C> out config-router# Ctrl-Z # clear ip bgp external soft out
Just guessing - you're seeing these events between midnight and 5 am?
Wouldn't it be wiser to do the following: config-router# no neighbor <a> config-router# no neighbor <b> config-router# no neighbor <b> (script to rewrite filters executes) config-router# neighbor <a> remote-as <x> config-router# neighbor <a> shutdown config-router# neighbor <b> remote-as <y> config-router# neighbor <b> shutdown config-router# neighbor <c> remote-as <z> config-router# neighbor <c> shutdown config-router# neighbor <a> route-map <A> out config-router# neighbor <b> route-map <B> out config-router# neighbor <c> route-map <C> out config-router# no neighbor <a> shutdown config-router# no neighbor <b> shutdown config-router# no neighbor <c> shutdown config-router# Ctrl-Z # clear ip bgp external soft out This way, the neighbor has much less time to come up without filters since we're immediately putting it in admin idle after naming it. --- John Fraizer EnterZone, Inc
This way, the neighbor has much less time to come up without filters since we're immediately putting it in admin idle after naming it.
It's not as bad as it sounds though - IOS waits for 30 seconds after the "neighbor w.x.y.z remote-as 123" before trying to bring the sessions up - giving you time to complete the configuration. 30 seconds always seems long enough for a manual configuration (unless the phone rings after the first line), so an automatic configuration should be fine. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
You may want to consider using tftp/rcp/whatnot loaded files for this. As it loads [most if not all depending on the config length] all of the config then parses it promptly. this will prevent leakage in rare cases. - jared On Tue, Jan 15, 2002 at 07:21:18PM +0000, Simon Lockhart wrote:
This way, the neighbor has much less time to come up without filters since we're immediately putting it in admin idle after naming it.
It's not as bad as it sounds though - IOS waits for 30 seconds after the "neighbor w.x.y.z remote-as 123" before trying to bring the sessions up - giving you time to complete the configuration. 30 seconds always seems long enough for a manual configuration (unless the phone rings after the first line), so an automatic configuration should be fine.
Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
In the referenced message, Jared Mauch said:
You may want to consider using tftp/rcp/whatnot loaded files for this.
As it loads [most if not all depending on the config length] all of the config then parses it promptly.
this will prevent leakage in rare cases.
- jared
I have noted that even tftp-loaded files run the risk of a BGP scan occuring between the parsing of "no access-list foo" and the parsing of the first "access-list foo" line. It appears Brand C takes the non-existance of an access-list to mean "implicit permit". I think this is probably the source of much of the seen mini-leaks. As someone else mentioned, prefix-lists (again brand C) do allow for insertion and deletion of individual items at "any" point in the list, so may be a good workaround. However, if you are doing anything at all "interesting" in your acls, it becomes a lot more difficult to translate over to prefix-lists. One major item that seems missing is the ability to match less-specifics. There are certain instances when this would be really nifty. Brand C extended acls, and Brand J prefix-lists seem to be able to partially cover this, but not perfectly.
On Fri, Jan 18, 2002 at 04:03:35PM -0500, Stephen Griffin wrote:
In the referenced message, Jared Mauch said:
You may want to consider using tftp/rcp/whatnot loaded files for this.
As it loads [most if not all depending on the config length] all of the config then parses it promptly.
this will prevent leakage in rare cases.
- jared
I have noted that even tftp-loaded files run the risk of a BGP scan occuring between the parsing of "no access-list foo" and the parsing of the first "access-list foo" line. It appears Brand C takes the non-existance of an access-list to mean "implicit permit". I think this is probably the source of much of the seen mini-leaks.
i had a mini-leak that was only related to an adjacent router rebooting that also originated the p2p /30 i think there is some bug w/ community based filtering that allowed it to leak. (i am following up with the related vendor) - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (4)
-
Borchers, Mark -
Jared Mauch -
Simon Lockhart -
Stephen Griffin