Traceroute of the day: traceroute to styx.ios.com (198.4.75.44), 30 hops max, 40 byte packets 1 cambridge1-cr1.bbnplanet.net (192.52.71.11) 3 ms 7 ms 8 ms 2 cambridge2-cr2.bbnplanet.net (192.233.149.202) 3 ms 3 ms 2 ms 3 alternet.bbnplanet.net (192.233.33.8) 4 ms 3 ms 3 ms 4 Hssi4-0.Boston3.MA.Alter.Net (137.39.100.97) 4 ms 3 ms 3 ms 5 Fddi0-0.Boston6.MA.Alter.Net (137.39.99.10) 5 ms 4 ms 4 ms 6 Hssi2-0.CR1.BOS1.Alter.Net (137.39.101.166) 130 ms 196 ms 11 ms 7 103.Hssi4-0.CR2.SCL1.Alter.Net (137.39.58.133) 93 ms 93 ms 94 ms 8 137.39.19.36 (137.39.19.36) 97 ms 93 ms 93 ms 9 137.39.63.35 (137.39.63.35) 99 ms 138 ms 96 ms 10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms 11 eth-0.gw-7.hck.idt.net (169.132.34.246) 297 ms 204 ms 249 ms 12 206.20.143.34 (206.20.143.34) 273 ms 230 ms 263 ms 13 styx.ios.com (198.4.75.44) 239 ms 288 ms 321 ms -- Kelly J. Cooper Network Analyst BBN Planet Corporation phone 800-632-7638 150 Cambridge Park Drive fax 617-873-6351 Cambridge, MA 02140 http://www.bbnplanet.com
Traceroute of the day:
traceroute to styx.ios.com (198.4.75.44), 30 hops max, 40 byte packets 1 cambridge1-cr1.bbnplanet.net (192.52.71.11) 3 ms 7 ms 8 ms 2 cambridge2-cr2.bbnplanet.net (192.233.149.202) 3 ms 3 ms 2 ms 3 alternet.bbnplanet.net (192.233.33.8) 4 ms 3 ms 3 ms 4 Hssi4-0.Boston3.MA.Alter.Net (137.39.100.97) 4 ms 3 ms 3 ms 5 Fddi0-0.Boston6.MA.Alter.Net (137.39.99.10) 5 ms 4 ms 4 ms 6 Hssi2-0.CR1.BOS1.Alter.Net (137.39.101.166) 130 ms 196 ms 11 ms 7 103.Hssi4-0.CR2.SCL1.Alter.Net (137.39.58.133) 93 ms 93 ms 94 ms 8 137.39.19.36 (137.39.19.36) 97 ms 93 ms 93 ms 9 137.39.63.35 (137.39.63.35) 99 ms 138 ms 96 ms 10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms
Looks like someone wanted to assign a serial network and didn't have time to look at their internal network assignment maps... I advise 'ip unn' for times like that :)
11 eth-0.gw-7.hck.idt.net (169.132.34.246) 297 ms 204 ms 249 ms 12 206.20.143.34 (206.20.143.34) 273 ms 230 ms 263 ms 13 styx.ios.com (198.4.75.44) 239 ms 288 ms 321 ms
Kelly J. Cooper Network Analyst
Avi
On Tue, 30 Jul 1996, Avi Freedman wrote:
10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms
Looks like someone wanted to assign a serial network and didn't have time to look at their internal network assignment maps... I advise 'ip unn' for times like that :)
I think that it would be "a good thing" for companies to start using the ips in RFC 1918 for internal ips on Serial Interfaces. This way, you are able to still reach Serial interfaces via ips where ip unn you can't. But, to do so, you would have to have filters on. If not it could cause problems.
10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms
Looks like someone wanted to assign a serial network and didn't have time to look at their internal network assignment maps... I advise 'ip unn' for times like that :)
Ack! ip unn wrecks havoc with net managers, causing all kinds of grief ;)
I think that it would be "a good thing" for companies to start using the ips in RFC 1918 for internal ips on Serial Interfaces. This way, you are able to still reach Serial interfaces via ips where ip unn you can't.
Seriously, I'd agree that internals should use the reserved space. With the poliferation of thousands of frame-relay PVC's (T-3 frame-relay is here, folks!), and the penchant of using point-to-point rather than multipoint interfaces, you'll end up dedicating lots of blocks just for the serial lines. Well, not lots and lots ... but we are at the point of the NIC enforcing /27 assignments right now ...
But, to do so, you would have to have filters on. If not it could cause problems.
Ahem ... just where is that condom I left lying around ... ;) rob
On Wed, 31 Jul 1996, Christian Nielsen wrote:
On Tue, 30 Jul 1996, Avi Freedman wrote:
10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms
Looks like someone wanted to assign a serial network and didn't have time to look at their internal network assignment maps... I advise 'ip unn' for times like that :)
I think that it would be "a good thing" for companies to start using the ips in RFC 1918 for internal ips on Serial Interfaces. This way, you are able to still reach Serial interfaces via ips where ip unn you can't.
Yes, this is the primary reason why we don't use unn interfaces.
But, to do so, you would have to have filters on. If not it could cause problems.
Indeed .. Even tho we filter these from being announced, we still get occassional letters from people who assume we are. - Golan
The biggest problem with using non-routable ip addresses on numbered interfaces whether point to point or frame or atm or whatever, is that you lose outside connectivity from those interfaces. We tried this, but the essential traceroutes from our core routes are too important when debugging BGP problems to the outside. Robert Bowman Exodus Communications Inc.
On Wed, 31 Jul 1996, Christian Nielsen wrote:
On Tue, 30 Jul 1996, Avi Freedman wrote:
10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms
Looks like someone wanted to assign a serial network and didn't have time to look at their internal network assignment maps... I advise 'ip unn' for times like that :)
I think that it would be "a good thing" for companies to start using the ips in RFC 1918 for internal ips on Serial Interfaces. This way, you are able to still reach Serial interfaces via ips where ip unn you can't.
Yes, this is the primary reason why we don't use unn interfaces.
But, to do so, you would have to have filters on. If not it could cause problems.
Indeed .. Even tho we filter these from being announced, we still get occassional letters from people who assume we are.
- Golan
The biggest problem with using non-routable ip addresses on numbered interfaces whether point to point or frame or atm or whatever, is that you lose outside connectivity from those interfaces. We tried this, but the essential traceroutes from our core routes are too important when debugging BGP problems to the outside.
Robert Bowman Exodus Communications Inc.
Exactly. Especially when you have downstream customers who only announce routes via BGP to you and/or other providers, it can be important for them to be able to trace out with a source address that has global connectivity. We usually use unnumbered interfaces, though, for singly-connected customers (unless their routers can't support unnumbered interfaces). The only major gotcha with that is that if they're using a Real Router (that deleted routes associated with interfaces that aren't available), you can't get to their router if their ethernet is down... Avi
On Fri, 2 Aug 1996, Avi Freedman wrote: ==>We usually use unnumbered interfaces, though, for singly-connected customers ==>(unless their routers can't support unnumbered interfaces). The only ==>major gotcha with that is that if they're using a Real Router (that deleted ==>routes associated with interfaces that aren't available), you can't ==>get to their router if their ethernet is down... Actually, with release 11.0(x) on 1000-series (can't confirm on other routers), unnumbered will still work with downed ethernet. We use ip unnumbered on all remote ISDN and frame routers for cisco's employees. Even if the remote Ethernet interface is up/down or admin-down/down, we can still reach the router over the BRI interface or serial interface. I know that older IOS releases wouldn't let you, though.
Avi, Could you use loopback interfaces to do what you want? -alan ps i'm not really a fan of ip unn, I think /30 serial networks should be considered responsible allocation by most all parties. pps i'm really a big fan of loopback interfaces for the purposes of monitoring a router as a node, as opposed to the plurality's idea of an interface having a cpu ......... Avi Freedman is rumored to have said: ] ] > The biggest problem with using non-routable ip addresses on numbered interfaces ] > whether point to point or frame or atm or whatever, is that you lose outside ] > connectivity from those interfaces. We tried this, but the essential ] > traceroutes from our core routes are too important when debugging BGP ] > problems to the outside. ] > ] > Robert Bowman ] > Exodus Communications Inc. ] ] Exactly. Especially when you have downstream customers who only announce ] routes via BGP to you and/or other providers, it can be important for them ] to be able to trace out with a source address that has global connectivity. ] ] We usually use unnumbered interfaces, though, for singly-connected customers ] (unless their routers can't support unnumbered interfaces). The only ] major gotcha with that is that if they're using a Real Router (that deleted ] routes associated with interfaces that aren't available), you can't ] get to their router if their ethernet is down... ] ] Avi ] ] ]
participants (8)
-
Alan Hannan -
Avi Freedman -
Christian Nielsen -
Craig A. Huegen -
Golan Ben-Oni -
Kelly J. Cooper -
rmg＠ranma.com -
Robert Bowman