RE: (usr-tc) Static Routing Question
The mask on the Hiper ARC is /24. On with the dispute! I am learning a lot from the discussion so keep it up! Thanks. Mike Storjohann -----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Colin Wantling Sent: Tuesday, April 25, 2000 2:00 PM To: 'usr-tc@lists.xmission.com' Subject: RE: (usr-tc) Static Routing Question Jeff, We need Mike to confirm what the mask is on the HARC interface. This will get us past this techie discussion an onto helping the guy. His attached network may well be mask /29 /28 ... etc. This would give the error message he gets as it would then include the address of the HARC itself. Not a question of Classful/Classless, more a question of inconsistency and getting caught. Regards, Colin Also sprach Colin Wantling >Maybe yes, maybe no. No "maybe" to it...as long as the next-hop of the route isn't within the route itself, there's no problem. 10.1.1.12 isn't within 10.1.1.9/32, so there's no problem. Even if it were, its *possible* to even get that to work...but there's not a "standard" way of doing it. If you put the /32 in there, its gonna be the most specific route, so it will (should) be referenced before any shorter length match. At that point, the only questions are, "Is the next-hop reachable?" There's another route that is valid for the next-hop address (locally connected), so yes. "Is there a higher precedence route of the same mask length (ie, /32)?" Possible, but unlikely. >The route Mike is adding has a /32 mask, he doesn't say what the mask >is on the HARC ethernet interface already. Doesn't matter. As long as the next-hop for the /32 route is reachable, it should be accepted. Even if the next-hop isn't reachable, the route should probably be accepted...just not entered into the active routing table. >By giving it an address from another subnet, you can beat >the rules. s/rules/bugs/ :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Mike Storjohann
The mask on the Hiper ARC is /24. On with the dispute! I am learning a lot from the discussion so keep it up!
Yeah...I went back and found that in your original message. :) Really, its a question of most-specific route wins...this really is the whole concept of classless routing. You could have a whole nest of routes, a /24, a /28, a /29, a /30, and a /32 if you really wanted. When you have a packet to route, you find the most specific (netmask with the most ones, or highest number if you're using the /24 type notation) route that includes the IP address for the packet that you're routing and use that route/next-hop. When you have that next-hop, you look for where you send that next-hop...so if you have a route 10.1.1.9/32 with a next-hop of 10.1.1.12, you forward the packet to 10.1.1.12. Of course, to find out where 10.1.1.12 is, you...have to do a route lookup. :) Eventually, you find a next-hop that is directly connected, which gives you the interface to use, at which point you go looking in other locations for how to send the packet (for ethernet you go looking in the arp table for a MAC address, if its a point-to-point interface, you just fire the packet out the interface for the other side to pick up). So, there really is nothing magical about directly connected routes (or there *shouldn't* be at least), other than the fact that they give you an interface for the next-hop rather than another IP address (some systems represent this by putting the IP address assigned to the interface as the next-hop address, some just put the interface name in there). Basically, the same rules of picking the most-specific route still apply, even if the more specific route is a static route, and the less specific route is a directly connected. Of course, we could get really funky and start talking about tunnels, where the "interface" is really a logical construct that takes you into other processing that eventually comes back and does more route table lookups and starts the whole process over again...but that's getting off the subject. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Tue, 25 Apr 2000, Jeff Mcadams wrote:
Of course, we could get really funky and start talking about tunnels, where the "interface" is really a logical construct that takes you into other processing that eventually comes back and does more route table lookups and starts the whole process over again...but that's getting off the subject. :)
Not for long. ;-) I am trying to set up some sort of Tunneling from our Total Controls in order to utilize a web filtering system. I would prefer to use L2TP, but I could cope with IPIP or PPTP. I am curious what needs to be set up in RADIUS (Cistron) and what I need on the Linux box I intend to use as a LNS. I have seen L2TPd and the ip_tunneling modules in Linux, but I can't quite comprehend how to get it all working as a LNS. Thanx in advance. ----Steve Stephen Amadei Dandy.net CTO Atlantic City, NJ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Stephen Amadei
On Tue, 25 Apr 2000, Jeff Mcadams wrote:
Of course, we could get really funky and start talking about tunnels, where the "interface" is really a logical construct that takes you into other processing that eventually comes back and does more route table lookups and starts the whole process over again...but that's getting off the subject. :)
Not for long. ;-) I am trying to set up some sort of Tunneling from our Total Controls in order to utilize a web filtering system. I would prefer to use L2TP, but I could cope with IPIP or PPTP.
The Arc support L2TP and PPTP...I'm with you in prefering L2TP there. :) They also support VTP, but that's pretty much only used for tunnels set up at the control of MPIP.
I am curious what needs to be set up in RADIUS (Cistron)
Well...would still be a framed user, you'll probably need a Tunnel-Type attributed, perhaps a Tunnel-Medium-Type attribute (though that probably defaults to what you'd expect), perhaps a Tunnel-Client-Endpoint (though, again, the probably defaults sanely), certainly a Tunnel-Server-Endpoint. You can put a Tunnel-Password on there to provide some measure of security on who you allow to set up the tunnel (assuming you don't have other access controls on that).
and what I need on the Linux box I intend to use as a LNS. I have seen L2TPd and the ip_tunneling modules in Linux, but I can't quite comprehend how to get it all working as a LNS. Thanx in advance.
On this part, you're on your own...I've never done l2tp or tunneling on a Linux box, it should be possible without any real problem, but I just don't have any experience with it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Maybe I'm doing something stupid, but why is my TC not letting me create an IP address pool starting with .0... ERROR - Pool operation failed. Attempting to initialize the ip address pool with an illegal address (216.133.96.0). Why would the TC care? I'm taken two /23 networks, broken them up into nice pieces, and routed them to my HiPerARC. The TC is going to treat the addresses with a netmask of 255.255.255.255, right? There are going to be alot of .0's in there. ----Steve Stephen Amadei Dandy.net CTO Atlantic City, NJ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Stephen Amadei
Maybe I'm doing something stupid, but why is my TC not letting me create an IP address pool starting with .0...
ERROR - Pool operation failed. Attempting to initialize the ip address pool with an illegal address (216.133.96.0).
And this is the other place where 3Com is trying to protect us from ourselves and not accepting a perfectly valid (though uncommon) configuration. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Wed, 26 Apr 2000, Jeff Mcadams wrote:
Also sprach Stephen Amadei
Maybe I'm doing something stupid, but why is my TC not letting me create an IP address pool starting with .0...
ERROR - Pool operation failed. Attempting to initialize the ip address pool with an illegal address (216.133.96.0).
And this is the other place where 3Com is trying to protect us from ourselves and not accepting a perfectly valid (though uncommon) configuration.
O.K... after a couple days of thought... and some guessing ;-), I have been able to "fool" the TC into giving me what I want... but is it going to bite me in the ass later: I added my ip pool by using the class B designator: add ip pool test initial_pool_address 216.133.96.0/B size 64 instead of: add ip pool test initial_pool_address 216.133.96.0 size 64 And it allowed it. Is this going to have any odd side effects? Thanx in advance. ----Steve Stephen Amadei Dandy.net CTO Atlantic City, NJ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Stephen Amadei
O.K... after a couple days of thought... and some guessing ;-), I have been able to "fool" the TC into giving me what I want... but is it going to bite me in the ass later:
I added my ip pool by using the class B designator:
add ip pool test initial_pool_address 216.133.96.0/B size 64
instead of:
add ip pool test initial_pool_address 216.133.96.0 size 64
And it allowed it. Is this going to have any odd side effects? Thanx in advance.
I believe it will take a chunk out of you if you try to advertise it as an aggregate. :) I *think* (if some nice 3Com person could back me up on this, it would be nice) that the network size designator controls what size network is advertized if you set it to do an aggregate advertisement. This means that you'd advertize the /16 that contains your IP pool space as an aggregate rather than the individual pool addresses. I'm not sure that this is what this control is there for, but if that's not the reason for it to be there, I'm not sure what other reason there could be. :/ You might try using "23" instead of "B" there. Or maybe "22" or something like that. That way, if you ever do set it to be an aggregate, at least its not as big of a chunk out of your rear-end. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
The way the IP pool is going to advertise depends on if you are aggregating the pool or not. Normally for public pools with non-aggregate option the pool size and class does not matter - for all address are addressed - host based. This being the case you setting up the pool with B/A/C class IP does not really matter. However if your pool is set to aggregate, the TC will look at the size of the IP pool and automatically advertise the proper network route - so if you have 64 address it will be a part of lower c class and in this case it will have a route of /26 network. IP polls for no aggregate does not make any sense. regards V ----- Original Message ----- From: "Jeff Mcadams" <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Saturday, April 29, 2000 8:59 AM Subject: Re: (usr-tc) IP Pools.
Also sprach Stephen Amadei
O.K... after a couple days of thought... and some guessing ;-), I have been able to "fool" the TC into giving me what I want... but is it going to bite me in the ass later:
I added my ip pool by using the class B designator:
add ip pool test initial_pool_address 216.133.96.0/B size 64
instead of:
add ip pool test initial_pool_address 216.133.96.0 size 64
And it allowed it. Is this going to have any odd side effects? Thanx in advance.
I believe it will take a chunk out of you if you try to advertise it as an aggregate. :) I *think* (if some nice 3Com person could back me up on this, it would be nice) that the network size designator controls what size network is advertized if you set it to do an aggregate advertisement. This means that you'd advertize the /16 that contains your IP pool space as an aggregate rather than the individual pool addresses. I'm not sure that this is what this control is there for, but if that's not the reason for it to be there, I'm not sure what other reason there could be. :/
You might try using "23" instead of "B" there. Or maybe "22" or something like that. That way, if you ever do set it to be an aggregate, at least its not as big of a chunk out of your rear-end. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Ved
IP polls for no aggregate does not make any sense.
I'm curious why you say that. We use IP pools on all of our Arcs without aggregation (don't want to take the penalty of IP space wastage that aggregation seems to require on the Arcs). Perhaps I'm missing some configuration that will let me set up pools without the wasting more IP space? Most of my racks have either 46 or 92 active ports (we still have a *lot* of quads in service :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
I should have been a little bit clear - If you are not using aggregate option then using IP pools with /B /25 or any /netmask does not make sense - for the HiPer arc will use host based routing for the individual IP address those are assigned to dialup connections. Therefore having a /netmask set for the IP pools with no aggregation does not make sense. V ----- Original Message ----- From: "Jeff Mcadams" <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Sunday, April 30, 2000 6:45 PM Subject: Re: (usr-tc) IP Pools.
Also sprach Ved
IP polls for no aggregate does not make any sense.
I'm curious why you say that. We use IP pools on all of our Arcs without aggregation (don't want to take the penalty of IP space wastage that aggregation seems to require on the Arcs). Perhaps I'm missing some configuration that will let me set up pools without the wasting more IP space? Most of my racks have either 46 or 92 active ports (we still have a *lot* of quads in service :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Also sprach Ved
I should have been a little bit clear - If you are not using aggregate option then using IP pools with /B /25 or any /netmask does not make sense - for the HiPer arc will use host based routing for the individual IP address those are assigned to dialup connections. Therefore having a /netmask set for the IP pools with no aggregation does not make sense.
OK...that makes more sense. :) And mine are /24's I think...'cause I don't set them, and I think that's the default. Since we don't use any aggregation, its of no concern. So, then the next question...you seemed to imply in a previous message that the Arc will "intelligently" choose what to advertise out as an aggregate. I was under the impression that this was controlled by the /netmask. Again, we don't do any aggregation on the Arcs, so I don't know its behavior...can you clear this up a bit? If the Arc does it "intelligently" (without needing the control of the /netmask, then what is the /netmask value there for?) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
And mine are /24's I think...'cause I don't set them, and I think that's the default.
The defualt is dependent upon the ip addresses you specify for the pool. We never had any problems with this until we moved to a new address block 63.90.215.X and the pool defaulted the netmask to 255.255.0.0, so I now have to specify the netmask when I create the ip pool. As far as the clients were concerned, some folks didn't seem to notice any problems but others had all sorts of trouble getting to many sites on the net. Changing the netmask of the pool to a /24 fixed it. Mark Thornton San Marcos Internet, Inc. 512-393-5300 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Sun, 30 Apr 2000, Jeff Mcadams wrote:
Also sprach Ved
I should have been a little bit clear - If you are not using aggregate option then using IP pools with /B /25 or any /netmask does not make sense - for the HiPer arc will use host based routing for the individual IP address those are assigned to dialup connections. Therefore having a /netmask set for the IP pools with no aggregation does not make sense.
OK...that makes more sense. :) And mine are /24's I think...'cause I don't set them, and I think that's the default. Since we don't use any aggregation, its of no concern.
So, then the next question...you seemed to imply in a previous message that the Arc will "intelligently" choose what to advertise out as an aggregate. I was under the impression that this was controlled by the /netmask. Again, we don't do any aggregation on the Arcs, so I don't know its behavior...can you clear this up a bit? If the Arc does it "intelligently" (without needing the control of the /netmask, then what is the /netmask value there for?)
In the old versions of the HiPer arc code 4.0 etc, the netmask options was to be set by the system administrator, however that lead to many issues as the IP pools would have a mask set that would overlap the actual ethernet mask and caused problems - thus the hiper arc in the 4.1 and above code decides the netmask based on the size of the pools. If you know the exact netmask to use you can give it - and thus the /netmask option. -V
-- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
participants (5)
-
Jeff Mcadams -
Mark Thornton -
Mike Storjohann -
Stephen Amadei -
Ved