jussi

@daking, genauso ist es konfiguriert: bridge 99 protocol vlan-bridge interface Vlan22 description <egal> ip address x.y.z.n 255.255.0.0 ip helper-address x.y.z.52 ip helper-address x.y.z.51 bridge-group 99 usw... Es wird keine grosse datanmenge sein, wir sprechen von 1 server und ca 20 clients. und selbst das soll bis kommenden samstag (2. versuch der migration) abgestellt sein. @black, ich sag noch bescheid wie es gelaufen ist.

@daking danke für deine tips, das werde ich ausprobieren. ich habe das "trocken" konfiguriert, umstekcne kann ich erst wieder zum vereinbarten termin, mal sehen ob es die wende bringt. und das funktioniert auch wenn ich das mit mehren switchports im selben access vlan mache? also gi 1/1 und gi 1/3 und 3/7 sind dann alle switchport switchport mode access switchpoirt nonnegotiate switchport access vlan XY die bridge group config muss ich nachreichen, da ich gerade keinen zugriff auf das gerät habe. ich arbeite aber schon daran diesen zopf einfach abzuschneiden. evtl ist das also kein killerkriterium mehr für die migration dennoch wär eich erfreut was in dieser hinsicht zu lernen. @black, solange keine kabel in den optiken sind, ist natürlich alles gut, und in der "sh vlan brief" übersicht alles sichbar, sobald ich kabel einstecke werden einzelne ports aus verschiedenen vlans im 6500er deaktiviert und es fließt null traffic. es ist eine historisch gewachsene umgebung. es exitieren alte 3508er und 2950er und neuere 2960/70er. wenn nich die anfangs beschriebenen ketten auflöse und alle mit dem neuen core switch verbinde, gehen "die alten" scheinbar sofort, "die neuen" eben nicht. ich habe inzwischen verstanden, dass es ein trunking problem ist und dass der 6500er schlauer ist als der alte core 3550er und deshalb ports mit groben unfug einfach abschaltet. ports die nach dem verbinden auftauchen haben gegenüber immer alte switche die scheinbar einen default in den switchports haben haben: "Trunking VLANs Enabled: NONE" und da wo ports abgeschaltet werden hat es neuere switche mit der einstellung "Trunking VLANs Enabled: ALL" dies kann ich aber scheinbar nicht erzwingen (zumindest trocken auch nicht mit den befehlen von daking) da der 3550 aber mit dieser heterogenen umgebung null probleme hatte, muss das imho auch auf dem 6500er irgendwie gehen, Danke für eure Zeit!

black, hier mal ein beispiel eines problemports, ohne kabel drin auf dem 6500 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: down Administrative Trunking Encapsulation: negotiate Negotiation of Trunking: On Access Mode VLAN: 27 (VLAN0027) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Operational Native VLAN tagging: disabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Unknown unicast blocked: disabled Unknown multicast blocked: disabled

hi black, soweit richtig wie du es dir vorstellst ausser das bei einigen "abteilungen" eben x pL2 switche an ebensovielen ports des 6500ers hängen sollen. soweit ich weiss kann ich das nur machen wenn ich die betreffenden ports in ein vlan hänge. ich gleube ein ip interface kreieren und da dann die switchports reinhängen ist genau der richtige weg, aber ich denke ich habe know-how probleme bei der konfig von PVST und MST, denn warum sollte der 6500er sonst port abschalten sobald ich was reinstecke (port ist up connected, aber im sh vlan brief taucht er nicht mehr auf)

ich will aber vlans haben, es ist ein weitverzweigtes netz mit hunderten ips in verschiedenen nummernkreisen angeschlossen an hintereinandergekettete switche, diese ketten will ich auflösen und dann zum beispiel port x, y und z mit dem einen vlan belegen und port a,b und c mit dem anderen die clients bekommen alle als gw das bein des 6500er im jeweiligen vlan, wenn ich deinen vorschlag mache und die switchports auflöse und nur vlan ifs für die ips konfiguriere liegen doch alle teilnehmer in einer bc domain, oder nicht? oder meinst du doch sowas hier: interface gi 1/3 description <whatever> encapsulation dot1Q 25 ip address 1.2.3.4 x.y.0.0 dann muss ich doch alle übrigen ports die auch im vlan 25 liegen sollen mit anderen ips belegen, oder nicht? wahrscheinlich habe ich gerade ne denkblockade weil ich vom layer 3 switch auf so nen fetten edel router umsteigen will

