jussi

Warte, ich putze kurz die Glaskugel...

 

Ernsthaft, das ist keine ios Meldung sondern eine Fehlermeldung von Plink.

Zeig uns doch mal dein Script. Höchstwahrscheinlich ist die Syntax falsch. Vielleicht kommen wir gemeinsam dahinter.

lefg,

 

deine beiträge lesen sich regelmäß wie die beschwerden eines chirurgenpraktikanten darüber, dass die venen im menschlichen körper gar nicht wirklich blau sind wie im lehrbuch.

 

natürlich hat die vlan konfig _alles_ zu tun mit der frage ob und wie clients (hier z.B. schwitche) den dhcp server erreichen, wenn der nicht in der gleichen broadcast domain ist. du siehst - auch layer3 problemen können fehlerhafte layer2 konfigurationen zugrunde liegen.

 

die frage nach der sinnhaftigkeit ist auch wenig hilfreich, vielleicht will der fragesteller einfach nur was lernen und wenn du nicht aufpasst, schnappst du auch noch was auf.

begrifflich geht da wirklich einiges durcheinander. wie auch immer, wenn du ips in (aus) vlans per dhcp zuweisen willst, deren clients den dhcp nicht per broadcast erreichen können, dann brauchst du einen sogenannten dhcp helper im jeweiligen layer 3 interface. der macht aus dem broadcast ein unicast an eine (eben auch z.b. geroutete) adresse in einem anderen subnetzt (in einem anderen vlan).

 

ob du nun das L3 interface an den ersten Switch bauen willst oder die sophos habe ich deinen ausführungen nicht entnehmen können. beides ist möglich und sollte primär von der bandbreite abhängen.

 

dhcp helper heißt bei der sophos dhcp relay.

sei dir aber darüber im klaren, dass du an der sophos eine solche relay adresse nur global, also einmal für alle subnetze angeben kannst. an einem cisco l3 switch kannst du so viele verschiedene helper angeben, wie du l3 i terfaces in vlans hast.

 

cheers, jussi!

habs gefunden. ziehe die Frage zurück

hallo, 

 

ja danke das habe ich gelesen.

 

ich habe hier aber schon öfter ganz gute tipps bekommen. Ich bin sicher ich war nahe dran an der lösung. 

es ist jetzt etwas der druck aus der sache genommen, da man sich entschlossen hat "to throw money at the problem"...

es wird jetzt hardware migriert.

 

kann es nicht sein, dass mit der naheliegensten lösung, ( welche allerdings 100% _nicht_ lief)

 

 

native vlan 22 -------------------------------------- native vlan 22

 

es schlicht deshalb nicht ging, weil dann spanning tree usw nicht mehr durch gingen (was default mässig in 1 läuft und nicht von mir angepasst wurde)?

und wenn ich nun mit der angestrebten konfig 1 -----22 ein mismatch habe, geht denn dann(!) spanning tree überhaupt noch durch?

 

Fragen über Fragen

ich versuche meine frage mal zu präzisieren.

 

bei cisco kann ich untagged vlans auf zwei arten realisieren:

 

- access vlan

- native trunk vlan 

 

da ich bisher nur ein vlan im L2 switch hatte, war die konfig so problemlos möglich

 

L2 sw -------------------------------------------------------------------------L3 sw

 

access vlan 1                                                                        access vlan 22

 

     

nun trunke ich im L2 ein weiteres vlan (11)  dazu, dieses muss aus mehreren gründen tagged sein: 

 

 

ich habe schon ein untagged vlan (1)

ich muss es von untaged unterscheiden 

ich muss 11 bis zum gateway hinter dem L3 durch bekommen

 

ich habe also folegnde konfig ausrollen wollen:

 

L2 sw ----------------------------------------------------------------------L3 sw

 

switchport mode trunk                                                     switchport mode trunk

switchport trunk native vlan 1                                          swithcport trunk native vlan 22

