dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
110
aryoba
MVM
join:2002-08-22

aryoba to DarkLogix

MVM

to DarkLogix

Re: [Config] OSPF double check

said by DarkLogix:

sounds like summarizing the network statements wouldn't be useful to me

It was mostly a thought of trying to make the config smaller and remove unneeded lines and condense it.

and I don't think my home net is large enough to have more areas.

If you are trying to build a home lab, then there is no such thing as "my home net is not large enough to have more areas". I believe a home lab should be designed as close as possible to the real network design out there in the field, which contains lots of IP addresses and perhaps OSPF areas. The idea is to get used to the mindset of network engineers and architects in regards of OSPF design.

My 2c
markysharkey
Premium Member
join:2012-12-20
united kingd

markysharkey

Premium Member

Agreed. Across my 5 routers I have labbed with each one as a different area and also added in some EIGRP/OSPF redistribution for good measure. Then there's the whole virtual-links fun to have. And don't forget that on some IOS versions, sho ip ospf route is a hidden command!

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix to aryoba

Premium Member

to aryoba
Well my aim is in the imagination that my home lab if it were one site of a large network.

with 10.254.254.x/24 and through 10.255.255.x/24 reserved for point to point ip links

and with the setup of 10.x.y.z where x=site code, y=vlan, z=host

if you imagine its just one of many sites then would you make each site an area and then maybe the site to site links another area?

then likely use the 172 private range for site to site (obviously that doesn't exist at this time) so then I could say the 172 range would be one area and all non-local 10 ranges can be reached via the 172 area.

so with the imagination that there are other sites how would you do what I've done?

though if I can't get a good price for my 3745 then I might see if I might put my 3745 in our DRC and actually have a remote site. (ya right I doubt that would get approved.)
aryoba
MVM
join:2002-08-22

aryoba

MVM

said by DarkLogix:

Well my aim is in the imagination that my home lab if it were one site of a large network.

with 10.254.254.x/24 and through 10.255.255.x/24 reserved for point to point ip links

and with the setup of 10.x.y.z where x=site code, y=vlan, z=host

I have worked in an environment like that where the manager liked to dedicate third and fourth octets to something such as VLAN ID or anything that came to his mind. In small environment where all RFC-1918 IP address range is sufficient, it may work well to some extent. In larger environment where you are forced to use Internet-routable (non RFC-1918) IP addresses in private networks (not publicly-accessible from the Internet) or you have to re-use the IP addresses in some VRF-based environment, such mindset will not be applicable anymore
aryoba

aryoba to DarkLogix

MVM

to DarkLogix
said by DarkLogix:

Well my aim is in the imagination that my home lab if it were one site of a large network.

if you imagine its just one of many sites then would you make each site an area and then maybe the site to site links another area?

Depending on comfort level of the network architect, you can stay with multiple-area OSPF design or prepare to embrace BGP in addition to run OSPF as IGP. For those who like to stay in OSPF where each site has its own area, I have seen site-to-site links to have additional ABR to incorporate point-to-point links to keep simple OSPF design.

I personally would go with BGP in such case since you will limit your option when you insist to keep one area for each site.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

1 edit

DarkLogix to aryoba

Premium Member

to aryoba
if you're using non RFC-1918 (IE real public IP's) then why would you make them non-internet reachable? sounds like a waste of public IP's

I'd stick with 10.x.y.z and keep public IP's on the edge, then use the 172 for site to site and 192 for special use.

then layer an IPv6 /48 over it as such
2001:470:b801:XXYY::/64

and of course reserve some space for point to point and special links
(speaking of which I think I might redo my 10.254.254.x to 10.255.255.x so it'll line up better with how I'm going to redo my ipv6) (255=FF))
aryoba
MVM
join:2002-08-22

aryoba

MVM

said by DarkLogix:

if you're using non RFC-1918 (IE real public IP's) then why would you make them non-internet reachable? sounds like a waste of public IP's

In large environment, they usually consist of multiple "independent" entities which from network perspective are seen as different company. Where each entity is seen as their own company, each entity has their use of RFC-1918 IP addresses which may overlap or contradict with other entity's policy. All of the entities however still prefer to have the same global IT support across the entire company. With that in mind, it is considered normal practices to have non-RFC-1918 IP addresses assigned to end hosts such as PC, server, and printer.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_ to DarkLogix

MVM

to DarkLogix
said by DarkLogix:

if you're using non RFC-1918 (IE real public IP's)

Private, non-publicly-routeable address space isnt just limited to RFC1918. In theory, one way or another, the following subnets are all available for private network use:

10.0.0.0/8 Private-Use (RFC1918)
100.64.0.0/10 Shared Address Space (RFC6598)
169.254.0.0/16 Link Local (RFC3927)
172.16.0.0/12 Private-Use (RFC1918)
192.0.2.0/24 Documentation (TEST-NET-1) (RFC5737)
192.168.0.0/16 Private-Use (RFC1918)
198.18.0.0/15 Benchmarking (RFC2544)
198.51.100.0/24 Documentation (TEST-NET-2) (RFC5737)
203.0.113.0/24 Documentation (TEST-NET-3) (RFC5737)

Suffice to say, they will all route. With possibly the exception of 169.254.0.0/16 you could be reasonably assured that none of these addresses will (should) ever exist in your routing table unless youve configured them somewhere.

Source: »www.iana.org/assignments ··· ry.xhtml

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

Arrg I'm starting to consider redoing my IP setup again

for some reason I'm debating the use of the zero subnet on vlan 1
I think I'd be happier with it being 10.0.vlan number.x
then swap in 10.0.0.x for the special links (IE what I have 10.255.255.x for atm) arrg why can't we have a vlan 0? (oh wait I bet if that frame header is 0 its untagged right?)

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_