hallo, danke für deine antwort. ich habe erst mal so übernommen weil ich möglichst 1zu 1 übernehmen wollte. aber ich hgebe dir recht, dass das mit dem 6500er besser geht. schlägst du vor dann mit dot1q zu taggen? die nachgelagerten abteilungsswitche können aber im default vlan bleiben oder? muss dann jeder der ports auf dem 6500er im gleichen vlan eine eigene ip bekommen? noch ne spezialfrage auf dem abgelösten 3550er gabs eine brigde-group (für alte ipx ********) kann ich das irgendwie im 6500er abbilden?

keiner ne idee?

hallo, bei der migration vom C3550er (kleiner layer3) switch auf 6500 (modularer layer3) habe ich einige Probleme. netzwerk sieht so aus: 3550 ist der core switch/router an den 12 Gbit ifs liegen jeweils auf getrennte ip nummernkreise. der 3550 routet dann zwischen den netzen. entscheidende konfig exemplarisch --------------------------------------------------- [...] interface GigabitEthernet0/1 description trallala switchport access vlan X no ip address no cdp enable [...] interface Vlan X description <egal X> ip address x.y.a.b 255.255.0.0 ip helper-address <egal> ip helper-address <egal> ----------------------------------- Die Ports auf dem 3550 waren knapp, daher sind dann ein Abteilungsswitch hinter den nächtsen gebastelt. Das funktioniert ist aber natürlich extrem ausfallkritisch, wenn der erste in der Kette ausfällt sind alle dahinter down. Aus diesem Grund wurde ein modularer 6500 beschafft, An diesen sollen nun wieder zum echten Stern die vorher nachgelagerten Switche in eigene Anschlüsse angeschlossen werden. Wenn ich die Konfig nun so übertrage: ----------------------------- [...] gi 1/1 switchport switchport mode access vlan 20 no ip adress [...] gi 3/7 switchport switchport mode access vlan 20 no ip adress [...] interface Vlan 20 description <egal 20> ip address x.y.a.b 255.255.0.0 -------------------------------------------- das funktioniert nicht, im cdp kann ich die nachbarn sehen aber im 'sh vlan brief' werden regelmässig angeschlossene ports der betreffenden vlans nicht angezeigt. im oben gewählten beispiel wäre also im vlan 20 nur einer der beiden ports und auf ip kann ich auch nur einen strang erreichen. was mache ich falsch? ausserdem weigert sich der 6500er diese gbics zu fressen welche wieder auf kupfer umsetzen (habe zwei uralte ipx router an dem 3530, der mit 2x kupfer kommt). kann ich da konfigseitig irgendwas dran machen? danke im voraus

schön, bitte noch die warung von otaku beherzigen und prüfen ob der nachbar das nicht wieder wegfiltert.

du musst dich mal grundsätzlich mit dynamischem routing auseinandersetzen. natürlich musst du das nicht auf allen configurieren, dann könntest du doch auch auf allen routern die route statisch eintragen, weil der sinn von dynamischem routing ist u.a. auch der geringere administrative aufwand. in deinem router steht zZ dass er nur die connected routen (sprich alle routen, die er an interface gebunden hat) verteilt. das ist dein problem, erweiter das entsprechend, aber bitte verstehe zuerst was du tust.

moin, wozu die sec ip, du kannst doch selber entscheiden welche routen im bgp redistributiert werden. selbstverständlich mus dazu KEINE if route gesetzt sein. schau dir mal redistribute static und redistribute static route-map an

imho schon