switchport trunk allowed 1, 11                                         switchport trunk allowed vlan 1,11,22

 

 

diese konfig wirft natürlich cdp missmatch warnungen für das native vlan, aber laufen sollte sie doch schon, oder?

im paket tracer lief sie im echten leben _scheinbar_ nicht. scheinbar wie oben geschrieben deshalb, weil die tests

unvollständig waren. 

Hallo,

 

 

meine konkrete Frage ist folgende: Beim _untaggten_ Weiterleiten von Ethernet Frames kann ich das native VLan an einem Port bestimmen, aber kann ich das native Vlan

irgendwie beim Übergang vom einen zum anderen Switch nochmal ändern? Bzw ist das Native Vlan-Missmatch der Grund warum ich keinen Traffic übertragen kann?

Leider muss ich zugeben, dass die Frage ob ich Connectivty hatte oder nicht hatte nicht eindeutig geklärt ist, da das Monitoring "falsch" war und es leider nicht mal eben 

hin und her konfiguriert werden kann. Genau deshalb würde ich gerne im Vorfeld wissen wie es richtig geht. 

 

 

Und mit "es" meine ich folgendes:

 

Gegeben ist ein L3 Switch und dahinter diverse Abteilungs- und oder Distri-Switche. 

Die Unterverteilungen sind  "örtliche Zusammenfassung" des Campus (Gebäude, oder Werke). 

Unterverteilungen für gleiche Gebäude(teile) sind also sternförmig von L3 abgehend. 

Am L3 Switch existieren L3 Interfaces für die einzelnen  Vlans. Die Teilnehmer an den Access Switchen wissen nichts von Vlans

haben als Routing-Gegenstelle jeweils das L3 IF ihres vlans im L3 switch.

 

 

[L3 Switch]

 

 

vlan X

ip address 1.2.3.1 n.n.n.z 

 

vlan y

ip address 6.7.8.1 n.n.n.z

 

vlan z

ip adress 11.12.13.1 n.n.n.z

 

 

[...]

interface gi 2/4

switchport mode access 

access vlan x

switchport non-negotiate 

 

[...]

interface gi 3/6

switchport mode access 

access vlan x

switchport non-negotiate 

 

[...]

interface gi 1/7

switchport mode access 

access vlan y

switchport non-negotiate 

 

[...]

interface gi 1/9

switchport mode access 

access vlan z

switchport non-negotiate 

 

 

---------------------

---------------------

 

An den Switchen der betreffenden Ports sieht das dann so aus:

 

[switch vlan x]

 

vlan 1    [nur management]

ip address 1.2.3.10 n.n.n.z

 

 

interface gi 1/0/1

description irgendein Teilnehmer

spanning-tree portfast

 

 

[...]

interface gi 2/0/52

description uplink interface zum L3 

 

---------

 

Soweit so schlecht. Jetzt soll ein weiteres VLAN an Access Ports diverser Teilnehmer auf dem L2 switch  möglich sein. Das sind EXSe deren Gäste in verschiedene VLANs einkippen sollen. 

 

Dazu habe ich die Uplinks und die betreffenden access ports, bzw deren Portchannel jeweils auf Trunk umgestellt. und die nötigen Vlans erlaubt. 

 

switchport mode trunk

switchport trunk native vlan ?

swithcport trunk allowed vlan x, u, v

 

Jetzt kommt es aber zu den entscheidenden Fragen:

Welches Native Vlan muss auf die Uplinks am L3, am Uplink L2 und an portchanneln/access ports auf dem.

 

Damit nicht alle Teilnehmer Tn (access vlan 1) auf dem L2 switch von den umkonfigurierten trunkports auf L2 abgeschnitten sind, habe ich auf diesen ports "trunk native vlan 1" gemacht

auf dem uplink am l2 habe ich ebenfalls "native vlan 1" eingestellt. Auf dem core habe ich um dem missmachts zu entgehen native vlan 1 eingestellt, das bedeutet aber dann, dass die Teilnehmer Tn

