Re: Re: OT: RIP settings for private netblocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Mon, Oct 6, 2008 at 1:03 PM, James B. Byrne <byrnejb@xxxxxxxxxxxxx> wrote:
>
> On : Sat, 4 Oct 2008 14:50:37 +0200, "Mr Shunz" <mrshunz@xxxxxxxxx> wrote:
>
>> Hi,
>>
> [snip]
>
>>> Presently the setting for rip is:
>>>
>>> router rip
>>>  version 2
>>>  passive-interface [[FastEthernet]]0/0
>>>  network aaa.bbb.ccc.0
>>>  no auto-summary
>>
>> is that aaa.bbb.ccc.0 a *public* IP class?
>
> Yes. It is a routable 'c' class address.
>
>> if it is with the conf below:
>>
>>> router rip
>>>  version 2
>>>  passive-interface [[FastEthernet]]0/0
>>>  network aaa.bbb.ccc.0
>>>  network 192.168.0.0
>>>  network 10.0.0.0
>>>  no auto-summary
>>
>> you inject private addresses to the other (public?) router...
>>
>> if aaa.bbb.ccc.0 is another *private* class the configuration
>> should be ok...
>>
>> maybe i misunderstood your question ...
>>
>
> This is possibly because I an so unfamiliar with routing that I lack the
> terminology to ask it more clearly.
>
> Our internal networks date back to the spring of 1995 and at the time we
> used portions of our assigned C class netblock for all hosts.  This
> arrangement has survived to the present day.
>
> I wish to move to a private netblock for internal use but I am
> operationally constrained to do so gradually.  What I want to do is in the
> interim allow host 1 with the public IPv4 addr of aaa.bbb.ccc.171 to
> co-exist on the same lan segment as a host with an address of
> 192.168.2.151 say.  On said segement there is but one gateway to the
> Internet, located at IPv4 aaa.bbb.ccc.1.  The rest of the settings are as
> in the first example above.  If I add 192.168.0.0 to the list of networks
> handled by RIPv2 at the router (and configure the router Eth0 with a
> suitable virtual IP from the same network, say: 192.168.71.1) , will
> internal traffic originating at a host with an address of 192.168.2.71
> reach an internal host at 192.168.61.151 and can 192.168.2.71 also reach
> aaa.bbb.ccc.171?
>
> I will deal with NAT issues for these hosts at a later time.  For now I am
> concerned only with hosts that should not reach or be reached from the
> public Internet in any case and therefore do not need a public IP or NAT.
>
> I do not know if that is any clearer or not.  Basically, I do not wish to
> start physically segregating the internal lan into private and public
> segments using an internal router.  I want both address spaces to co-exit
> on the same switch until the transformation is finalized and then we will
> look at whether it makes sense to segregate.
>
> We are taking about dozens of hosts, not thousands.  But we do have legacy
> systems that require devoted multiple virtual IPS on a single interface so
> the number of IPs in use is several times the number of hosts.
>
> I hope this question makes my desires clearer and provides sufficient
> background detail for sensible commentary.

You can do this, no prob, make sure the private IPs terminate at the
firewall/proxy with NAT'ing and don't get RIP'd to the edge router
beyond.

I would probably only route 1 set of private IP addresses though,
pick 192.168.0.0/16 or 10.0.0.0/8, but not both. You can subnet 10.0.0.0
into as many subnets you want with variable subnetting. Use vlans on
the routers/switches, one vlan for the public IPs, one for the private IPs
and as hosts are migrated from public to private IPs you will remove
them from vlan A and add them to vlan B, if you use DHCP it makes
things sooo much easier as all you need to do is change the vlan
assignment.

Here I have a class B allocated from 10.X.X.X for each office site, and
separate class Cs for each network within those sites.

Turn subnet auto-summation off too.

If you want more detailed config info email me off-list.

-Ross
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux