#9370

nein #9370

Hallo mr-windows, deinen letzten Post verstehe ich nicht. Die zwei Routen würden so ausschauen: ! Route für DSL ip route 0.0.0.0 0.0.0.0 dialer0 ! Route für das ISDN Backup ip route 0.0.0.0 0.0.0.0 bri0 200 #9370

was sagen die dot1x debugs oder Radius Logs? #9370

ich war nur ein wenig verwirrt.... :D

@fu: der zweite Satz war auf die Frage von xyCruiseryx bezogen.

use-bia hat aber nichts mit der IP Adresse zu tun, sondern mit der MAC. Soweit ich weiß, nimmt der Router immer die "physikalische" Adresse und nie die virtuelle. #9370 edit: Bei Cisco ist das so, bei anderen weiß ich es nicht

nur, dass hier kein IGP einsetzbar ist. Was anderes: Warum verwendest du dialer-watch? Meines Wissens nach wird das verwendet, um ein ISDN Backup aufzubauen, wenn bestimmte Routen nicht vorhanden sind - ich habe das bis jetzt noch nie verwendet. Ich würde das hier anders lösen: Default Route auf das DSL; Default Route mit AD 200 auf das Dialer oder BRI Interface => Ist das DSL Intf down, zieht die ISDN Route und das ISDN wird aufgebaut. #9370

ich schätze mal, dass es gerade sein wird. Benützt werden sicher die mittleren zwei oder vier Pins. #9370

das ist natürlich ein Argument ;)

In so einer Situation verwendet man am besten ein IGP über DSL und eine statische Route mit AD 200 (Bsp) über ISDN. Wenn das IGP den Nachbaren verliert, dann zieht die statische Route und wenn das IGP wieder da ist, dann geht alles den normalen Weg.

wenn der Router ein Paket bekommt, schaut er sich den Status der Session nicht an, sondern nur die Dest IP und dann sucht er sich die "beste" Route und das zugehörige Interface und schickt das Paket raus. #9370

"show logg" - wenn nicht allzuviel los war, dann sieht man, welche Ports wann den Status geändert haben. Im besten Fall hat man einen Syslog Server... #9370

@wordo: das bgp ist nur am ISDN Router aktiv und hat keine Gegenstelle -> es werden nur bgp hellos ins Nirvana geschickt, die aber dazu ausreichen, das ISDN zu aktivieren. #9370

geht das rdp mit einer Source weg, die nur über das ISDN erreichbar ist? Ansonsten ist mir schleierhaft, warum rdp über das ISDN geroutet wird, obwohl die Route über die Standleitung zeigt.

Ich habe mir noch einmal die Problembeschreibung durchgelesen und mich irritiert folgendes: Warum geht die RDP Session noch über das ISDN, wenn die "normale" Route wieder da ist. Der Router sollte dann diese verwenden und die RDP Pakete über die DSL Leitung schicken. Da hat es noch ein anderes Problem. #9370

dann steht nichts mehr im Weg :)

Hallo Wordo, ich habe leider nichts mehr gefunden - das letzte Mal ist schon einige Zeit her. Die Config schaut aber so aus: Setup: ein oder zwei Router; OSPF oder EIGRP über die Standleitung und am LAN; HSRP zwischen den Routern; floating static auf dem ISDN Router; BGP mit einem Pseudo Nachbaren auf dem ISDN Router; Fehlt dem ISDN Router die IGP Route über das LAN zum BGP Nachbaren, dann wird das ISDN aufgebaut. HSRP schaltet zum ISDN Router um, sobald die Leitung down oder der Router tot. Für den Fall eines Routingproblems (HSRP schaltet nicht um) wird noch eine floating static auf dem Standleitungsrouter konfiguriert, die auf den ISDN Router zeigt; Das Setup wurde bei mehreren Kunden erfolgreich eingesetzt. Das Problem ist nur, dass es sich mit 800 Routern nicht realisieren lässt, da sie kein BGP können (keine Ahnung, ob das noch immer so ist). Wir haben das immer bei Kunden eingesetzt, die nicht nur IP im Einsatz hatten, sondern auch IPX usw., damit es einen verlässlichen Trigger für das ISDN gibt. In dem Fall sollte es aber auch funktionieren. #9370