nicht mehr ihrere Routing Gegenstelle erreichen können. Wie geht es richtig?

 

Vielen Dank in Voraus

Hallo, 

 

die wahrscheinlichste Ursache ist, dass weder switch0 noch switch1 eine default route (oder ersatzweise eine statische route zum gegenüberliegenden netz) haben, die zum eigenen router weist. das bedeutet in der praxis, dass deine pakete von pc0 durchaus an switch1 ankommen, aber dort nicht zurück gesendet werden können und das gleiche eben umgekehrt. 

 

 

Auf einem catalyst2950  lautet das commando zum setzen einer default route; im globalen config modus:

 

ip default-gateway <ip.des.rou.ters>    

 

Spitze Klammer durch die Router IP im eigenen Netz ersetzen. 

 

reichlich Grüsse,

 

Jussi

L3 ist ein Cisco  Catalyst  WS-C6509 mit redundanter supervisor engine  WS-SUP720-3B mit diversen gbit ind 10gbit modulen. der L3 im zweiten RZ soll die gleiche maschine werden.

 

 

Danke für deine Stichworte. ich fuchse mich da mal rein und wenn es läuft präsentiere ich hier mal die konzeption.

 

Edit: aber das erste rumgoogeln sagt mir, ich habe ein vss szenario. danke nochmal.

Hallo,

 

es gibt einen Catalyst L3 Switch mit n Vlans. In jedem Vlan befinden sich ein odere mehrere Abteilungsswitche (L2).

Es soll nun ein zweites RZ etabliert werden. Jeder Abteilungsswitch soll dann zusätzlch am neuen L3 Switch im RZ2 terminieren.

Netzwerk soll im Brandfall ohne RZ1 weiter gehen.

Die Endgeräte an den Abteilungsswitchen haben jeweils die L3 Adresse des Vlans im bisherigen (einzigen) L3 Switch als GW.

Es wird eine alternative Varkabelung von den Abteilungen zu RZ2 gelegt.

 

Verteilt man in so einem Fall die Vlan Ips des L3 switches mittel HSRP auf beide L3 Switche?

Gibt es alternative Lösungsvorschläge bei denen auch beide L3s autark arbeiten können?

 

Danke im voraus

client vlan13 fehlt das gateway nach subnetz vlan12 oder eben das default gw, falls das das gleiche ist

ja, nein und nein.

Hallo Otaku,

 

danke für deine enschätzung. ich sehe auch keinen fehler, aber die beiden nexus switche verhalten sich imho jetzt wie zwei einzelne switche, von denen jeweils einer nicht zum core verbunden ist. ist das der "best practise" zustand?

 

aufgefallen ist es weil in den angeschlossenen esxen die eths fälschlicherweise auf "status prüfung" standen. dann können dort hin migrierte gäste nur zufällig mit dem netz kommunizieren oder eben nicht kommunizieren. je nachdem über welche eth die pakete rausgeschickt werden, da der esx beide karten benutzt. erst wenn auf "signalprüfung" umgestellt wird und der esx auf layer 3 am gw testet, verhalten sich alle gäste konsistent, da dann sämtliche pakete über den jeweils aktiven weg zum core fließen.

hallo,

 

ich habe grosse fragezeichen beim virtual port channel über zwei  nx 5010 chassis hinweg zu einer core komponente (cisco 6509).

 

 

cisco 6509 ---- NX5010 

|                       |

|                       |

NX5010---------|

 

 

die nexus geräte dienen als access switche für verschiedene server racks. in meiner zielsezung sollten sich die beiden 

chassis durch den vpc in verbindung mit dem crosslink wie ein switch verhalten, machen sie aber nicht, es ist als ob vpc gar nicht wirkt und der core schlicht immer einen der beiden nx peers down hält. wofür habe ich dann vpc, das hätte spaning tree doch auch erledigt, oder?

 

