[cisco-voip] OT: using subnet/wildcard mask for group within a group, issues?
gentoo at ucpenguin.com
gentoo at ucpenguin.com
Thu Feb 5 11:53:43 EST 2015
This could probably be accomplished this with a layer 2 filtering
bridge. Either with a Linux VM with multiple tagged VLANs or an ASA in
transparent mode with multiple tagged VLANs for each host (or group of
hosts you want to filter).
You would need to place the layer 2 filtering bridge between the router
L3 interface and every individual host/(group of hosts to filter) (each
host would need to reside on its on VLAN on the filtered side of the
bridge).
The filtering bridge would need ACLs that would be able to inspect the
traffic traversing it and either match on the L3 IP or the L2 MAC.
I don't think doing this would be a good idea, but you could.
Readdressing and filtering with the router is a much simpler solution
(once the pain of readdressing is over).
On 2015-02-05 10:34, Lelio Fulgenzi wrote:
> Thanks Anthony!
>
> I should have included that I would be looking at ACLs only, nothing
> like modifying router interfaces or anything like. Using DHCP reserved
> addresses, the clients in question would get the appropriate IP
> address and be allowed through.
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
>
> 519‐824‐4120 Ext 56354
> lelio at uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
>
> -------------------------
>
> FROM: "Anthony Holloway" <avholloway+cisco-voip at gmail.com>
> TO: "Lelio Fulgenzi" <lelio at uoguelph.ca>, "Cisco-voip
> (cisco-voip at puck.nether.net)" <cisco-voip at puck.nether.net>
> SENT: Thursday, February 5, 2015 11:29:24 AM
> SUBJECT: Re: [cisco-voip] OT: using subnet/wildcard mask for group
> within a group, issues?
>
> I'm no Route/Switch engineer, so I'm likely wrong here, but I'll give
> my two cents anyway.
>
> You didn't specifically state what you are doing though. E.g., ACLs,
> Interfaces, Routes, etc.
>
> Let's pretend for a moment you wanted to carve out a new network in
> your environment for this range.
>
> I don't think you'll be allowed to configure this as different
> interfaces within a single router. It will tell you that the address
> on the interface is overlapping with another interface, or something
> like that. With that, what you could do, is redesign your subnets for
> this range. You will need to go through the exercise of changing all
> of the subnet masks for the hosts between .1 - .54. However, it's
> likely not going to be that easy, as you can see below, the new
> variable length subnet masks will chop up your existing network into
> four new networks. The fourth and last one is your desired new
> network, so really you end up with three networks for the 50 potential
> hosts which exist in that lower range.
>
> Current (host range) [count]:
> 192.168.45.0/26 [1] (.1 - .62) [62]
>
> New (host range) [count]:
> 192.168.45.0/27 [6] (.1 - .30) [30] *
> 192.168.45.32/28 [7] (.33 - .46) [14] **
> 192.168.45.48/29 [8] (.49 - .54) [6] ***
> 192.168.45.56/29 [2] (.57 - .62) [6]
>
> *Because of the new broadcast address of .31, you'd have to re-ip the
> current .31 host
>
> **Because of the new network address of .32, you'd have to re-ip the
> current .32 host. Same for the broadcast address of .47, you'd have to
> re-ip the current .47 host
>
> ***Because of the new network address of .48, you'd have to re-ip the
> current .48 host. Same for the broadcast address of .55, you'd have to
> re-ip the current .55 host
>
> To see this visually:
>
> If you did a router on a stick with sub interfaces for the four new
> subnets, then the hosts communicating between subnets cannot talk at
> layer 2 anymore, and would need to be routed. If you had them plugged
> into a layer 3 switch that was doing routing, then I wouldn't suspect
> much would change in terms of traffic patterns or network load. This
> would be further reduced if you addressed common servers contiguously.
> E.g., CUCM+CUC+CER+IM&P as .5, .6, .7, and .8.
>
> Routes to this router would not have to change, which is nice, but
> that's only if your routes were nicely summarized to begin with. I
> suspect they are. E.g,, A route of 192.168.45.0/26 [1] going to this
> router, which now has four sub interfaces, one for each new subnet,
> would still work fine, and would not need to change. If I'm not
> mistaken, some/all routing protocols would summarize these four
> networks into 192.168.45.0/26 [1] anyway, for the purpose of
> advertising to other routers. You may have to turn on route
> summarization however.
>
> Now, let's pretend you actually just wanted to create an ACL to permit
> those last 6 hosts to access some other subnet, and keep your existing
> network intact. Then, this is a whole lot less work and you simply
> need to create an ACE for your ACL which permits the wild card match.
> Let's assume that your protected voice subnet was 192.168.46.0/26 [9]
>
> permit ip 192.168.45.56 0.0.0.7 192.168.46.0 0.0.0.63
>
> Or if not using wild card masks
>
> permit ip 192.168.45.56 255.255.255.248 192.168.46.0 255.255.255.192
>
> I don't know if that helped or not, but it was fun using subnet
> calculating again. Something I haven't done in quite a few years. I
> think I did it right. ;)
>
> On Thu Feb 05 2015 at 9:11:18 AM Lelio Fulgenzi <lelio at uoguelph.ca>
> wrote:
>
>> This group is full of it. Knowledge, that is. So who better to ask
>> these questions....
>>
>> I've got a subnet, say 192.168.45.0/26 [1], of which I want to allow
>> only a small group of that subnet to access a particular host. I'm
>> able to reserve the top end, which falls into another subnet,
>> 192.168.45.56/29 [2].
>>
>> So, the first network, 192.168.45.0 has network id .0, first host
>> .1, last host .62, b/cast .63
>> And, the subgroup would be, network id .56, first host .57, last
>> host .62, b/cast .63
>>
>> I'm thinking, as long as I don't use 56 and 63, I can do this.
>>
>> The hosts I will be protecting will be voice gateways, and
>> collaboration servers, e.g. callmanager, connection, etc.
>>
>> Would there be a time where the hosts being protected would
>> interpret the incorrect broadcast address? I don't see how. But I
>> could be missing something.
>>
>> Lelio
>>
>> ---
>> Lelio Fulgenzi, B.A.
>> Senior Analyst, Network Infrastructure
>> Computing and Communications Services (CCS)
>> University of Guelph
>>
>> 519‐824‐4120 Ext 56354 [3]
>> lelio at uoguelph.ca
>> www.uoguelph.ca/ccs [4]
>> Room 037, Animal Science and Nutrition Building
>> Guelph, Ontario, N1G 2W1
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip [5]
>
>
>
> Links:
> ------
> [1] http://192.168.45.0/26
> [2] http://192.168.45.56/29
> [3] tel:519%E2%80%90824%E2%80%904120%20Ext%2056354
> [4] http://www.uoguelph.ca/ccs
> [5] https://puck.nether.net/mailman/listinfo/cisco-voip
> [6] http://192.168.45.0/27
> [7] http://192.168.45.32/28
> [8] http://192.168.45.48/29
> [9] http://192.168.46.0/26
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
More information about the cisco-voip
mailing list