MVM

Not necessarily.

The native VLAN is untagged, usually thats VLAN 1 but it can be any number within the VLAN ID range.

But why tie subnetting to VLAN numbers?

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

For good organization

Well the native would be untagged and could be any number 1-4096 (or is it 4095)
so in the frame header would 0=untaged=native or is 0=1?
DarkLogix

DarkLogix

Premium Member

Ok just went to refresh and found this

»en.wikipedia.org/wiki/IE ··· E_802.1Q

so a VID of 0 is special and shows no vlan membership and vlan 4095 is also reserved so its 4094 usable-ish (got those pesky fiddi and token ones)

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

2 edits

TomS_

MVM

Yeah, 1-4094. Those FDDI and token ring VLANs are a Cisco specific legacy thing. I wish they would die as well.

The VLAN ID is stored in 12 bits, which gives a range of 0-4095, but with 0 and 4095 off limits that leaves you with 1-4094.

An untagged frame doesnt contain a VLAN header with 0 in it, it just doesnt have a VLAN header. So a tagged frame will be 4 bytes longer than an untagged one.

After a quick read around it seems that VLAN 0 can be considered untagged as well, but strictly speaking its still tagged IMO. :-P

A tagged frame also has a different ethertype. 0x8100 indicates an ethernet frame with a VLAN header, anything else represents an ethernet frame with X payload type.

»en.wikipedia.org/wiki/EtherType

So a device receiving a frame with ethertype 0x8100 then needs to remove the VLAN header to get to the original ethertype which will identify the type of payload. Armed with the info from the VLAN header it can then keep the frame within the boundaries of where it is allowed to go.

Then theres Q-in-Q with an entirely different ethertype again, but we'll leave that for another time.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

Ya its just been awhile since I thought about the frame composition.

though when watching a review video the other week I was getting ticked when the person said tagged packet and never talked about the different transmission units for layers 2 and 3

so based on how a given switch deals with vid=0 0 and the native could end up being the same or would most gear just drop 0 tagged, sounds like an attack vector.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_

MVM

I think its best never to use the native VLAN anyway. As an untagged VLAN you cant really control where its frames go like you can with tagged VLAN IDs.

And if VLAN ID 0 is treated as an untagged frame I dont really see how its any more of an attack vector as sending in traditionally untagged frames.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

said by TomS_:

I dont really see how its any more of an attack vector

That's for some hacker to figure out.
DarkLogix

1 edit

DarkLogix

Premium Member

The only ideas I have for how it could become an exploit involve an already insecure net.

But I bet with the right hacker an exploit could be figured out (though maybe its already happened and there's some fix already.)

imagine if someone got on a trunk port but didn't know the native they could send a vlan 0 frame and find some info. though the reply would also be untagged, but it could be a vtp packet or such. (and from what I've seen if you don't set a native then you have a default native of vlan 1)

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_

MVM

But you dont need to know or even try to guess the VLAN ID to accessing the native VLAN, you just send untagged frames and they are automatically handled as part of the native VLAN.

If you plug in to a trunk port, just start Wireshark and look at the frames coming in. From there you'll probably find out what some of the VLAN IDs in use are, and with enough time what subnets are in use in those VLANs.

But as you say, that would be an already existing security problem.

Thats why I dont like using the native VLAN, and configure all of my unused switch ports as access ports in the native VLAN. That way anyone with ill intentions plugging in is only going to find someone else plugging in to an unconfigured port.

Then again, 802.1x would go a long way to preventing that kind of thing in the first place.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

if you're not tagging native -- you're doing it wrong%u2122

tag natives. unused ports in a dummy vlan. even better if your kit allows you to make the ports members of a vlan not in vlan.dat. shut everything down and give port-descriptions of "ops people -- dont change. evar!".

q.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix to TomS_

Premium Member

to TomS_
IMO anything that works in an odd way like that can be leveraged by the right creative mind.
DarkLogix

DarkLogix to TomS_

Premium Member

to TomS_
said by TomS_:

Then again, 802.1x would go a long way to preventing that kind of thing in the first place.

Well ya

on my home net I've left it with native at default and put all unused ports in a non-routed vlan as access ports, so if anyone plugs in they'll find nothing not even a vlan interface.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_ to tubbynet

MVM

to tubbynet
Tag native? I thought native was supposed to be untagged...

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

its a knob you can turn.
on trunks, native vlan can be tagged, such that there is no untagged vlan on a trunk.

q.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_

MVM

Have not seen this before, I will have to take a look. That would have been really good to know at my last job I suspect.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

tubbynet

MVM

said by TomS_:

Have not seen this before, I will have to take a look. That would have been really good to know at my last job I suspect.

the only caveat is making sure that if you turn the knob -- that the kit can support it. at times, you'll run into something that doesn't support the tagging of a native vlan (or is foolishly coded to accept that vl1 is always native and untagged).

always worth mocking in the lab before putting it into prod. unless you're like me and just cowboy it in there.

q.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

Naw man cowboy up then if you mess up you'll never forget it life lesson and all.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_ to tubbynet

MVM

to tubbynet
Im all for cowboy. You dont learn when stuff doesnt break.

tubbynet
reminds me of the danse russe
MVM
join:2008-01-16
Gilbert, AZ

1 recommendation

tubbynet

MVM

i rarely test, but when i do -- i do it in prod.

q.
tubbynet

tubbynet to TomS_

MVM

to TomS_
»www.cisco.com/en/US/docs ··· p1970379

for your records.

q.

DarkLogix
Texan and Proud
Premium Member
join:2008-10-23
Baytown, TX

DarkLogix

Premium Member

And let me guess it'll break all trunks till you've applied it to all switches right?