Wij, de plaatselijke computerboeren van een flink bedrijfje, hebben een tweede subnetje gekregen voor onze fabriek. we hadden al x.y.80.0/24 als range, maar dat subnet zit barstensvol en is bovendien ingericht door iemand die er een puinhoop van gemaakt heeft. Omdat deze lieve jongen nooit in z'n hele bestaan het idee heeft opgevat dat ie bij moet houden welke kabel waar naartoe gaat heb ik nul overzicht van welke kabel waarheen gaat en kan ik dus ook niet de twee subnetten in VLANs onderbrengen. Ik besef me dat de oplossing "2 subnets op 1 VLAN" ongeveer dezelfde schoonheidsprijs verdient als "strontschuit met vlag" maar op dit moment kan het even niet anders. Bij het herindelen van het netwerk kan ik zo'n lijst wel gaan maken maaar NU in elk geval even niet.
We hebben als netwerk core een Cisco L3 switch hangen, waar een aantal andere switchjes aan zitten waar alle printers, servers, clients, APs etc aanhangen. Dit zijn ook allen managed Ciscos.
Voor zover de gisteren hier geweeste Cisco programmeur het kan zien hebben alle switches alleen het default VLAN1 vlan, en zit elke poort op elke switch in dat VLAN. de complexiteit is dus gelijk aan een LAN met Sweex componenten.
De DHCP server is een DNSone appliance die DNS en DHCP doet en levert normaliter uit de 80.0/24 range adresjes. We willen dat ie daarmee ophoudt en uit de 60.0/24 range gaat uitleveren. De L3 switch geven we op zijn enige eth interface dat aan het LAN zit zowel 80.2 als 60.2 en ip routing staat er aan. De WAN router (dus naar het bedrijfsnetwerk) zit in de 80 range en heeft een route voor de 60 range naar de L3 switch, dus van buiten is de 60 range berikbaar en als je op een server hier, in de 80 range, niet de L3 switch maar de WAN router opgeeft als default GW dan komen de pakketjes ook aan (zij het met een omweggetje). Ik heb dit getest en kan vanuit de 80 en 60 ranges naar elkaar pingen, naar buiten pingen, de DHCP server pingen, internetten en de mainframes in Europa, Amerika en de Pacific bereiken en er op werken met m'n terminal clientje.
Ogenschijnlijk zijn we gaaf en eigenlijk klaar.
Als ik de DHCP server nu zeg dat er geen 80.0/24 maar 60.0/24 adressen moeten worden uitgedeeld krijgen geen van m'n clients een IP adres. Zet ik de range terug op 80, gaat alles weer goed.
Onze Europese netwerk wijsheer heb ik na anderhalf uur de blaren op m'n tong lullen overtuigd dat we helemaal geen VLANS hebben en dat dat dus geen probleem mag en kan zijn. Hij dacht vervolgens dat de L3 swtich dan misschien wel de inhoud van de DHCP pakketjes leest en beslist dat de 60 pakketjes niet het LAN op mogen. (dit lijkt me wat ongebruikelijk, zeker gezien het secondary IP 60.2 op die switch...). In elk geval gelooft hij eigenlijk dat het aan alles liggen kan behalve aan de DHCP server.
Ik ben niet geheel n00byw00by in netwerkjes aanleggen en de diverse spannende manieren om je ((W)(L))AN de soep in te helpen, en kan me echt niet voorstellen dat er ergens een beestje in de switches zit dat DHCP request (broadcast pakketjes) en de vervolgens uitgepoepte replies (unicast naar één MAC adres) ineens kwijtmaakt als de inhoud van die pakketjes wijzigt. De externe Cisco boer gelooft dit ook niet, de plaatselijke IT manager volgde het gesprek al heel snel niet meer (daarom ben ik hier) en ik vraag me af of onze interne netwerkguru wel helemaal op het juiste pad is.
Zou dit kunnen? Kan de Cisco switch zomaar die pakketjes mishandelen, of hebben we ergens een denkfout zitten die we maar blijven missen?
De config kmot expres als laatste: als je die niet zien wilt moet je dit stuk overslaan.
We hebben als netwerk core een Cisco L3 switch hangen, waar een aantal andere switchjes aan zitten waar alle printers, servers, clients, APs etc aanhangen. Dit zijn ook allen managed Ciscos.
Voor zover de gisteren hier geweeste Cisco programmeur het kan zien hebben alle switches alleen het default VLAN1 vlan, en zit elke poort op elke switch in dat VLAN. de complexiteit is dus gelijk aan een LAN met Sweex componenten.
De DHCP server is een DNSone appliance die DNS en DHCP doet en levert normaliter uit de 80.0/24 range adresjes. We willen dat ie daarmee ophoudt en uit de 60.0/24 range gaat uitleveren. De L3 switch geven we op zijn enige eth interface dat aan het LAN zit zowel 80.2 als 60.2 en ip routing staat er aan. De WAN router (dus naar het bedrijfsnetwerk) zit in de 80 range en heeft een route voor de 60 range naar de L3 switch, dus van buiten is de 60 range berikbaar en als je op een server hier, in de 80 range, niet de L3 switch maar de WAN router opgeeft als default GW dan komen de pakketjes ook aan (zij het met een omweggetje). Ik heb dit getest en kan vanuit de 80 en 60 ranges naar elkaar pingen, naar buiten pingen, de DHCP server pingen, internetten en de mainframes in Europa, Amerika en de Pacific bereiken en er op werken met m'n terminal clientje.
Ogenschijnlijk zijn we gaaf en eigenlijk klaar.
Als ik de DHCP server nu zeg dat er geen 80.0/24 maar 60.0/24 adressen moeten worden uitgedeeld krijgen geen van m'n clients een IP adres. Zet ik de range terug op 80, gaat alles weer goed.
Onze Europese netwerk wijsheer heb ik na anderhalf uur de blaren op m'n tong lullen overtuigd dat we helemaal geen VLANS hebben en dat dat dus geen probleem mag en kan zijn. Hij dacht vervolgens dat de L3 swtich dan misschien wel de inhoud van de DHCP pakketjes leest en beslist dat de 60 pakketjes niet het LAN op mogen. (dit lijkt me wat ongebruikelijk, zeker gezien het secondary IP 60.2 op die switch...). In elk geval gelooft hij eigenlijk dat het aan alles liggen kan behalve aan de DHCP server.
Ik ben niet geheel n00byw00by in netwerkjes aanleggen en de diverse spannende manieren om je ((W)(L))AN de soep in te helpen, en kan me echt niet voorstellen dat er ergens een beestje in de switches zit dat DHCP request (broadcast pakketjes) en de vervolgens uitgepoepte replies (unicast naar één MAC adres) ineens kwijtmaakt als de inhoud van die pakketjes wijzigt. De externe Cisco boer gelooft dit ook niet, de plaatselijke IT manager volgde het gesprek al heel snel niet meer (daarom ben ik hier) en ik vraag me af of onze interne netwerkguru wel helemaal op het juiste pad is.
Zou dit kunnen? Kan de Cisco switch zomaar die pakketjes mishandelen, of hebben we ergens een denkfout zitten die we maar blijven missen?
De config kmot expres als laatste: als je die niet zien wilt moet je dit stuk overslaan.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
| !
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname root_3750
!
enable password 7 120A561F0502011422
!
username root password 7 140311031E0D973B2C
no aaa new-model
switch 1 provision ws-c3750g-24ts
vtp mode transparent
ip subnet-zero
ip routing
no ip domain-lookup
!
!
!
!
!
!
no file verify auto
!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
spanning-tree vlan 1,80,84-85 priority 4096
!
vlan internal allocation policy ascending
!
vlan 80
name LAN_alt
!
vlan 90
name Reserve1
!
vlan 100
name Reserve2
!
interface Port-channel1
description root1 (Cat3508G )
switchport trunk encapsulation isl
switchport mode trunk
!
interface GigabitEthernet1/0/1
description root1 ( Cat3508G )
switchport trunk encapsulation isl
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet1/0/2
description root1 ( Cat3508G )
switchport trunk encapsulation isl
switchport mode trunk
channel-group 1 mode on
!
interface GigabitEthernet1/0/3
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet1/0/4
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
!
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
interface GigabitEthernet1/0/14
!
interface GigabitEthernet1/0/15
!
interface GigabitEthernet1/0/16
!
interface GigabitEthernet1/0/17
!
interface GigabitEthernet1/0/18
!
interface GigabitEthernet1/0/19
!
interface GigabitEthernet1/0/20
!
interface GigabitEthernet1/0/21
!
interface GigabitEthernet1/0/22
!
interface GigabitEthernet1/0/23
!
interface GigabitEthernet1/0/24
!
interface GigabitEthernet1/0/25
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet1/0/26
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet1/0/27
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet1/0/28
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan1
ip address 192.168.60.1 255.255.255.0 secondary
ip address 192.168.80.51 255.255.255.0
no ip redirects
no ip proxy-arp
!
interface Vlan80
no ip address
no ip redirects
no ip proxy-arp
!
interface Vlan90
no ip address
no ip redirects
no ip proxy-arp
!
interface Vlan100
no ip address
no ip redirects
no ip proxy-arp
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.80.1
ip http server
ip http secure-server
!
snmp-server community nlka_ro RO
snmp-server community nlka_rw RW
!
control-plane
!
banner motd
| |
:|: :|:
:|||: :|||:
.:|||||||:..:|||||||:.
C I S C O S Y S T E M S
************************************
* De naam van ons filiaaltje alhierzo *
* Bladiebladiebla GmbH & Co. *
* Cisco 3750G-24TS-S *
* root3750 *
************************************
!
line con 0
line vty 0 4
password 7 111A1A0D051B1B04
login local
line vty 5 15
password 7 051805073345431911
login local
!
end |