RE: Simple route/gateway forwarding

James Smallacombe <[email protected]> Mon, 5 Apr 2010 16:31:20 -0400 (EDT)
Newsgroups gmane.org.operators.internet-access
Message-ID <[email protected]>
Spot on.

On Mon, 5 Apr 2010, Brian Johnson wrote:

> OK... is this a correct diagram?
>
>
>  +-----------+          +------------+
>  | 2811 RTR  |-PAT----->|  CPE-RTR A |
>  +-----------+          +------------+
>        | 192.168.7.1/21
>        |
>      /---\              +-----------+
>     | LAN |-------------| CPE-RTR B |--PAT-->
>      \---/              +-----------+
>        |           192.168.7.10/21
>        |
>        | 192.168.7.x/21
>    +--------+
>    | CLIENT |
>    +--------+
>
>
> - Brian
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:list-bounces@inet-
>> access.net] On Behalf Of James Smallacombe
>> Sent: Monday, April 05, 2010 2:00 PM
>> To: [email protected]
>> Subject: RE: Simple route/gateway forwarding
>>
>> On Mon, 5 Apr 2010, Brian Johnson wrote:
>>
>>> What you are trying to do is definitely possible. How you are
> stating
>>> this makes my head hurt. :)
>>
>> Sorry...I can see how it looks super-complex, but in reality, it's not
>> too
>> bad.
>>
>>> You have a LAN using the 192.168.7.0/24 network. This network has
> two
>>
>> Actually, it's using 192.168.0.0/21.  Nothing in there is actually
>> subnetted out, although, for example, 192.168.7.x is set aside for
>> network
>> equipment and 192.168.3.x is set aside for workstations, etc.
>>
>>> externally facing routers and one internally facing router. The
>>> internally facing router uses NAP (do you mean PAT, overloaded NAT?)
>> and
>>
>> Yes, like most NAT implementations like this, it is overloaded, not
>> 1-to-1.
>>
>>> uses the 192.168.0.0/21 network internally.
>>>
>>>        +------------+     +------------+
>>>        | Provider A |     | Provider B |
>>>        +------------+     +------------+
>>>              |                  |
>>>        +-----------+      +-----------+
>>>        | CPE-RTR A |      | CPE-RTR B |
>>>        +-----------+      +-----------+
>>>  192.168.7.1/24  \          / 192.168.7.10/24
>>>                   \        /
>>
>> In the case of provider A, there is no customer access to their CPE
>> router
>> and it is not doing NAT.  NAT is being performed by the customer's
>> 2811.
>> RFC 1918 to the internal Ether and provider A's "real" /26 on the
>> external
>> Ether.  Provider B's Netgear is on the same LAN as the 2811's internal
>> Ether and performing NAT to B's upstream network.  We DO have access
> to
>> this B's Netgear.  I gave it 192.168.7.10/21 while the 2811 bas
>> 192.168.7.1/21.
>>
>>>                 +------------+
>>>                 | LAN SWITCH |
>>>                 +------------+
>>>                       |
>>>                       | 192.168.7.2/24
>>>                  +----------+               / ip route 0.0.0.0
>> 0.0.0.0
>>> 192.168.7.1
>>
>> This is a little off.  192.168.7.1/21 is on the 2811's internal Etherm
>> while a real IP is on the external interface.  The Cisco has
>>
>> ip route 0.0.0.0 0.0.0.0 real.ip.of.A's.CPE.router
>>
>>>                  | 2811 RTR | NAT/PAT   <--<  ip route 192.168.3.240
>>> 255.255.255.255 192.168.7.10
>>>                  +----------+               \
>>
>> That looks correct, above.
>>
>>>                       | 192.168.0.1/21
>>
>> You mean the 192.168.0.0/21 network above, right?
>>
>>> If this diagram is correct, and the CPE routers are configured
>>> correctly, then packets bound for 192.168.3.240 WILL be forwarded to
>>> 192.168.7.10. What that router does with it is another question all
>>> together.
>>>
>>> Do you have access to the CPE routers? Are you using a routing
>> protocol
>>> or just static routes? You are dealing with all private IP addresses
>> in
>>> your example. Are they really all private IP addresses or are there
>> some
>>> public addresses in here?
>>
>> Just static routes.  Want to avoid RIP and the Netgear doesn't do
> OSPF.
>>
>>> - Brian
>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:list-bounces@inet-
>>>> access.net] On Behalf Of James Smallacombe
>>>> Sent: Monday, April 05, 2010 9:33 AM
>>>> To: Inet-Access Mailing List
>>>> Subject: Simple route/gateway forwarding
>>>>
>>>>
>>>> This is really basic, but since I've never tried it before (and
> it's
>>>> not
>>>> working), I want to see if it's possible, one way or another:
>>>>
>>>> customer has a network hooked up to provider A using provider's CPE
>>>> router.  They also have a 2811 doing NAT, which is the default
>> gateway
>>>> for
>>>> the NAT'd network 192.168.0.0/21.  The 2811 then has a default
> route
>>> to
>>>> the CPE router and a typical "internal" Ethernet on 192.168.7.1 and
>> an
>>>> "external" Ethernet on Provider A's static IPs.
>>>>
>>>> To this, they add a second connection, a business broadband
>> connection
>>>> using a typical broadband router (NetGear, I believe) to provider
> B.
>>>> They know their provider A static IPs, won't route through provider
>>> B's
>>>> network, but certainly the NATed 192.168. network will.  I stick
> the
>>>> Netgear on the same Ether as the 2811's internal interface and give
>> it
>>>> 192.168.7.10.  All workstations use a default gateway of
>> 192.168.7.1.
>>>> The
>>>> idea is to be able to switch them over to 192.168.7.10 without
>> having
>>>> to
>>>> change their settings, by just re-routing some networks on the
> Cisco
>>> to
>>>> provider B.  I tried this as a test:
>>>>
>>>> ip route 192.168.3.240 255.255.255.255 192.168.7.10
>>>>
>>>> Similar to a ppp /32 route.  However, all traffic from
> 192.168.3.240
>>>> still
>>>> goes out the default route to provider A via the default route.  Is
>>>> there
>>>> a way to make this work without subnetting 192.168.3.0 and putting
>>>> aliases
>>>> of it on one or both routers?
>>>>
>>>> James Smallacombe		      PlantageNet, Inc. CEO and Janitor
>>>> [email protected]
>>> http://3.am
>>>>
>>>
>>
> =======================================================================
>>>> ==
>>>> --
>>>> Eat sushi frequently. - Avi
>>>> [email protected] is the human contact address.
>>>> [email protected] is the list posting address.
>>>> See below URL for subscribe/unsubscribe and list options:
>>>> http://inet-access.net/mailman/listinfo/list
>>>
>>> CONFIDENTIALITY NOTICE: This email message, including any
>> attachments, is for the sole use of the
>>> intended recipient(s) and may contain confidential and privileged
>> information. Any unauthorized review,
>>> copying, use, disclosure, or distribution is prohibited. If you are
>> not the intended recipient, please
>>> contact the sender by reply e-mail and destroy all copies of the
>> original message. Thank you.
>>> --
>>> Eat sushi frequently. - Avi
>>> [email protected] is the human contact address.
>>> [email protected] is the list posting address.
>>> See below URL for subscribe/unsubscribe and list options:
>>> http://inet-access.net/mailman/listinfo/list
>>>
>>
>> James Smallacombe		      PlantageNet, Inc. CEO and Janitor
>> [email protected]
> http://3.am
>>
> =======================================================================
>> ==
>> --
>> Eat sushi frequently. - Avi
>> [email protected] is the human contact address.
>> [email protected] is the list posting address.
>> See below URL for subscribe/unsubscribe and list options:
>> http://inet-access.net/mailman/listinfo/list
> -- 
> Eat sushi frequently. - Avi
> [email protected] is the human contact address.
> [email protected] is the list posting address.
> See below URL for subscribe/unsubscribe and list options:
> http://inet-access.net/mailman/listinfo/list
>

James Smallacombe		      PlantageNet, Inc. CEO and Janitor
[email protected]							    http://3.am
=========================================================================
-- 
Eat sushi frequently. - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list