refresher - what's happening
Hi, At 0700 EDT on Tuesday, April 25, all peering sessions on ENSSes: 128 129 130 131 133 134 135 137 139 140 141 142 143 145 will be commented out of the routing configuration files. If there is a catastrophic failure tomorrow morning, Merit will advise the ANS NOC to roll back to the previous configuration (the one installed on Tuesday morning). If it is determined that problems are isolated to individual autonomous systems, Merit will enable the sessions with those individual autonomous sytems. If there are individual routes from many sources which are unreachable, Merit will designate one emergency configuration time period at which all of the independent additions wil be made. If you are experiencing problems tomorrow after 0700 EDT, please call 1-800-456-6300 or 1-313-677-7333. The NOC operators will page a Merit engineer to help you. If you still have email access, you may send a message to trouble@ans.net. Thanks for your help in getting prepared for this day. --Elise
If there is a catastrophic failure tomorrow morning, Merit will advise the ANS NOC to roll back to the previous configuration (the one installed on Tuesday morning). Which Tuesday?
Beware that the ENSS gated announces it's interfaces into the ANS core, even if there are no E-BGP peers (or for that matter, even if the LAN interfaces are down). This means that the planed test will not really idle the ENSS if: - There are any services or *clients* on the DMZ itself (mrouted?, DNS?, NTP?, etc) - Anybody is remotely monitoring your peers with either snmp or ping. My observations are based on the FDDI interface of ENSS132, which was previously attached to a natural class C network. Physically unplugging the FDDI did not stop the ENSS from announcing it.... Your mileage may vary. Good luck, --MM--
Matt, we will be increasing the preference on the DMZ interface routes in gated on all NSFNET ENSSes along with the turning off the sessions. This will make us prefer the route announced by your service provider as it will have a better preference than the local route. We could have done the same for enss132 (or simply not export the interface route out to AS 690) if we knew this was a problem for you. In any case, I don't think it will be an issue tomorrow morning but if you still see problems with DMZ please let us know. Thanks, Serpil Bayraktar ANS
In message <9504250245.AA19883@mailer.psc.edu>, "Matt Mathis" writes:
If there is a catastrophic failure tomorrow morning, Merit will advise the ANS NOC to roll back to the previous configuration (the one installed on Tuesday morning). Which Tuesday?
Beware that the ENSS gated announces it's interfaces into the ANS core, even if there are no E-BGP peers (or for that matter, even if the LAN interfaces are down). This means that the planed test will not really idle the ENSS if: - There are any services or *clients* on the DMZ itself (mrouted?, DNS?, NTP?, etc) - Anybody is remotely monitoring your peers with either snmp or ping.
My observations are based on the FDDI interface of ENSS132, which was previously attached to a natural class C network. Physically unplugging the FDDI did not stop the ENSS from announcing it....
Your mileage may vary.
Good luck, --MM--
Matt, The ENSS still had a route to that DMZ, only the DMZ was now partitioned. The behavior used to be that at least one peer had to be on the DMZ but it now announces the route anyway. Rather than pull the plug, an "ifconfig down" on the ENSS or adding "restrict" to the "proto direct" line for the interface in the exports to IBGP in the gated.conf file should do the trick. Next time please just call our NOC and ask them to take it down. Thanks, Curtis
FYI.
the plug, an "ifconfig down" on the ENSS or adding "restrict" to the "proto direct" line for the interface in the exports to IBGP in the gated.conf file should do the trick. Next time please just call our
We are not exporting the local DMZs out to AS 690 from any of the NSFNET ENSSes as of 7 am EDT this morning. I think the reason we did not want to ifconfig the interfaces down was to be prepared to enable ASes that might have problems later in the day (and there could be more than one AS per ENSS). Serpil Bayraktar ANS
participants (4)
-
Curtis Villamizar -
epgļ¼ merit.edu -
Matt Mathis -
Serpil Bayraktar