- mice-discuss - lists.micemn.net

Re: Juniper Switch upgrade

by Doug McIntyre

On Thu, Aug 23, 2012 at 01:33:13PM -0500, James Stahr wrote: > We can remotely verify that everyone has configured a secondary IP, > but that's just the start. You've also got to duplicate ALL of your > peer BGP sessions beforehand as well. Why? Well, > I don't believe Cisco can initiate a BGP session on a secondary > address so once a $C router switches their primary and secondary, > they cannot initiate a BGP session. Not a problem yet. What about > when the next one does it? Suddenly neither of the Cisco devices > can peer with each other.. I've not been through an exchange > re-address, but given this limitation, I foresee many problems and > the idea of a "flag day" much more appealing - luckily though, most > participants are using the route server. Yeah, I was thinking of that issue as well. Perhaps subinterfaces could be used like int gig 0/0 ip address 69.147.218.100/24 int gig 0/0.0 ip address 206.108.255.100/24 router bgp 65500 neighbor 69.147.218.1 update-source gig0/0 neighbor 206.108.255.1 update-source gig0/0.0 but I don't have anything to test that out with right now. (not using cisco to talk to MICE right now). But I think my two bilateral peers can probably wait for a renumber at some future time as it is. > Hmm... I assume the BIRD configuration allows you to specify source > IP's to be used for each peer? It looks like 'router id' is allowed per AS peer. Leave the existing, and setup a new peer entry to the new IP with the new 'router id'. -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

MNNS or Digital Plains outage?

by Frank Bulk

We have some email queued up to a domain that use digitalplains.net DNS servers (company based in Slayton). Those servers don't respond, and calling the target domain (based in Pipestone) they said that there's an issue upstream, something with Knology. Apparently Digital Plains recently assumed responsibility for all MNNS.COM services, and I can't hit any of their web properties, either. I called Digital Plains toll free support number, but it just goes to someone's voicemail. Anyone know what's going on? Frank ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by James Stahr

On 8/22/2012 4:51 PM, Doug McIntyre wrote: > On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: > >> While I agree with the general sentiment that the IP change and switch >> change will likely be smooth, the IP change can be done more >> transparently and has literally nothing to do with the L2 gear. >> To that end, I don't see any reason to not configure/assign the new IP >> block now and let folks start using it right away, even before the >> switch switch. >> > But, we don't have a central router? > > If your border to the exchange right now got a prefix with the next > hop of 206.108.255.3, how'd you get there? You'd have no route to host > for 206.108.255.3. > > That is why I brought up the secondary IPs. Once everybody puts in a > secondary IP in 206.108.255.0/24, they'll know how to try to get to > 206.108.255.3 for my prefix announcement. But I can't really do the > prefix announcement with the next-hop in 206.108.255.3 until everybody > knows how to get to 206.108.255.0/24? > > We can remotely verify that everyone has configured a secondary IP, but that's just the start. You've also got to duplicate ALL of your peer BGP sessions beforehand as well. Why? Well, I don't believe Cisco can initiate a BGP session on a secondary address so once a $C router switches their primary and secondary, they cannot initiate a BGP session. Not a problem yet. What about when the next one does it? Suddenly neither of the Cisco devices can peer with each other.. I've not been through an exchange re-address, but given this limitation, I foresee many problems and the idea of a "flag day" much more appealing - luckily though, most participants are using the route server. Hmm... I assume the BIRD configuration allows you to specify source IP's to be used for each peer? -James CDW ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 04:45:17PM -0700, Mike Tindle wrote: > Easiest migration is to leave the last octet the same for > everything. Quick regex replace and your old BGP configs have been > copied to the new address range. If you start messing with the > assigned last octets, it's just an added headache. This was a verification item. I am *not* officially involved with the transition. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by Mike Tindle

Easiest migration is to leave the last octet the same for everything. Quick regex replace and your old BGP configs have been copied to the new address range. If you start messing with the assigned last octets, it's just an added headache. Regards, Mike On Aug 22, 2012, at 3:30 PM, Mike Horwath wrote: > BTW: what am I gonna use for the route servers for IP addresses? > > 69.147.218.1 > 69.147.218.2 > > I'm guessing, cause of the idea before, that it should just end in .1 > and .2 again. > > Right? > > If so I should be ready to change over to the new /24 and then > secondary these addresses for later removal - I can update the > interfaces during the switch downtime. > > -- > Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net > The universe is an island, surrounded by whatever it is > that surrounds universes. - Berkeley Fortune > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > *----------- H U R R I C A N E - E L E C T R I C ---------->> | Mike Tindle | Senior Network Engineer | mtindle(a)he.net | ASN 6939 | http://www.he.net | 510-580-4126 *---------------------------------------------------->> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Koch, Andrew

