Re: [eng/rtg] changing loopbacks
--- Austin [EMAIL PROTECTED] wrote: It's worth noting that C's don't need actual IP address space assigned to the router-id for OSPF. It's just an arbitrary value; it's probably better karma to set it to whatever you want (maybe something that doesn't look like an IP address). RFC 2328: Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System. eek! There are a couple of downsides to having the router-ID divorced from a physical address: 1) you get an additional number which you have to have to track to ensure uniqueness. 2) you lose the benefit of being able to double check reachability (ping/ssh to router ID) 3) RFC 1403 says that the BGP router identifier must be the same as the OSPF router ID, and do you really want your BGP to reflect an unreachable ID? I've had a customer who used unreachable router IDs, and it made their NOC work quite a bit harder than they otherwise would have had to... -David __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [eng/rtg] changing loopbacks
[EMAIL PROTECTED] wrote: eek! There are a couple of downsides to having the router-ID divorced from a physical address: 1) you get an additional number which you have to have to track to ensure uniqueness. 2) you lose the benefit of being able to double check reachability (ping/ssh to router ID) No doubt, but the OP was trying to fend off OSPF adjacency teardowns when renumbering loopbacks. 3) RFC 1403 says that the BGP router identifier must be the same as the OSPF router ID, and do you really want your BGP to reflect an unreachable ID? Wait a second... RFC 1403 3. BGP Identifier and OSPF router ID The BGP identifier MUST be the same as the OSPF router id at all times that the router is up. This characteristic is required for two reasons. iSynchronisation between OSPF and BGP Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, belong to the same autonomous system. +-+ | RT3 | +-+ | Autonomous System running OSPF / \ +-+ +-+ | RT1 | | RT2 | +-+ +-+ Both RT1 and RT2 have routes to an external network X and import it into the OSPF routing domain. RT3 is advertising the route to network X to other external BGP speakers. RT3 must use the OSPF router ID to determine whether it is using RT1 or RT2 to forward packets to network X and hence build the correct AS_PATH to advertise to other external speakers. More precisely, RT3 must determine which ASBR it is using to reach network X by matching the OSPF router ID for its route to network X with the BGP Identifier of one of the ASBRs, and use the corresponding route for further advertisement to external BGP peers. /RFC 1403 Can someone explain that? Why would RT3 care about the BPG identifiers of the other ASBR's? Why would the ASBR's even have BGP identifiers? What BGP attribute has anything to do with this? Austin --On Sunday, October 02, 2005 12:55 PM -0700 David Barak [EMAIL PROTECTED] wrote: eek! There are a couple of downsides to having the router-ID divorced from a physical address: 1) you get an additional number which you have to have to track to ensure uniqueness. 2) you lose the benefit of being able to double check reachability (ping/ssh to router ID) 3) RFC 1403 says that the BGP router identifier must be the same as the OSPF router ID, and do you really want your BGP to reflect an unreachable ID? I've had a customer who used unreachable router IDs, and it made their NOC work quite a bit harder than they otherwise would have had to... -David
Re: [eng/rtg] changing loopbacks
On Fri, 30 Sep 2005, Christopher L. Morrow wrote: ospf doesn't, for router-id on cisco's atleast, as Warren pointed out :( however! switching from ospf to 'another igp' (ISIS would work well) would avoid that, slide off ospf and onto ISIS, kill ospf when all next-hops switch, which should be 'as soon as isis converges'. It is a good reason to assign seperate router IDs, rather than rely on the OSPF implementation to decide which IP is the one it will use. Of course not all vendors support this. The major router vendors do, though. -Sean
Re: [eng/rtg] changing loopbacks
It's worth noting that C's don't need actual IP address space assigned to the router-id for OSPF. It's just an arbitrary value; it's probably better karma to set it to whatever you want (maybe something that doesn't look like an IP address). RFC 2328: Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System. CCO: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_command_reference_chapter09186a008010a39c.html#wp1049279 Usage Guidelines You can configure an arbitrary value in the IP address format for each router. However, each router ID must be unique. If this command is used on an OSPF router process which is already active (has neighbors), the new router-ID is used at the next reload or at a manual OSPF process restart. To manually restart the OSPF process, use the clear ip ospf command.
Re: [eng/rtg] changing loopbacks
Are you using any logging-source or source interface for your authentication on the boxes? I've found that most versions of IOS require a reboot to accept a change of these. Similarly, OSPF under IOS will need a bounce/reboot to change it's router-ID if you are using the loopback for that. Personally, the cleanest way I've been able to accomplish changing this in regard to OSPF, logging and authentication on Cisco's is to suck down the running config, make the changes in your editor of choice, push it back up to startup-config and schedule a reboot. iBGP is much easier to make the changes as you outline. As always, your mileage may vary. David On Sep 29, 2005, at 11:05 AM, Randy Bush wrote: so i have junipers, ciscos, and a few gasp zebras in an ospf and ibgp mesh. they're peering via loopbacks, of course. unfortunately, i need to recover the space from which the loopbacks are taken. of course, i would like to do so with minimal disruption. i am thinking of something like the following: o add second loopbacks to all routers with new address in new block o set up ibgp peerings to new addresses from existing peerings o change the source of routing updates to new addresses o remove old peerings o remove old loopbacks what [else] am i missing? randy
Re: [eng/rtg] changing loopbacks
Personally, the cleanest way I've been able to accomplish changing this in regard to OSPF, logging and authentication on Cisco's is to suck down the running config, make the changes in your editor of choice, push it back up to startup-config and schedule a reboot. iBGP is much easier to make the changes as you outline. this is my fear. which is why i asked. pushing out new configs (the canonic config is on disk, not the router [0]) and setting a reload of a bunch of routers at time t0 does not give me warm fuzzies about what the world will be like at time tn (n 0). but i may have to take that path. i am hoping folk will give me a magic pill. after all, any group with such a deep understanding of how to deal with the world's social ills must know a bit of router magic smirk. randy --- [0] - i once worked at a large company who was proud of saying that the network is the database of record. i left there rather quickly.
RE: [eng/rtg] changing loopbacks
this is my fear. which is why i asked. pushing out new configs (the canonic config is on disk, not the router [0]) and setting a reload of a bunch of routers at time t0 does not give me warm fuzzies about what the world will be like at time tn (n 0). but i may have to take that path. i am hoping folk will give me a magic pill. after all, any group with such a deep understanding of how to deal with the world's social ills must know a bit of router magic smirk. I think with OSPF this will be very difficult to do without rebooting (or as long an outage as rebooting). We migrated from OSPF to IS-IS and changed some loopbacks a while ago, the IS-IS change was totally transparent - no issue, but on the change of loopback caused a lot of BGP churn. It was easier to change it and reboot and do it over a period of time in small network triangles. I always thought that the billing system was the database of record ;-) Neil.
Re: [eng/rtg] changing loopbacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Randy Bush wrote: so i have junipers, ciscos, and a few gasp zebras in an ospf and ibgp mesh. they're peering via loopbacks, of course. unfortunately, i need to recover the space from which the loopbacks are taken. of course, i would like to do so with minimal disruption. i am thinking of something like the following: o add second loopbacks to all routers with new address in new block o set up ibgp peerings to new addresses from existing peerings o change the source of routing updates to new addresses o remove old peerings o remove old loopbacks what [else] am i missing? In addition to what others have said, I'd ask: - - Any ACL's anywhere that filter based on the old loopbacks? - - Any VTY access controls on the router based on the old loopbacks? - - Any external systems like authentication servers, management systems, etc, etc that need the old loopbacks and can't dynamically adapt? - - Any internal routing policies that reference the old loopbacks? - - Any DNS entries that need to be migrated (CNAME-A references)? - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDPE3ME1XcgMgrtyYRApizAKDUz+80NvW2tdMfyivgLGA8+uJ1dQCdF54a VzUeshCuqbV0dlI3D3Poqxw= =jOI/ -END PGP SIGNATURE-
Re: [eng/rtg] changing loopbacks
### On Thu, 29 Sep 2005 13:25:48 -0700, Bruce Pinsky [EMAIL PROTECTED] ### casually decided to expound upon Randy Bush [EMAIL PROTECTED] the ### following thoughts about Re: [eng/rtg] changing loopbacks: BP what [else] am i missing? BP BP In addition to what others have said, I'd ask: BP BP - - Any ACL's anywhere that filter based on the old loopbacks? BP - - Any VTY access controls on the router based on the old loopbacks? BP - - Any external systems like authentication servers, management systems, BP etc, etc that need the old loopbacks and can't dynamically adapt? BP - - Any internal routing policies that reference the old loopbacks? BP - - Any DNS entries that need to be migrated (CNAME-A references)? Also want to keep in mind things like tunnel endpoints (IPv6, VOIP, multicast, VPN, etc). Barring any sort of advanced config management package, grep and diff become your friends (some would say despite). As a first pass, I'd snarf down all configs and do a grep for the loopbacks to indtify which ones need attention. Then make your changes in each config and do diffs to verify. Then I'd stage out deployment with stub and leaf nodes going last to minimise churn in OSPF. If you've got iBGP going and are using route-reflectors then do the top-most hierarchy first before the lower clusters. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Re: [eng/rtg] changing loopbacks
Randy Bush wrote: Personally, the cleanest way I've been able to accomplish changing this in regard to OSPF, logging and authentication on Cisco's is to suck down the running config, make the changes in your editor of choice, push it back up to startup-config and schedule a reboot. iBGP is much easier to make the changes as you outline. this is my fear. which is why i asked. pushing out new configs (the canonic config is on disk, not the router [0]) and setting a reload of a bunch of routers at time t0 does not give me warm fuzzies about what the world will be like at time tn (n 0). but i may have to take that path. i am hoping folk will give me a magic pill. after all, any group with such a deep understanding of how to deal with the world's social ills must know a bit of router magic smirk. You may need to change your BGP router-id to match if you set it explicitly, which *may* alter path selection (a long way down the tree I admit). Another nasty is if you run TE and use the old Loopback as your TE-ID, even with IS-IS. Plus of course, your zone/hosts file for managing/polling these nodes in the first place :-) -- Ian Dickinson Development Engineer PIPEX [EMAIL PROTECTED] http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
Re: [eng/rtg] changing loopbacks
On Fri, Sep 30, 2005 at 12:14:46AM +0100, Ian Dickinson wrote: Randy Bush wrote: Personally, the cleanest way I've been able to accomplish changing this in regard to OSPF, logging and authentication on Cisco's is to suck down the running config, make the changes in your editor of choice, push it back up to startup-config and schedule a reboot. iBGP is much easier to make the changes as you outline. this is my fear. which is why i asked. pushing out new configs (the canonic config is on disk, not the router [0]) and setting a reload of a bunch of routers at time t0 does not give me warm fuzzies about what the world will be like at time tn (n 0). but i may have to take that path. i am hoping folk will give me a magic pill. after all, any group with such a deep understanding of how to deal with the world's social ills must know a bit of router magic smirk. You may need to change your BGP router-id to match if you set it explicitly, which *may* alter path selection (a long way down the tree I admit). Another nasty is if you run TE and use the old Loopback as your TE-ID, even with IS-IS. Plus of course, your zone/hosts file for managing/polling these nodes in the first place :-) -- Ian Dickinson Development Engineer PIPEX [EMAIL PROTECTED] http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html Of course, you can always pre-deploy ibgp sessions and TE configs to the new address (which will remain down until the new address exists), go for your OOB access to the box, change the loopback IP address (and associated references), clear ip bgp * and accept the 2 minute interruption. Changing loopback IPs is difficult to do gracefully but can still be done relatively quickly. IS-IS and OSPF should be able to pick up the change as soon as the IP address is entered into the config. --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: [eng/rtg] changing loopbacks
On Thu, 29 Sep 2005, Wayne E. Bouchard wrote: chopped ian's good infos Of course, you can always pre-deploy ibgp sessions and TE configs to the new address (which will remain down until the new address exists), go for your OOB access to the box, change the loopback IP address (and associated references), clear ip bgp * and accept the 2 minute interruption. Changing loopback IPs is difficult to do gracefully but can still be done relatively quickly. The clearing MIGHT have a larger effect, especially depending on the number of peers you have and this device's placement in your network. I'd think that a graceful bgp switchover would be simple enough (and wouldn't require clear ip bgp *) The devil, IMHO, is in the IGP switches :( (not withstanding ian's noted bgp router-id change) IS-IS and OSPF should be able to pick up the change as soon as the IP address is entered into the config. ospf doesn't, for router-id on cisco's atleast, as Warren pointed out :( however! switching from ospf to 'another igp' (ISIS would work well) would avoid that, slide off ospf and onto ISIS, kill ospf when all next-hops switch, which should be 'as soon as isis converges'.