hallo Lausebub, ich glaube du machst das richtige aus den falschen gründen, daher noch mal zur aufklärung: " Die Clients aus dem Daten VLAN 2 haben das Vlan-Interface 10.10.2.5 [...] als Default-Gateway.[...] nicht mehr zusätzlich auf dem Switch, weil dieser sein Gateway bereits hat, richtig? " das dfgw des layer 2 switches nutzt bei der wegfindung der pakete im daten netz nichts. die pakete werden ge_SWITCHED nicht ge_ROUTET. Gw für die clients ist natürlich die interface ip des vlan interfaces auf den l3 (also wie du schreibst 10.10.2.5. der l2 switch braucht natürlich ein anderes gw, du willst ihn ja im mngmt netz erreichen (pakete sollen zu dir, vermutlich im daten lan sitzend zurückkommen) also die l3 if ip des mngmt vlan (10.10.1.1) ansonsten die anmerkungen meiner beiden vorredner verwursten und dann sollte es laufen.

also nur noch mal fürs protokoll mpls hat grundsätzlich nix mit sicherheitsorientiertem VPN (wie z.B. ipsec vpn) zu tun. das wird zwar regelmässig vom vertrieb eines magentafarbenen carriers behauptet, bleibt aber trotzdem falsch. Die übertragenen daten werden nicht verschlüsselt oder der content authentifiziert. für jede art von klassifizierten daten ist mpls NICHT ausreichend. natürlich kann man innerhalb eines MPLS netzes auch eine L2 VPN oder ein L3 VPN abbilden, aber dafür ist MPLS kein bisschen voraussetzung. BTW: der overhead bei ipsec ist natürlich abhängig von der menge, der fragmentiertheit der daten sowie der eigesetzten verschlüsselungsmethode und des Protokolls innerhalb des payloads. 10%-15% overhead würde ich aber schon als schlecht konfigurierten worst case ansehen. citrix, cifs und mapi sind sicherlich deutlich besser, d.h. weniger overhead anfällig innerhalb des vpns. eine 10mbit vpn strecke, die diese 10bits (ausserhalb des derzeitigen vpns) auch macht. durch eine 2 mbit/s MPLs strecke zu ersetzen ist eine marketingtechnische meisterleistung des carriers: technisch unmöglich und zudem noch entweder sinnlos oder gefährlich, je nachdem ob im mpls nochmal sicherheitsorientiertes vpn gemacht wird oder nicht.

Na Glückwunsch!

wordo, das geht. habe ich schon mehrfach gemacht.

ich weiss du hast nach aktueller hardware gefragt, aber ich habe sowas schon mal mit nem 1741-tralala router gelöst. eth und bri onboard, 2x modul slot. darein habe ich dann eth if zusätzlich gesteckt. inklusive vpn modul und entsprechendem IOS von "befreundeten" greyimporteuren für unter 600 euro. vor den eths der wan anbindung brauchst du natürlich dann zwei baumerkt modems für (2x 20 euro). von den adsl wics kann ich (preislich) nur abraten. es sei den wenn der kunde die modem im serverschrank nicht wünscht, dann muss er aber eben auch dem premium preis bezahlen.

hallo, wenn du 192.168.1.1/website1 zur default website machst die auf 80 "hört" wenn server 192.168.1.1 erreicht wird reicht natürlich einfaches DNAT welches sowohl mit der pix aus lauch der asa geht. wichtig ist eben dass du den einen port (80) nur einmal (pro offizieller ip) weiterleiten kannst und keine host header hast, weil wie black sagte, die pix nichts von der application weiss. (layer 4 und höher)

otaku, danke für die liste, aber ich habe überlegt ein produkt eines anderen herstellers zu nehmen. ist natürlich abhängig vom budget. black, du musst halt mehr als den ersten satz lesen :-p aber ist doch np. hauptsache ich weiss jetzt warum es nicht funzt.

oder ich verkaufe dem jetzt ne richtige firewall/vpn konzentrator *wegduck* danke für deine hilfe

hintergrund ist folgender: vorher gab es eine internetleitung. asymmetrisch (kleiner uplaod) für mail/surfen + remote access vpn. Dann kam ein site to site tunnel dazu, welcher eine bestimmte bandbreite in beiden richtungen erforderte. man schaffte eine 2. leitung an, symmetrisch. den site2site tunnel habe ich darauf gelegt und das macht nun soviel spass, dass das ra vpn auch darauf gelegt werden soll, was aber nicht geht da die df route auf outside liegt (weil natürlich surfen , mailen etc weiter darüber laufen soll). ein klassischer fall für pbr, welches die asa scheinbar nicht kann. blackbox, die maps sind schon ok, wenn ich ne hostroute auf die ip lege von welchem ich das versucht habe, geht es natürlich, allerdings halte ich es nicht für praktikabel, dass jeder der r-a machten will vorher anruft um dem admin die derzeitige ip mitzuteilen. :P

noch mal ich! ich glaube ich habe (mal wieder) ein schlichtes routing problem. die default route liegt doch am interface outside, dann wird doch NIEMALS remote-access am interface vpn funktionieren, ich weiss ja nicht von wo der ra zugriff kommt, kann ihn also auch nicht statisch routen. Die ASA unterstützt kein PBR lese ich gerade.... also dann gehen mir die ideen aus.

otaku, ich muss hier noch mal nen alten thread hervorholen. habe nun endlich mal zeit gehabt das zu tun was du mir geraten hast. beide vpns (site2site und remote access) in die gleich cryptomap lege, antwortet die asa nicht auf ra anfragen zum vergleich: GEHT: ----------- crypto dynamic-map remotevpn_dyn_map 20 set transform-set ESP-3DES-SHA crypto dynamic-map remotevpn_dyn_map 20 set security-association lifetime seconds 288000 crypto map OUTSIDE_MAP 20 match address <accessliste> crypto map OUTSIDE_MAP 20 set pfs crypto map OUTSIDE_MAP 20 set peer <peername> crypto map OUTSIDE_MAP 20 set transform-set <transformset> crypto map OUTSIDE_MAP 20 set security-association lifetime seconds 3600 crypto map OUTSIDE_MAP interface vpn crypto map REMOTE_MAP 20 ipsec-isakmp dynamic remotevpn_dyn_map crypto map REMOTE_MAP interface outside crypto isakmp enable outside crypto isakmp enable vpn GEHT NICHT: ---------------------- crypto dynamic-map remotevpn_dyn_map 20 set transform-set ESP-3DES-SHA crypto dynamic-map remotevpn_dyn_map 20 set security-association lifetime seconds 288000 crypto map OUTSIDE_MAP 20 match address <accessliste> crypto map OUTSIDE_MAP 20 set pfs crypto map OUTSIDE_MAP 20 set peer <peername> crypto map OUTSIDE_MAP 20 set transform-set <transformset> crypto map OUTSIDE_MAP 20 set security-association lifetime seconds 3600 crypto map OUTSIDE_MAP interface vpn crypto map OUTSIDE_MAP 65535 ipsec-isakmp dynamic remotevpn_dyn_map crypto isakmp enable outside crypto isakmp enable vpn alle anderen config parts identisch, im client die peer ip aufs das entsprechende 2. interface der asa (vpn) gelegt. das log des clients meldet im 2. fall DEL_REASON_PEER_NOT_RESPONDING sieht aus wie eine fw regel die das verhindert, aber ich sehe nicht das irgendwo etwas bestimmtes für das interface outside geöffnet war was hier eine rolle spielt.

schreib ich einfach beides in die cryptomap rein? Kennst du da ein knackiges howto? Danke im Voraus.

Hallo, ich habe probleme den ite2site tunnel und das remote vpn auf das gleich interface zu legen. solange remote acces auf dem anderen liegt ist alles i.o. sobald ich beides auf das gleiche (vpn interfac e) lege bricht der s2s tunnel zusammen) aktuelle config, beide auf verschiedenen interfaces: remote access: ---------------------- ip local pool VPN_Pool_new x.y.nx.1-x.y.nx.254 mask 255.255.255.0 group-policy remote_vpn internal group-policy remote_vpn attributes dns-server value x.y.z.n vpn-tunnel-protocol IPSec wins-server value x.y.z.n dns-server value x.y.z.n vpn-tunnel-protocol IPSec default-domain value dummy.local crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto dynamic-map remotevpn_dyn_map 20 set transform-set ESP-3DES-SHA crypto dynamic-map remotevpn_dyn_map 20 set security-association lifetime seconds 288000 crypto map remotevpn_map 20 ipsec-isakmp dynamic remotevpn_dyn_map crypto map remotevpn_map interface outside # ******** crypto isakmp enable outside # ******** crypto isakmp policy 20 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 crypto isakmp nat-traversal 20 tunnel-group remotevpn type ipsec-ra tunnel-group remotevpn general-attributes address-pool VPN_Pool_new default-group-policy remote_vpn tunnel-group remotevpn ipsec-attributes pre-shared-key XXXXXX sobald ich die mit ***** gekennzeichneten Zeilen auf crypto map remotevpn_map interface vpn crypto isakmp enable vpn ändere, wobei das interface vpn eben den site-2-site tunnel treibt, bricht der site-2-site zusammen. VIelen Dank im voraus für eure Meinungen.