> -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Jay Hanke > Sent: Wednesday, August 22, 2012 15:24 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo > > On Wed, Aug 22, 2012 at 3:05 PM, Larry Patterson <larry(a)atomicdata.com> > wrote: > > That being said, what is the method > > for reporting networking issues amongst peering members? > > Usually directly to the peering contact or via the MICE-DISCUSS list. Please contact direct, at least for any concerns with TDS. There are many of us that are not able to monitor the -DISCUSS list for real-time problem notification. Regards, Andy Koch TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com Desk: 608-664-4694 Cell: 608-616-0072 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

BTW: what am I gonna use for the route servers for IP addresses? 69.147.218.1 69.147.218.2 I'm guessing, cause of the idea before, that it should just end in .1 and .2 again. Right? If so I should be ready to change over to the new /24 and then secondary these addresses for later removal - I can update the interfaces during the switch downtime. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 22, 2012, at 14:51 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: >> While I agree with the general sentiment that the IP change and switch >> change will likely be smooth, the IP change can be done more >> transparently and has literally nothing to do with the L2 gear. >> To that end, I don't see any reason to not configure/assign the new IP >> block now and let folks start using it right away, even before the >> switch switch. > > But, we don't have a central router? > > If your border to the exchange right now got a prefix with the next > hop of 206.108.255.3, how'd you get there? You'd have no route to host > for 206.108.255.3. > > That is why I brought up the secondary IPs. Once everybody puts in a > secondary IP in 206.108.255.0/24, they'll know how to try to get to > 206.108.255.3 for my prefix announcement. But I can't really do the > prefix announcement with the next-hop in 206.108.255.3 until everybody > knows how to get to 206.108.255.0/24? > Your next hop for peers that are still peering on the old address should be your old address. For peers on the new address, should be your new address. The problem you describe could only apply, therefore, to the routeservers which are providing next hop data other than their own local interface. In that case, there are multiple possibilities: 1. Run two route-server instances on each address set. 2. Run one route-server instance on each address set. The route-server instances on the old address set shouldn't be seeing new address next-hops. The route-server instances on the new address set shouldn't be seeing old-address next-hops. Yes, it means everyone that is using new addresses has to maintain their old sessions with the route-servers until everyone has a new session. As Mr. Tindle said earlier... I've been through a few of these. They're not rocket science, but trying to herd all the cats into doing it as one massive change all at the same time is an almost certain path to large-scale disruption and lots of time debugging stuff that didn't have to be debugged all at once. A little careful planning and adding sessions one at a time and then judiciously removing sessions that are no longer needed along the way can accomplish this in a reasonable timeframe with a minimal amount of fuss and no mass-scale risks. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 02:40:09PM -0700, Owen DeLong wrote: > Suggestion instead... During switch maintenance... > > conf term > int bajilliongmillibit0/0 > ip address new-ip new-netmask > ip address old-ip old-netmask secondary > ipv6 address new-ip new-netmask > ipv6 address old-ip old-netmask secondary > > In this way, yes, there will be a brief time where the old-ip > disappears from the router and those BGP sessions will shut down > accordingly. However, since they will already be down for the switch > maintenance, no harm. > > Then, when everyone has completed their address migration, > removing the secondary address is easy and doesn't cause any > outage. There we go, smarty pants win. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 04:33:23PM -0500, Jay Hanke wrote: > > conf term > > int bajlliongmillibit0/0 > > ip address secondary-ip secondary-netmask > > ^z > > write mem > > > > notice I didn't remove the primary address...nor the old secondary. > > > > Should work? > > That will change the primary IP. When it gets removed the neighbor > dies because that is typically the source IP of the TCP session. You > then need to add the "old" ip as a secondary. Causing the previously > mentioned blip. > > There isn't really secondaries in Junos so, not an issue. What is the > behavior on Brocade and Extreme? I'd suggest making sure BGP is already configured in ahead of time cause that seems smart. Not like it hurts to have them both operational concurrently or anything. But then sk00ling happens. Damnit. Doug explained this: neighbor (x.x.x.x|x:x:x:x:x..) update-source INTERFACE So oh well, guess you just need to change it some night. IT IS NOT THE END OF THE WORLD IF YOUR MICE CONNECTION GOES DOWN Says Nevin. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012