Whistleblower 45 Geschrieben 27. April 2007 Melden Teilen Geschrieben 27. April 2007 Hallo zusammen, habe derzeit Probleme beim Zugriff auf einige Webseiten, wie z.B. www.dell.de (oder auch www.dell.com) Der Seitenaufbau dauert Minuten, ist aber irgendwann vollständig. Über einen anderen Weg (anderer ADSL-Router, anderer Provider) ist der Seitenaufbau problemlos. Vermute daher Probleme beim ip-inspect, welches auf beiden Interfaces (Vlan1, Dialer1) für in und out aktiv ist. Regeln: ip inspect name ethernet_0 tcp router-traffic ip inspect name ethernet_0 ftp ip inspect name ethernet_0 udp ip inspect name ethernet_0 http ip inspect name ethernet_0 realaudio ip inspect name ethernet_0 h323 ip inspect name ethernet_0 h323callsigalt ip inspect name ethernet_0 h323gatestat ip inspect name ethernet_0 skinny ip inspect name ethernet_0 fragment maximum 256 timeout 1 ip inspect name ethernet_0 sip-tls ip inspect name ethernet_0 sip ip inspect name ethernet_0 pptp Im Logging taucht zu der Seite nichts auf (aber dafür z.B. wenn auf Seiten Java geblockt wird). Wie kann ich das ganze sinnvoll debuggen, testen (wie schalte ich ip-inspect kurzzeitig aus, ohne dass ich hinterher sämtliche Client-Connections zurücksetzen muss), und wie bekomme ich den Router dazu, dass er die Seite fehlerfrei liest (kann man notfalls Ausnahmen für einzelne Adresse vom ip-inspect vornehmen)? Soviele Fragen bei soooo einem Wetter... ;-) Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 27. April 2007 Melden Teilen Geschrieben 27. April 2007 debug ip inspect http Entweder nimmst du den inspect vom Interface komplett raus oder halt von der Config wie du sie gepostet hast. Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 27. April 2007 Autor Melden Teilen Geschrieben 27. April 2007 Ergibt EWAIT TCP ACK 2347544940 SEQ 4135496290 LEN 200 (143.166.83.190:80) <= (10.x.x.x:2693) 026207: Apr 27 10:10:48.740 PCTime: CBAC sis 82CFDEE4 L4 inspect result: SKIP packet 82C35E50 (143.166.83.190:80) (10.x.x.x:2693) bytes 0 ErrStr = Retransmitt Verwirft also aus irgendeinem Grund das Paket... ? Kann ich die Debugausgabe nicht irgendwie filtern, z.B. nach der IP, damit ich nicht den ganzen Traffic sehe??? Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 27. April 2007 Melden Teilen Geschrieben 27. April 2007 Kommt die Meldung nur 1mal? Gehen microsoft.com, amazon.de und google.de? Wenn nein, poste mal die Config Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 27. April 2007 Autor Melden Teilen Geschrieben 27. April 2007 Hab den Debug nur kurz laufen lassen, wie gesagt, bis die Seite komplett aufgebaut ist, vergehen einige Minuten... Und wenn ichs länger laufen lassen, habe ich zuviel Output... :-( Deswegen die Frage, ob ichs gleich auf dem Cisco filtern kann, werds sonst nochmal übern Texteditor filtern... Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 27. April 2007 Autor Melden Teilen Geschrieben 27. April 2007 So, habe jetzt mal komplett ein Trace gezogen, bis die Startseite geladen war... Hier ein Auszug: 030397: Apr 27 12:23:14.963 PCTime: CBAC sis 82CFF1EC pak 82613DE0 SIS_CLOSED/LISTEN TCP SYN SEQ 2649143727 LEN 0 (217.91.120.31:1137) => (143.166.83.190:80) 030399: Apr 27 12:23:15.151 PCTime: CBAC sis 82CFF1EC pak 82C314E0 SIS_OPENING/SYNSENT TCP SYN ACK 2649143728 SEQ 2156885667 LEN 0 (143.166.83.190:80) <= (10.x.x.x:1137) 030400: Apr 27 12:23:15.155 PCTime: CBAC sis 82CFF1EC pak 82611928 SIS_OPENING/SYNRCVD TCP ACK 2156885668 SEQ 2649143728 LEN 0 (217.91.120.31:1137) => (143.166.83.190:80) 030405: Apr 27 12:23:15.155 PCTime: CBAC sis 82CFF1EC pak 82568770 SIS_OPEN/ESTAB TCP PSH ACK 2156885668 SEQ 2649143728 LEN 421 (217.91.120.31:1137) => (143.166.83.190:80) 030411: Apr 27 12:23:15.359 PCTime: CBAC sis 82CFF1EC pak 82619D58 SIS_OPEN/ESTAB TCP PSH ACK 2649144149 SEQ 2156885668 LEN 939 (143.166.83.190:80) <= (10.x.x.x:1137) 030454: Apr 27 12:23:15.499 PCTime: CBAC sis 82CFF1EC pak 82612F30 SIS_OPEN/ESTAB TCP ACK 2156886607 SEQ 2649144149 LEN 0 (217.91.120.31:1137) => (143.166.83.190:80) 030498: Apr 27 12:23:15.575 PCTime: CBAC sis 82CFFCCC pak 826127D8 SIS_CLOSED/LISTEN TCP SYN SEQ 2102944013 LEN 0 (217.91.120.31:1138) => (143.166.224.202:80) 030532: Apr 27 12:23:15.767 PCTime: CBAC sis 82CFFCCC pak 82615EEC SIS_OPENING/SYNSENT TCP SYN ACK 2102944014 SEQ 120447181 LEN 0 (143.166.224.202:80) <= (10.x.x.x:1138) 030533: Apr 27 12:23:15.767 PCTime: CBAC sis 82CFFCCC pak 82C3188C SIS_OPENING/SYNRCVD TCP ACK 120447182 SEQ 2102944014 LEN 0 (217.91.120.31:1138) => (143.166.224.202:80) 030538: Apr 27 12:23:15.767 PCTime: CBAC sis 82CFFCCC pak 82C4123C SIS_OPEN/ESTAB TCP PSH ACK 120447182 SEQ 2102944014 LEN 731 (217.91.120.31:1138) => (143.166.224.202:80) 030570: Apr 27 12:23:15.987 PCTime: CBAC sis 82CFFCCC pak 82C38308 SIS_OPEN/ESTAB TCP PSH ACK 2102944745 SEQ 120447182 LEN 645 (143.166.224.202:80) <= (10.x.x.x:1138) 030578: Apr 27 12:23:15.987 PCTime: CBAC sis 82CFFCCC pak 82560F2C SIS_OPEN/ESTAB TCP PSH ACK 2102944745 SEQ 120449087 LEN 200 (143.166.224.202:80) <= (10.x.x.x:1138) 030579: Apr 27 12:23:15.990 PCTime: CBAC sis 82CFFCCC L4 inspect result: DROP packet 82560F2C (143.166.224.202:80) (10.x.x.x:1138) bytes 200 ErrStr = Out-Of-Order Segment http 030580: Apr 27 12:23:15.990 PCTime: CBAC sis 82CFFCCC pak 82C386B4 SIS_OPEN/ESTAB TCP ACK 2102944745 SEQ 120447827 LEN 1260 (143.166.224.202:80) <= (10.x.x.x:1138) 030586: Apr 27 12:23:15.994 PCTime: CBAC sis 82CFFCCC pak 8253EAC8 SIS_OPEN/ESTAB TCP PSH ACK 2102944745 SEQ 120450547 LEN 200 (143.166.224.202:80) <= (10.x.x.x:1138) 030587: Apr 27 12:23:15.994 PCTime: CBAC sis 82CFFCCC L4 inspect result: DROP packet 8253EAC8 (143.166.224.202:80) (10.x.x.x:1138) bytes 200 ErrStr = Out-Of-Order Segment http 030588: Apr 27 12:23:15.994 PCTime: CBAC sis 82CFFCCC pak 82614538 SIS_OPEN/ESTAB TCP ACK 120449087 SEQ 2102944745 LEN 0 (217.91.120.31:1138) => (143.166.224.202:80) 030589: Apr 27 12:23:15.994 PCTime: CBAC sis 82CFFCCC pak 82C3D3D0 SIS_OPEN/ESTAB TCP ACK 2102944745 SEQ 120449287 LEN 1260 (143.166.224.202:80) <= (10.x.x.x:1138) 030590: Apr 27 12:23:15.994 PCTime: CBAC sis 82CFFCCC L4 inspect result: DROP packet 82C3D3D0 (143.166.224.202:80) (10.x.x.x:1138) bytes 1260 ErrStr = Out-Of-Order Segment http So geht das die ganze Zeit, nur dass am Ende irgendwann mal die Pakete durchgehen... Hat der hier Probleme mit der Paketgröße (das leidige Thema MTU...?), oder warum kommen die nicht in der richtigen Reihenfolge an??? Hab schon ein ip tcp adjust-mss 1300 auf dem Vlan 1... Hab allerdings grad gesehen, dass der Dialer (sh int di 1) eine MTU von 1500 hat, sollte eigentlich 1492 sein... Hmmmm... Sollte das der Grund sein? Zitieren Link zu diesem Kommentar
mturba 10 Geschrieben 27. April 2007 Melden Teilen Geschrieben 27. April 2007 Dass bei "show int dialer1" eine MTU von 1500 angezeigt wird, ist normal... wichtig ist, dass am Dialer-Interface eine MTU von 1492 konfiguriert ist ("show run int dialer1 | include mtu"). Hab mich allerdings auch schonmal drüber gewundert, wieso dann trotzdem 1500 bei "sh int" angezeigt werden... weiß jemand, wieso? Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 27. April 2007 Melden Teilen Geschrieben 27. April 2007 Am besten waere ein "deb ppp neg", "ter mon", "clear pppoe all". Dan siehste was deine MTU ist. Normalerweise wird sie dir vorgegeben vom ISP. Ich check auch nicht warum die das immer falsch anzeigt. Ich glaub das liegt generell am Dialer IF Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 27. April 2007 Autor Melden Teilen Geschrieben 27. April 2007 Am besten waere ein "deb ppp neg", "ter mon", "clear pppoe all". Danke, werde ich mal machen, wenn hier weniger Traffic ist... Eigentlich hatte ich das auch mal fest konfiguriert, aber ist wohl irgendwann wieder rausgewandert... Mal schauen, ob's dann daran liegt... Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 27. April 2007 Autor Melden Teilen Geschrieben 27. April 2007 So grade nochmal getestet. "debug ppp neg" sagt 1492, also wie gewünscht... Habe sicherheitshalber auch noch mal auf dem Dialer definitiv 1492 angegeben. Macht allerdings keinen Unterschied. Sobald ich allerdings "ip inspect name ethernet_0 http" rausnehme, läuft die Seite (wie zu erwarten) auf Anhieb... Aber das ist eigentlich nicht die gewünschte Einstellung... :-( Noch Ideen, woran es scheitern könnte? Oder kann ich die Seite als Ausnahme definieren? Zitieren Link zu diesem Kommentar
tom12 10 Geschrieben 28. April 2007 Melden Teilen Geschrieben 28. April 2007 Hi, ist schon spät und hab mir nicht alle posts durchgelesen... Hatte mal sowas ähnliches. Versuch am LAN INterface: ip tcp adiust-mss 1400 grüsse Thomas Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 1. Mai 2007 Autor Melden Teilen Geschrieben 1. Mai 2007 Hi Thomas, hab das VLAN-Interface eigentlich schon MSS auf 1300 gestellt. Vielleicht muss ich tatsächlich mal ein wenig mit dem Wert varieren... Werds die Woche wohl mal austesten... Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 2. Mai 2007 Melden Teilen Geschrieben 2. Mai 2007 Hm, kann mir jemand vielleicht ganz allgemein bzw kurz und knapp sagen wie Ip inspect arbeitet ? hab zwar ein paar Konfigbeispiele gefunden, das die Inspektion auf Layer 7 basiert, aber wie man damit umgeht nicht so recht. also ip inspect "name" Protokoll und dann das binden am interface, zu was führt das ? blockieren oder zulassen ? passt meine Annahme soweit das ich über ip inspecdtion zb FTP oder telnet verkehr auf irgendwelchen phantasieports blocken könnte ? Zitieren Link zu diesem Kommentar
Whistleblower 45 Geschrieben 2. Mai 2007 Autor Melden Teilen Geschrieben 2. Mai 2007 Hi Otaku, so wie ich das bisher verstanden habe, überprüft ip inspect, ob der jeweilige Traffic protokoll-konform ist. Daher (bei mir) vermutlich auch die Probleme mit http, da er vermutlich fragmentierte Pakete nicht richtig zusammensetzen kann. Wenn Du ip inspect für ftp nutzen willst, und nicht den Standardport 21 verwendest, mußt Du die PAM table (Port Application Mapping) anpassen. z.B. in der Form: ip port-map application_name port port_# [list acl_#] Also für application_name ftp, für port_# Deinen ftp-Port und optional die ACL, die dafür genutzt werden soll (in der Du z.B. Deinen einzelnen ftp-Server angibst). Kontrollieren kannst Du die Einträge dann über show ip port-map Die Ports für eingehende Dienste (wie ftp, www ...) würde ich allerdings schon vorher über eine ACL einschränken. Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 2. Mai 2007 Melden Teilen Geschrieben 2. Mai 2007 aha, also prüft das ding ob eben zB http oder FTP Pakete die da übers interface wandern auch zum Protokoll passen und nicht sosnt irgendwelcehn Unfug treiben. und mit ip inspect...gebe ich an um welceh Art von Verkehr sich das ganze kümmern soll ? ip inspect entscheidet dann quasi selbst welche pakete verworfen werden udn welche nicht Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.