konfig und debug auszüge unten

 

 

c6509,  Version 12.2(17r)SX5

---------------------------------------------------------------------------

---------------------------------------------------------------------------

---------------------------------------------------------------------------

 

[...]

 

 

 

[....]

 

-----------------------------------------

sieht dann so aus:

 

 

 

 

------

show etherchannel port-channel:

 

 

2x  nexus 5010, Version 4.2(1)N1(1)

---------------------------------------

 

nexus A: 

--------------------------------------------------------------------------

-------------------------------------------------------------------------

-------------------------------------------------------------------------

 

[...]

 

 

show port-channel summary:

 

 

 

---

show vpc brief:

 

[...]

 

 

vPC Peer-link status

 

 

nexus B:

-------------------------------------------------

-------------------------------------------------

-------------------------------------------------

 

config genau wie A ausser natürlich umgekehrte ips

 

[...]

Hallo,

 

ich möchte ein bestimmtes offizielles Netz durch den GRE Tunnel zur Niederlassung senden.

Der Tunnel terminiert in der Niederlassung  an einer statischen Adresse per VDSL, an der Hauptstelle an einer offiziellen von mir, Leitung egal, komplettes BGP routing ins internet.

 

Hardware: Niederlassung 18xx, Hauptstelle 47xx

 

*Einwahl in der  VDSL über DTAG Modem geht,

*Tunnelaufbau geht.

*Transfernetz über Tunnel gegenseitig erreichbar

* Vom Router der Hauptstelle Ips in der Niederlassung erreichbar.

* Von der Niederlasssung IPs der Gegenstelle inklusive Interfaces ausserhalb des Tunnels erreichbar, alles dahinter nicht erreichbar

*umgekehrt genauso, entferne ich mich auf seite der Hauptstelle nur einen hop weiter kann ich nicht mehr zu dem offiziellen Netz hinterm Tunnel.

 

 

Hauptstelle Konfig:

--------------------------

interface Tunnel0
 ip address <TransferIP AAAA>  
 tunnel source <offizielle IP Hauptstelle, XXXX>
 tunnel destination <statische IP DTAG,YYYY>

 

ip route <offizielles Netz der Niederlassung, NNNNN> <Transfernetz, BBBB>

ip route 0.0.0.0 0.0.0.0 <IP im Backbone, host kennt die route zu NNNN über ospf>

------------------------

 

Niederlassung Konfig:

 

interface Tunnel0
 ip address <TransferIP Niederlassung, BBBB>
 tunnel source <statischeIP DATG, YYYY>
 tunnel destination <offizielle IP Hauptstelle, XXXX>
 

 

interface FastEthernet0/0
 description Einwahl-zum-Modem
[...]

pppoe-client dial-pool-number 1
 

interface FastEthernet0/1
 description LAN
 ip address 192.168.0.229 255.255.255.0 secondary
 ip address <offizielle Ip im Netz der Niederlassung, NNNN-1>

 

interface Dialer1
 ip address negotiated
 ip mtu 1492
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 0
 dialer persistent
 dialer-group 1
 fair-queue
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname xxxxxx@t-online-com.de
 ppp chap password  xxxxxxxxx

 ppp pap sent-username xxxxxxxx@t-online-com.de password xxxxxxxx
 

 

ip route 0.0.0.0 0.0.0.0 <transfernetz IP Hauptseite, AAAA>
ip route <offizielle IP Haupstelle, XXXXX>  Dialer1
 

 

---------------------

 

muss ich den traffic durch den tunnel noch irgendwo erlauben?

 

zur klarstellung von  NNNN-1 komme ich locker bis AAAA UND bis zu allen weiteren Interfaces des Routers auf der Hauptseite aber keinen Hop weiter.

danke für die erläuterungen. tja, die globale goldrandlösung und soho preisgefüge schliessen sich thematisch irgendwie aus :-P