ich muss mal in den Untiefen meines Notebooks wühlen...

das stimmt natürlich. Wir haben für so einen Backupfall immer BGP konfiguriert. Funktionsweise: BGP nur auf dem ISDN Router aktivieren und als einziges in die dialer-list mitaufnehmen. BGP sendet periodisch Hellos an eine Unicast Adresse (ganz egal, ob sich dahinter ein anderer BGP Router verbirgt). Solange die DSL Leitung da ist, werden die Hellos darüber geschickt. Im Fehlerfall geht das ISDN up und der gesamte Verkehr geht über die Wählleitung. usw. Wenn der Router kein BGP kann, muss man sich über ein anderes Protokoll Gedanken machen oder ein Script auf einem Rechner verwenden. #9370

solange das rdp in der dialer-list drinnen steht, nicht. #9370

Das Line-Protocol (L2) ist nur up, wenn eine Verbindung zur Gegenstelle, mit der ppp, hdlc, frame-relay usw. gesprochen wird, vorhanden ist. Solange da keine Daten hin und her gehen, bleibt as Line-Protocol auf Down. Der Router setzt es auch probehalber nicht wieder auf up. In deinem Fall war wahrscheinlich die Leitung kurz up und dann wieder gestört. #9370 Die Befehle machen folgendes: pulse-time: To enable pulsing data terminal ready (DTR) signal intervals on the serial interfaces, use the pulse-time command in interface configuration mode. To restore the default interval, use the no form of this command. carrier-delay: To set the carrier delay on a serial interface, use the carrier-delay command in interface configuration mode. To return to the default carrier delay value, use the no form of this command. Usage Guidelines If a link goes down and comes back up before the carrier delay timer expires, the down state is effectively filtered, and the rest of the software on the switch is not aware that a link-down event occurred. Therefore, a large carrier delay timer results in fewer link-up/link-down events being detected. On the other hand, setting the carrier delay time to 0 means that every link-up/link-down event is detected. In most environments a lower carrier delay is better than a higher one. The exact value that you choose depends on the nature of the link outages that you expect to see in your network and how long you expect those outages to last. If data links in your network are subject to short outages, especially if those outages last less than the time it takes for your IP routing to converge, you should set a relatively long carrier delay value to prevent these short outages from causing unnecessary churn in your routing tables. If outages in your network tend to be longer, you might want to set a shorter carrier delay so that the outages are detected sooner, and the IP route convergence begins and ends sooner. keepalive: To enable keepalive packets and to specify the number of times that the Cisco IOS software tries to send keepalive packets without a response before bringing down the interface or before bringing the tunnel protocol down for a specific interface, use the keepalive command in interface configuration mode. When the keepalive function is enabled, a keepalive packet is sent at the specified time interval to keep the interface active. To turn off keepalive packets entirely, use the no form of this command.

natürlich macht es Sinn, die Userinfos bei größeren Installationen aus anderen Datenbanken abzufragen (Bsp. MS AD). Am Radius Server können dann die AD Gruppen auf Radius Gruppen gemappt werden und somit unterschiedliche Profile angelegt werden. Deine 2. Frage habe ich nicht verstanden. #9370

Command Accounting ist mit Syslog nicht möglich. Das was du suchst ist aaa accounting -> dafür wird aber ein Radius/Tacacs Server (in dem Fall besser TACACS) benötigt. Mitt aaa accounting werden login Infos und bei entsprechender Konfiguration auch ausgeführte Commands per User ausgegeben. #9370

Hallo, keine Ahnung wie das bei HP ist, aber im Normalfall hat der Switch per Default Spanning-Tree aktiviert und damit ist ein Loop (im Normalfall) nicht möglich. #9370

Hast du im Controller eine clock-source angegeben? #9370