was kann jeder balancer? DNS Round Robin oder Route wegnehmen?

 

Welches "kleine" Cisco Gerät könnte denn zB. HTTP return code checken und bei bedarf die Route runterziehen.

danke für deine anregung, die geräte sehe ich mir mal an.

hast du damit (gute) erfahrung?

hallo ich habe eine produktunabhängige frage, da aber in diesem board viel netzwerk sachverstand zu finden ist, stelle ich es in den cisco bereich.

 

ich möchte einen http service an mehreren standorten hochverfügbar machen.

die methoden mittels dns und loadbalancer sind mir bekannt. eine weitere methode ist anycast, bei der die webserver die gleiche IP bekommen welche dann mit dynamischem routing mal da oder mal ist, bzw der weg zum server über verschiedene wege distributiert wird.

 

meine eigentlich frage an die community: gibt es irgend eine art gerät (router/applicance) die ohne selbst basteln feststellen kann, daß zB ein http service einer bestimmten maschine down ist, um eine route dann zb ins ospf zu distributieren?

 

mit hearbeat und quagga kann man sowas hinkriegen aber das muss es doch auch in profi qualität geben.

 

ps. mögliche anycast probleme bei http (tcp) sind mir klar.

doppelpost

Du blockst alles ausser typ 0, also blockst du typ 3 (unter anderem fragmentation needed) und jetzt geht alles ausser anwendung x y z... hmm ich wittere einen zusamenhang

ich möchte das hier noch mal aufwärmen.

 

Black, wird hier (write mem - Redunant IOS VPN – Applying your crypto map to 2 interfaces) das problem mit dem interested traffic nicht umgangen? Würde das auch funktionieren wenn auf beiden seiten 2 ISPs sind? Oder muss man zwingend die lösung von sessi bauen?

Ne, so funktioniert das ja bei vielen Brötchengebern nicht, aber jede Ausbildung, Zertifizierung oder Prüfung wird sich später mal bezahlt machen.

 

that's the spirit!

 

herzlichen glückwunsch

so einen schalter gibt es schon bei diversen cisco routern

 

such mal nach ip sla oder auch ip tracking.

 

1) du definiertst eine bedingung

 

 

* ip sla 1 <nummer egal, hauptsache unique>

* icmp-echo x.y.z.n

<irgendwas was nur über die "richtige" leitung erreicht werden kann, im schlimmsten fall eine hostroute dorthin legen und so das ereichen nur auf der richtigen leitung erzwingen

* timeout 500 <zeit in ms>

* frequency 3 <sooft muss es fehlschlagen>

* ip sla schedule 1 start-time now life forever <ping es und hör nicht auf damit>

* track 1 rtr 1 reachability <bedingung definieren>

 

2) bedingung an route(n) knüpfen

 

* ip route <netz> <maske> <gw-1> track 1

* ip route <netz <maske> <gw2> 10

 

die erste route ist die primäre, welche bei erfüllter bedingung immer genommen wird, die zweite route ist die fallback route, schlechtere metric nicht vergessen (10 ist nur nen beispiel) damit nach wiedererreichbarkeit der ertsen strecke wieder die "richtige" verbindung genommen wird.

 

 

ABER. das ist eklig, fehleranfällig, eklig, wird nicht von allen ios versionen unterstützt, extrem statisch, eklig und eklig.

 

Wenn du die kontrolle über alle endpunkte hast willst du nicht sowas machen sondern dynamisches routing (bei dem setup empfehle ich ospf) innerhalb des vpn etablieren.

es hat jett alles geklappt dank euerer hilfreichen tipps,

 

der entscheidende fehler war scheinbar dass die statements

 

switchport mode access

switchport nonegotiate

 

 

fehlten.

 

ipx war auch kein prob, die spasmen dazu waren auch dem falschen trunking geschuldet.

 

danke an alle