Capturing IPv6 packets. [7:73033]
Hello everybody, I am wondering if there is any tool like Sniffer / Ethereal which allows capturing and analysing IPv6 traffic? Thanks, Rajesh Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73033t=73033 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Capturing IPv6 packets. [7:73033]
Couple of options based on web searching. Ipgrab - http://ipgrab.sourceforge.net/ Ethereal - http://www.ethereal.com/ Linux Based sniffer - http://members.tripod.com/~YohanFernando/sniffer.html Others possibly such as dsniff. Ian www.ccie4u.com Rack Rentals and Lab Scenarios starting at $20 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rajesh Kumar Sent: Friday, July 25, 2003 1:30 PM To: [EMAIL PROTECTED] Subject: Capturing IPv6 packets. [7:73033] Hello everybody, I am wondering if there is any tool like Sniffer / Ethereal which allows capturing and analysing IPv6 traffic? Thanks, Rajesh Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=73047t=73033 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Computer receiving packets which are connected to [7:71600]
Ashok C Braganza wrote: I have a strange problem; all my Microsoft XP Professional operating system client computers are sending and receiving packets continues (Ethernet Adapter light blinks continues) which are connected to Cisco switch, but if I connect to normal hub or 3com switch, it stops, I checked with sniffer, it says spanning tree, and it shows Cisco IOS details. This problem is only in XP other Microsoft operating system like Win98, ME etc, doesn't send or received any packets. A switch running the spanning tree protocol sends Bridge Protocol Data Unit (BPDU) frames every 2 seconds. That's normal. You could disable it, but that's risky. A Cisco switch sends lots of other stuff too, like keepalives (every 10 seconds), Cisco Discovery Protocol (CDP) every 60 seconds, VTP depending on your config, etc. It's normal. No worries. As far as the computers sending, well, that's a good thing, eh? They would be broken if they didn't send. As far as it only being Windows XP, that could be something else. You could copy and paste some frames of interest and ask about them specifically. Priscilla Can someoe help me, what could be the problem Thanks A. Braganza Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71669t=71600 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Computer receiving packets which are connected to [7:71600]
What is the switch port set to on the Cisco switch? -Auto negotiation? -Portfast - Spanning tree? -Is there any CRC's or runts on the switch port when the XP hosts are connected? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71623t=71600 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Computer receiving packets which are connected to Cisco Switch [7:71600]
I have a strange problem; all my Microsoft XP Professional operating system client computers are sending and receiving packets continues (Ethernet Adapter light blinks continues) which are connected to Cisco switch, but if I connect to normal hub or 3com switch, it stops, I checked with sniffer, it says spanning tree, and it shows Cisco IOS details. This problem is only in XP other Microsoft operating system like Win98, ME etc, doesn't send or received any packets. Can someoe help me, what could be the problem Thanks A. Braganza Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=71600t=71600 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dhcp packets not visible in 6509 [7:70898]
Vik, There could be any number of reasons that DHCP isn't working. The client may not be requesting DHCP, the switch may not have portfast enabled, a router not having an IP helper address, DHCP server offline, DHCP server without a scope for the VLAN, and so on. Perform a packet trace from the DHCP client and if necessary on the DHCP server (using SPAN). You will be able to determine the problem by identifying which packets are present in the capture and which are not. For example, you may find that the client sends a DHCP discovery packet but does not receive an offer packet from the DHCP server. If you see the same behavior on the server port (discovery, no offer) then it's possible that: - The DHCP server isn't operational or the service/daemon isn't running - The DHCP server doesn't have a scope defined for that VLAN - The DHCP server has run out of IP addresses for that VLAN On the other hand, if you the capture shows a discovery packet is sent by the client but the packet is never seen by the DHCP server it's much more likely that you have a missing (or incorrect) IP helper address. Once you perform the packet capture(s) you will probably need no further help. If you do, the information obtained from the capture would be enough for the group to point you in the right direction. - Tom Vik Vikky wrote: Hi *, am fairly new to cisco products/ commands. have a problem got a WS-X6348-RJ-45 module at slot 3 of 6509. In which am unable to get DHCP broadcast /address from the main dhcp server. configured all the ports to respective vlan-x and at the routing module in a core switch (6509 with msfc) I hv given the ip helperaddress for this vlan. rest of the catalyst 4006 switch fetches dhcp frm this scope. Below is the module capabilities: Type 10/100BaseTX Speedauto,10,100 Duplex half,full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel yes Broadcast suppressionpercentage(0-100) Flow control receive-(off,on),send-(off) Security yes Dot1xyes Membership static,dynamic Fast start yes QOS scheduling rx-(1q4t),tx-(2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan1..1000,1025..4094,untagged,dot1p,none SPAN source,destination COPS port group 3/1-48 Link debounce timer yes Module configuration: set vlan 68 3/1-48 set port auxiliaryvlan 3/1-48 none set port qos 3/1-48 trust-ext untrusted set port qos 3/1-48 cos-ext 0 set port enable 3/1-48 set port speed 3/1-48 auto set port trap 3/1-48 enable set port name 3/1-48 set port dot1x 3/1-48 port-control force-autho set port dot1x 3/1-48 multiple-host disable set port dot1x 3/1-48 re-authentication disabl set port security 3/1-48 disable age 0 maximum set port broadcast 3/1-48 100.00% set port membership 3/1-48 static set port protocol 3/1-48 ip on set port protocol 3/1-48 ipx auto set port protocol 3/1-48 group auto set port flowcontrol3/1-48 send off set port flowcontrol3/1-48 receive off set cdp enable 3/1-48 set udld disable 3/1-48 set udld aggressive-mode disable 3/1-48 Cat-OS version: cat6000-sup.6-3-9.bin Can you guide me, anything I am missing out. Thank you _ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=70926t=70898 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
dhcp packets not visible in 6509 [7:70898]
Hi *, am fairly new to cisco products/ commands. have a problem got a WS-X6348-RJ-45 module at slot 3 of 6509. In which am unable to get DHCP broadcast /address from the main dhcp server. configured all the ports to respective vlan-x and at the routing module in a core switch (6509 with msfc) I hv given the ip helperaddress for this vlan. rest of the catalyst 4006 switch fetches dhcp frm this scope. Below is the module capabilities: Type 10/100BaseTX Speedauto,10,100 Duplex half,full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel yes Broadcast suppressionpercentage(0-100) Flow control receive-(off,on),send-(off) Security yes Dot1xyes Membership static,dynamic Fast start yes QOS scheduling rx-(1q4t),tx-(2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan1..1000,1025..4094,untagged,dot1p,none SPAN source,destination COPS port group 3/1-48 Link debounce timer yes Module configuration: set vlan 68 3/1-48 set port auxiliaryvlan 3/1-48 none set port qos 3/1-48 trust-ext untrusted set port qos 3/1-48 cos-ext 0 set port enable 3/1-48 set port speed 3/1-48 auto set port trap 3/1-48 enable set port name 3/1-48 set port dot1x 3/1-48 port-control force-autho set port dot1x 3/1-48 multiple-host disable set port dot1x 3/1-48 re-authentication disabl set port security 3/1-48 disable age 0 maximum set port broadcast 3/1-48 100.00% set port membership 3/1-48 static set port protocol 3/1-48 ip on set port protocol 3/1-48 ipx auto set port protocol 3/1-48 group auto set port flowcontrol3/1-48 send off set port flowcontrol3/1-48 receive off set cdp enable 3/1-48 set udld disable 3/1-48 set udld aggressive-mode disable 3/1-48 Cat-OS version: cat6000-sup.6-3-9.bin Can you guide me, anything I am missing out. Thank you _ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=70898t=70898 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RES: dhcp packets not visible in 6509 [7:70898]
Did you enable spannint-tree portfast ? I'd use set port host instead , which includes STP portfast, aomong other things . . . _ Henrique Issamu Terada, CCIE # 7460 IT Support - Open Network CPM S.A. - Tecnologia criando valor Tel.: 55 11 4196-0710 Fax: 55 11 4196-0900 [EMAIL PROTECTED] www.cpm.com.br -- --- Esta mensagem pode conter informagco confidencial e/ou privilegiada. Se vocj nco for o destinatario ou a pessoa autorizada a receber esta mensagem, nco pode usar, copiar ou divulgar as informagues nela contidas ou tomar qualquer agco baseada nessas informagues. Se vocj recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperagco. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Mensagem original- De: Vik Vikky [SMTP:[EMAIL PROTECTED] Enviada em: quarta-feira, 18 de junho de 2003 22:14 Para: [EMAIL PROTECTED] Assunto: dhcp packets not visible in 6509 [7:70898] Hi *, am fairly new to cisco products/ commands. have a problem got a WS-X6348-RJ-45 module at slot 3 of 6509. In which am unable to get DHCP broadcast /address from the main dhcp server. configured all the ports to respective vlan-x and at the routing module in a core switch (6509 with msfc) I hv given the ip helperaddress for this vlan. rest of the catalyst 4006 switch fetches dhcp frm this scope. Below is the module capabilities: Type 10/100BaseTX Speedauto,10,100 Duplex half,full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel yes Broadcast suppressionpercentage(0-100) Flow control receive-(off,on),send-(off) Security yes Dot1xyes Membership static,dynamic Fast start yes QOS scheduling rx-(1q4t),tx-(2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan1..1000,1025..4094,untagged,dot1p,none SPAN source,destination COPS port group 3/1-48 Link debounce timer yes Module configuration: set vlan 68 3/1-48 set port auxiliaryvlan 3/1-48 none set port qos 3/1-48 trust-ext untrusted set port qos 3/1-48 cos-ext 0 set port enable 3/1-48 set port speed 3/1-48 auto set port trap 3/1-48 enable set port name 3/1-48 set port dot1x 3/1-48 port-control force-autho set port dot1x 3/1-48 multiple-host disable set port dot1x 3/1-48 re-authentication disabl set port security 3/1-48 disable age 0 maximum set port broadcast 3/1-48 100.00% set port membership 3/1-48 static set port protocol 3/1-48 ip on set port protocol 3/1-48 ipx auto set port protocol 3/1-48 group auto set port flowcontrol3/1-48 send off set port flowcontrol3/1-48 receive off set cdp enable 3/1-48 set udld disable 3/1-48 set udld aggressive-mode disable 3/1-48 Cat-OS version: cat6000-sup.6-3-9.bin Can you guide me, anything I am missing out. Thank you _ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=70902t=70898 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: dhcp packets not visible in 6509 [7:70898]
you need to enable portfast. Read about portfast. Set spantree portfast enable ( I think this is the syntax I don't have a 6509 in front of me now.) Vik Vikky wrote in message news:[EMAIL PROTECTED] Hi *, am fairly new to cisco products/ commands. have a problem got a WS-X6348-RJ-45 module at slot 3 of 6509. In which am unable to get DHCP broadcast /address from the main dhcp server. configured all the ports to respective vlan-x and at the routing module in a core switch (6509 with msfc) I hv given the ip helperaddress for this vlan. rest of the catalyst 4006 switch fetches dhcp frm this scope. Below is the module capabilities: Type 10/100BaseTX Speedauto,10,100 Duplex half,full Trunk encap type 802.1Q,ISL Trunk mode on,off,desirable,auto,nonegotiate Channel yes Broadcast suppressionpercentage(0-100) Flow control receive-(off,on),send-(off) Security yes Dot1xyes Membership static,dynamic Fast start yes QOS scheduling rx-(1q4t),tx-(2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan1..1000,1025..4094,untagged,dot1p,none SPAN source,destination COPS port group 3/1-48 Link debounce timer yes Module configuration: set vlan 68 3/1-48 set port auxiliaryvlan 3/1-48 none set port qos 3/1-48 trust-ext untrusted set port qos 3/1-48 cos-ext 0 set port enable 3/1-48 set port speed 3/1-48 auto set port trap 3/1-48 enable set port name 3/1-48 set port dot1x 3/1-48 port-control force-autho set port dot1x 3/1-48 multiple-host disable set port dot1x 3/1-48 re-authentication disabl set port security 3/1-48 disable age 0 maximum set port broadcast 3/1-48 100.00% set port membership 3/1-48 static set port protocol 3/1-48 ip on set port protocol 3/1-48 ipx auto set port protocol 3/1-48 group auto set port flowcontrol3/1-48 send off set port flowcontrol3/1-48 receive off set cdp enable 3/1-48 set udld disable 3/1-48 set udld aggressive-mode disable 3/1-48 Cat-OS version: cat6000-sup.6-3-9.bin Can you guide me, anything I am missing out. Thank you _ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=70903t=70898 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP packets unroutable???? [7:65250]
Did you make a type-o perhaps? Source IP = 138.108.168.3 Destination IP = 138.168.108.2 Maybe you mixed up the 168.108 / 108.168 parts? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xy Hien Le Sent: Wednesday, March 12, 2003 10:45 PM To: [EMAIL PROTECTED] Subject: IP packets unroutable [7:65250] Hello Everyone, I have this router which will give me the debug message everytime I ping a connected network: Every interfaces, ATM, FastEthernet, Serial etc are same results. Seemed like there are no arp cache for the connect interfaces, but I do not know the solution to solve this problem!!! Anyone with the same problem and solutions??? Help routerC#debug ip packet de IP packet debugging is on (detailed) routerC#ping 138.168.108.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 138.168.108.2, timeout is 2 seconds: 00:13:17: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:17: ICMP type=8, code=0. 00:13:19: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:19: ICMP type=8, code=0. 00:13:21: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:21: ICMP type=8, code=0. 00:13:23: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:23: ICMP type=8, code=0. 00:13:25: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:25: ICMP type=8, code=0. Success rate is 0 percent (0/5) routerC# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65271t=65250 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
IP packets unroutable???? [7:65250]
Hello Everyone, I have this router which will give me the debug message everytime I ping a connected network: Every interfaces, ATM, FastEthernet, Serial etc are same results. Seemed like there are no arp cache for the connect interfaces, but I do not know the solution to solve this problem!!! Anyone with the same problem and solutions??? Help routerC#debug ip packet de IP packet debugging is on (detailed) routerC#ping 138.168.108.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 138.168.108.2, timeout is 2 seconds: 00:13:17: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:17: ICMP type=8, code=0. 00:13:19: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:19: ICMP type=8, code=0. 00:13:21: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:21: ICMP type=8, code=0. 00:13:23: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:23: ICMP type=8, code=0. 00:13:25: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:25: ICMP type=8, code=0. Success rate is 0 percent (0/5) routerC# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65250t=65250 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: IP packets unroutable???? [7:65250]
Maybe if you include the running-config, forum members may be able to help. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65252t=65250 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: IP packets unroutable???? [7:65250]
I've never seen that before, but I'd hazard to guess there isn't a 138.168.0.0 network in your routing table. post your routing table. scott Xy Hien Le wrote in message news:[EMAIL PROTECTED] Hello Everyone, I have this router which will give me the debug message everytime I ping a connected network: Every interfaces, ATM, FastEthernet, Serial etc are same results. Seemed like there are no arp cache for the connect interfaces, but I do not know the solution to solve this problem!!! Anyone with the same problem and solutions??? Help routerC#debug ip packet de IP packet debugging is on (detailed) routerC#ping 138.168.108.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 138.168.108.2, timeout is 2 seconds: 00:13:17: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:17: ICMP type=8, code=0. 00:13:19: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:19: ICMP type=8, code=0. 00:13:21: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:21: ICMP type=8, code=0. 00:13:23: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:23: ICMP type=8, code=0. 00:13:25: IP: s=138.108.168.3 (local), d=138.168.108.2, len 100, unroutable 00:13:25: ICMP type=8, code=0. Success rate is 0 percent (0/5) routerC# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65258t=65250 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ntp packets modes [7:58359]
From RFC 1305. 0 - unspecified 1 - symmetric active 2 - symmetric passive 3 - client 4 - server 5 - broadcast 6 - reserved for NTP control message 7 - reserved for private use Symmetric Active (1): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer. Symmetric Passive (2): This type of association is ordinarily created upon arrival of a message from a peer operating in the symmetric active mode and persists only as long as the peer is reachable and operating at a stratum level less than or equal to the host; otherwise, the association is dissolved. However, the association will always persist until at least one message has been sent in reply. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer. --- John Tafasi wrote: the debug ntp packets command shows packets sent and received with different modes. What are these modes? can some one explain? R5-2503# Mar 6 02:42:08.879: NTP: rcv packet from 10.10.10.1 to 10.10.10.2 on BRI0: Mar 6 02:42:08.883: leap 0, mode 2, version 3, stratum 8, ppoll 64 Mar 6 02:42:08.887: rtdel (0.000), rtdsp 0009 (0.137), refid 7F7F0701 (12 7.127.7.1) Mar 6 02:42:08.891: ref AF428DF1.DDC96254 (02:41:53.866 UTC Sat Mar 6 1993) Mar 6 02:42:08.891: org AF428DCF.F7F245A8 (02:41:19.968 UTC Sat Mar 6 1993) Mar 6 02:42:08.895: rec AF428DCF.FC06E685 (02:41:19.984 UTC Sat Mar 6 1993) Mar 6 02:42:08.899: xmt AF428E00.DDC524C4 (02:42:08.866 UTC Sat Mar 6 1993) Mar 6 02:42:08.903: inp AF428E00.E1C1EE1B (02:42:08.881 UTC Sat Mar 6 1993) R5-2503# Mar 6 02:42:23.966: NTP: xmit packet to 10.10.10.1: Mar 6 02:42:23.970: leap 0, mode 1, version 3, stratum 8, ppoll 1024 Mar 6 02:42:23.970: rtdel (0.000), rtdsp 000B (0.168), refid 7F7F0701 (12 7.127.7.1) Mar 6 02:42:23.974: ref AF428DEF.F7D4D2C0 (02:41:51.968 UTC Sat Mar 6 1993) Mar 6 02:42:23.978: org AF428E00.DDC524C4 (02:42:08.866 UTC Sat Mar 6 1993) Mar 6 02:42:23.982: rec AF428E00.E1C1EE1B (02:42:08.881 UTC Sat Mar 6 1993) Mar 6 02:42:23.986: xmt AF428E0F.F7B05F8D (02:42:23.967 UTC Sat Mar 6 1993) R5-2503# __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58360t=58359 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
ntp packets modes [7:58359]
the debug ntp packets command shows packets sent and received with different modes. What are these modes? can some one explain? R5-2503# Mar 6 02:42:08.879: NTP: rcv packet from 10.10.10.1 to 10.10.10.2 on BRI0: Mar 6 02:42:08.883: leap 0, mode 2, version 3, stratum 8, ppoll 64 Mar 6 02:42:08.887: rtdel (0.000), rtdsp 0009 (0.137), refid 7F7F0701 (12 7.127.7.1) Mar 6 02:42:08.891: ref AF428DF1.DDC96254 (02:41:53.866 UTC Sat Mar 6 1993) Mar 6 02:42:08.891: org AF428DCF.F7F245A8 (02:41:19.968 UTC Sat Mar 6 1993) Mar 6 02:42:08.895: rec AF428DCF.FC06E685 (02:41:19.984 UTC Sat Mar 6 1993) Mar 6 02:42:08.899: xmt AF428E00.DDC524C4 (02:42:08.866 UTC Sat Mar 6 1993) Mar 6 02:42:08.903: inp AF428E00.E1C1EE1B (02:42:08.881 UTC Sat Mar 6 1993) R5-2503# Mar 6 02:42:23.966: NTP: xmit packet to 10.10.10.1: Mar 6 02:42:23.970: leap 0, mode 1, version 3, stratum 8, ppoll 1024 Mar 6 02:42:23.970: rtdel (0.000), rtdsp 000B (0.168), refid 7F7F0701 (12 7.127.7.1) Mar 6 02:42:23.974: ref AF428DEF.F7D4D2C0 (02:41:51.968 UTC Sat Mar 6 1993) Mar 6 02:42:23.978: org AF428E00.DDC524C4 (02:42:08.866 UTC Sat Mar 6 1993) Mar 6 02:42:23.982: rec AF428E00.E1C1EE1B (02:42:08.881 UTC Sat Mar 6 1993) Mar 6 02:42:23.986: xmt AF428E0F.F7B05F8D (02:42:23.967 UTC Sat Mar 6 1993) R5-2503# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58359t=58359 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Packets received on wrong pvc [7:57509]
I turned on some debugging and I am seeing this message in my log files. Does anyone know the cause or how to correct? IP precedence 0 received on voice but should have been on data --Mark Snips of the router config: class-map match-all voip match access-group 100 policy-map llq class voip priority 80 set ip dscp cs5 class class-default fair-queue set ip dscp default vc-class atm vip vbr-rt 256 256 20 precedence 5-7 no bump traffic no protect vc no protect group vc-class atm normal vbr-nrt 192 192 precedence 0-4 no protect vc no protect group end interface ATM0/0 bandwidth 256 ip address 1.1.1.254 255.255.255.0 no atm ilmi-keepalive bundle-enable bundle qosmap protocol ip 1.1.1.1 encapsulation aal5snap pvc-bundle voice 0/36 class-vc vip service-policy output llq pvc-bundle data 0/37 class-vc normal service-policy output llq ! dsl equipment-type CPE dsl operating-mode GSHDSL symmetric annex A dsl linerate AUTO access-list 100 permit ip any any dscp cs5 access-list 100 permit ip any any precedence critical access-list 100 permit tcp any any eq 1720 access-list 100 permit udp any any range 16383 16384 dial-peer voice 1 voip destination-pattern T session target ras ip qos dscp cs5 media ip qos dscp cs5 signaling Router#sh debug Generic ATM: ATM VC Bundle Events debugging is on ATM VC Bundle Errors debugging is on ATM VC Bundle INARP Events debugging is on ATM VC Bundle Adjacency Events debugging is on Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=57509t=57509 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
FW: Duplicate packets with same SEQ #'s... [7:53024]
Is it possible that you are doing a dump on a link that the packet must transverse to and fro to get to the destination. You stated that you did this dump off of one of your core switches. I'm assuming your spanning or port mirroring the port or vlan possibly. If these PC's are on separate networks..see what I'm saying. Well if you don't here goes. If you have a switch connected to a router using some kind of trunking capability(or internal router) and the user's are on separate VLAN/subnets. They must cross the router to get to each other. Thus when you do a dump you will see the same packet come across twice. If you have a protocol analyzer you should see the mac address change as it crosses the router. I only believe my theory to be true if the PC's are on separate sub networks. Hope this helps D -Original Message- From: Neil Desai [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: Re: Duplicate packets with same SEQ #'s... [7:53024] We have a similar situation in our network. We have proxy arp turned on and it is causing the same thing. Neil r34rv13wm1rr0r wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689614 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 294:343(49) ack 363 win 7380NBT Packet (DF) [tos 0x4] 11:18:04.718183 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 6762:6811(49) ack 8223 win 8397NBT Packet (DF) [tos 0x4] 11:18:04.718187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718188 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718423 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718424 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win
Re: Duplicate packets with same SEQ #'s... [7:53024]
The tcpdump is being run on a gig span port on the core 6509, the only vlan's the span encompasses is the Server VLAN's. The VLAN's are being spanned on both core switches, so I can see why in the intrusion database duplicates are showing up since both servers are seeing the same VLAN's. I wonder why when TCPDUMP is run on once switch it sees duplicates. Like I said, I can see why the ACID database sees two entries if both servers are set on the same spanned VLAN's, but it does explain why the duplicates are notice when tcpdump is running on only one Linux Server. The host that is running tcpdump is only using 1 gigabit NIC, so no chance of seeing the packets from another interface. I guess it isn't that big of a deal, I just want to find out why it is happening, the Security folks are a litle annoyed with getting two entries in the database every time. I will evaluate spanning-tree and what not, but it seems there is some deep rooted explanation for this. Thanks for all of your replies... keep 'em coming! Antonio - Original Message - From: Priscilla Oppenheimer To: Sent: Tuesday, September 10, 2002 4:36 PM Subject: RE: Duplicate packets with same SEQ #'s... [7:53024] Where are you running this TCPdump? It seems to be somewhere on the network where it sees every packet twice. It's not just SEQ#s that are repeating, but ACKs, etc. Could the host that is running TCPdump be multihomed? Obviously, in a functioning network, it would be pretty bizarre for any LAN or host to see the same packet twice. Spanning Tree and routing protocols should ensure that this doesn't happen. But there may be situations where this is normal, for a station that is just doing network management type tasks, for example. Priscilla r34rv13wm1rr0r wrote: This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45
RE: FW: Duplicate packets with same SEQ #'s... [7:53024]
Newell Ryan D SrA 18 CS/SCBT wrote: Is it possible that you are doing a dump on a link that the packet must transverse to and fro to get to the destination. That's a good point. I can't comprehend the actual design from what we've been told, but it could be perfectly normal for a packet to traverse a network segment twice. An old-fashioned example is two routers on a segment. A host on the segment is set for one of the routers to be the default gateway. The host sends a packet to that router. The router can't get there directly so sends the packet back out the same interface to the other router. The MAC addresses should change, as you say. The router should also send an ICMP Redirect. A more modern example is a one-armed router doing inter-VLAN forwarding of packets. Have no idea if this applies, but I'm glad you triggered this thinking about basic network behavior with common network topologies. Priscilla I'm assuming your spanning or port mirroring the port or vlan possibly. If these PC's are on separate networks..see what I'm saying. Well if you don't here goes. If you have a switch connected to a router using some kind of trunking capability(or internal router) and the user's are on separate VLAN/subnets. They must cross the router to get to each other. Thus when you do a dump you will see the same packet come across twice. If you have a protocol analyzer you should see the mac address change as it crosses the router. I only believe my theory to be true if the PC's are on separate sub networks. Hope this helps D -Original Message- From: Neil Desai [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: Re: Duplicate packets with same SEQ #'s... [7:53024] We have a similar situation in our network. We have proxy arp turned on and it is causing the same thing. Neil r34rv13wm1rr0r wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.6896
Duplicate packets with same SEQ #'s... [7:53024]
This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689614 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 294:343(49) ack 363 win 7380NBT Packet (DF) [tos 0x4] 11:18:04.718183 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 6762:6811(49) ack 8223 win 8397NBT Packet (DF) [tos 0x4] 11:18:04.718187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718188 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718423 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718424 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718425 172.X.240.220.6103 172.X.15.68.4720: . 2920:4380(1460) ack 1 win 16816 (DF) 11:18:04.718586 172.X.240.220.6103 172.X.15.68.4720: . 4380:5840(1460) ack 1 win 16816 (DF) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53024t=53024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Duplicate packets with same SEQ #'s... [7:53024]
Have you looked at your spanning-tree? I had something similar happen to me because of a malfunctioning gig port. I would have sworn I didn't have a loop, but it ended up being a port was sending that by all appearances was blocking. We found many instances of the same packet circling through our switches by using a sniffer. r34rv13wm1rr0r wrote: This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689614 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 294:343(49) ack 363 win 7380NBT Packet (DF) [tos 0x4] 11:18:04.718183 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 6762:6811(49) ack 8223 win 8397NBT Packet (DF) [tos 0x4] 11:18:04.718187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718188 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718423 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718424 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718425 172.X.240.220.6103 172.X.15.68.4720: . 2920:4380(1460) ack 1 win 16816 (DF) 11:18:04.718586 172.X.240.220.6103 172.X.15.68.4720: . 4380:5840(1460) ack 1 win 16816 (DF) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53027t=53024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Duplicate packets with same SEQ #'s... [7:53024]
Where are you running this TCPdump? It seems to be somewhere on the network where it sees every packet twice. It's not just SEQ#s that are repeating, but ACKs, etc. Could the host that is running TCPdump be multihomed? Obviously, in a functioning network, it would be pretty bizarre for any LAN or host to see the same packet twice. Spanning Tree and routing protocols should ensure that this doesn't happen. But there may be situations where this is normal, for a station that is just doing network management type tasks, for example. Priscilla r34rv13wm1rr0r wrote: This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689614 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 294:343(49) ack 363 win 7380NBT Packet (DF) [tos 0x4] 11:18:04.718183 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 6762:6811(49) ack 8223 win 8397NBT Packet (DF) [tos 0x4] 11:18:04.718187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718188 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718423 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718424 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718425 172.X.240.220.6103 172.X.15.68.4720: . 2920:4380(1460) ack 1 win 16816 (DF) 11:18:04.718586 172.X.240.220.6103 172.X.15.68.4720: . 4380:5840(1460) ack 1 win 16816 (DF) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53031t=53024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Duplicate packets with same SEQ #'s... [7:53024]
We have a similar situation in our network. We have proxy arp turned on and it is causing the same thing. Neil r34rv13wm1rr0r wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This is from a tcpdump off of one of my core switches. It appears that it is logging a duplicate packet with the same SEQ #. Does any one have any idea why this is occuring? Thanks, A 11:18:04.688408 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688409 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 1:65(64) ack 49 win 8320NBT Packet (DF) 11:18:04.688643 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 158405518:158405625(107) ack 1210141117 win 8608NBT Packet (DF) 11:18:04.688644 172.X.103.10.netbios-ssn 172.X.15.15.1503: P 0:107(107) ack 1 win 8608NBT Packet (DF) 11:18:04.688645 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.688646 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 65:119(54) ack 98 win 8271NBT Packet (DF) 11:18:04.63 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.65 X.X.6.3.http 172.X.14.50.1123: . ack 4294967295 win 8155 (DF) 11:18:04.66 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 3194256684:3194256844(160) ack 95965178 win 7515NBT Packet (DF) 11:18:04.67 172.23.27.10.3021 172.X.15.10.netbios-ssn: P 0:160(160) ack 1 win 7515NBT Packet (DF) 11:18:04.68 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.69 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 119:173(54) ack 147 win 8222NBT Packet (DF) 11:18:04.688890 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.688891 172.X.15.15.1503 172.X.103.10.netbios-ssn: P 1:161(160) ack 107 win 7996NBT Packet (DF) 11:18:04.689183 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689185 172.X.15.10.netbios-ssn 172.23.27.10.3021: P 1:129(128) ack 160 win 8138NBT Packet (DF) 11:18:04.689186 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 173:255(82) ack 196 win 8173NBT Packet (DF) 11:18:04.689188 172.X.15.151.ssh 172.X.53.186.1219: P 2849560709:2849560801(92) ack 2980294350 win 9648 (DF) [tos 0x10] 11:18:04.689189 172.X.15.151.ssh 172.X.53.186.1219: P 0:92(92) ack 1 win 9648 (DF) [tos 0x10] 11:18:04.689192 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689193 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 255:309(54) ack 245 win 8124NBT Packet (DF) 11:18:04.689608 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689609 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 309:363(54) ack 294 win 8075NBT Packet (DF) 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 4096314569 win 2144 11:18:04.689610 172.X.243.6.printer 172.X.240.10.723: . ack 1 win 2144 11:18:04.689611 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689612 172.X.53.186.1219 172.X.15.151.ssh: P 1:45(44) ack 92 win 16724 (DF) 11:18:04.689614 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 294:343(49) ack 363 win 7380NBT Packet (DF) [tos 0x4] 11:18:04.718183 172.X.61.103.1066 172.X.15.49.netbios-ssn: P 6762:6811(49) ack 8223 win 8397NBT Packet (DF) [tos 0x4] 11:18:04.718187 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718188 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8223:8287(64) ack 6811 win 7438NBT Packet (DF) 11:18:04.718423 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718424 172.X.15.49.netbios-ssn 172.X.61.103.1066: P 8287:8341(54) ack 6860 win 7389NBT Packet (DF) 11:18:04.718425 172.X.240.220.6103 172.X.15.68.4720: . 2920:4380(1460) ack 1 win 16816 (DF) 11:18:04.718586 172.X.240.220.6103 172.X.15.68.4720: . 4380:5840(1460) ack 1 win 16816 (DF) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=53059t=53024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
UDP packets [7:52931]
Hi, Since I didn't get reply for the earlier one, Sorry to resend it again: I am using a router 7500 with ATM interface to manage an ATM device.The management s/w is run from a Sun solaris 2.8 .Each of the packet size is on an average 160 bytes.The device can be configured for managing on LAN as well as on ATM.When the device is configured for managing in the LAN,everything goes fine and none of the UDP packets gets lost.But when the device is configured for managing in ATM I see lot of ICMP redirects come from 7500.The UDP packets doesn't even reach the device.Also I noticed that the maximum packet send to the device when managed on the LAN is 2.7KBytes/sec and when configured for managing on the ATM, the maximum packet send to the device is 2.1KBytes/sec. I am so confused after looking at the sniffer output. When Managed for ATM (The device configured for ATM): 1)why ICMP redirects occurs from the router 7500 which is one reason for the UDP loss. 2)I see sometimes BAD UDP checksum on the sniffer o/p from the device. 3)Why the maximum packets send from the management station is 2.1 KBytes/sec only which is less than when the device is configured for management on the LAN side? 4)Is there a way to avoid this on the router end?Some configuration changes??? 5)For the management application which is running on the solaris does it matter LAN management and ATM management?If not, why the difference in Maximumm packets send differs in both?If yes, anybody can explain how?? I appreciate if anybody can throw some light into this.Spending considerable amount of time to troubleshoot this . Thanks, GP __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=52931t=52931 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: 11050 dropping packets [7:49169]
I never see this problem on CSSs. I done some tests on HTTP1.0 and 1.1 one year ago using ap0405068b and it worked fine. What do you mean by 1.1 doesn't seem to send the full header info ? what info are missing ? I just took some traces of HTTP 1.1 traffic and header are like HTTP 1.0 (the big difference between 1.0 and 1.1 fr loadbalancers is that one TCP connection can be used for transferring many objects in 1.1. In 1.0, one object download = one TCP connection). BH a icrit dans le message de news: [EMAIL PROTECTED] Hi, Has anyone seen a problem with the 11050 load balancer dropping packets from http 1.1 browsers? Http 1.0 seem to work fine but 1.1 doesnt seem to send the full header info and the 11050 drops packets like mad. Software version 4.00 build 3 Hardware Major version: 02 Hardware Minor version: 0 Thanks! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=49895t=49169 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
11050 dropping packets [7:49169]
Hi, Has anyone seen a problem with the 11050 load balancer dropping packets from http 1.1 browsers? Http 1.0 seem to work fine but 1.1 doesnt seem to send the full header info and the 11050 drops packets like mad. Software version 4.00 build 3 Hardware Major version: 02 Hardware Minor version: 0 Thanks! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=49169t=49169 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
tftp packets [7:41018]
hi to all Our cisco 7100 router sends tftp read request packets to 255.255.255.255 frequently. There is nothing about tftp in configuration. Is there anybody has an idea what may caiuse this? thanks all... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41018t=41018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: tftp packets [7:41018]
this is known as configuration auto-loading to disable on a router use: no boot network no service config hope this helps Mark Semih \st|n wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... hi to all Our cisco 7100 router sends tftp read request packets to 255.255.255.255 frequently. There is nothing about tftp in configuration. Is there anybody has an idea what may caiuse this? thanks all... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41020t=41018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: tftp packets [7:41018]
thanks. it worked. Semih - Original Message - From: Mark Patrick To: Sent: Wednesday, April 10, 2002 3:14 PM Subject: Re: tftp packets [7:41018] this is known as configuration auto-loading to disable on a router use: no boot network no service config hope this helps Mark Semih \st|n wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... hi to all Our cisco 7100 router sends tftp read request packets to 255.255.255.255 frequently. There is nothing about tftp in configuration. Is there anybody has an idea what may caiuse this? thanks all... Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41035t=41018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: tftp packets [7:41018]
You should add the following line to your config: no service config Otherwise the router will try to automatically load its config from a server. If the router SLARPed (got its IP address from the other end), it tends to do service config even if you never told it to. Priscilla At 07:11 AM 4/10/02, Semih \st|n wrote: hi to all Our cisco 7100 router sends tftp read request packets to 255.255.255.255 frequently. There is nothing about tftp in configuration. Is there anybody has an idea what may caiuse this? thanks all... Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=41069t=41018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
parsing error for SNMP packets [7:38030]
Good Day All, I am having some problems retreiving SNMP information from one of my routers here. As long as I send an SNMP get to the IP address of the dialer interface, the router returns the required information. If I send the same SNMP get request to the Ethernet interface or the loopback interface, the request times out. I setup debug SNMP packets on the router and performed the SNMP get commands again to the router. The router sent the required information for the dialer interface and returned a parsing error' for both the ethernet interface and the loopback interface. Has anyone ever dealth with anything like this before? regards, amanda Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=38030t=38030 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Hello packets mcast or ucast in Multipoint networks? [7:35395]
Hi all, Here is the question that I have. In Routing TCP/IP vol 1 by Jeff Doyle - OSPF chapter pg 417 under P- MP paragraph - it says OSPF packets are mcast. On Pg 433, 1st paragraph, 4th line it says Hellos are ucast in Point to Multipoint networks. Can somebody share with their explanation? Thanks rajesh Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=35395t=35395 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Hello packets mcast or ucast in Multipoint networks? [7:35461]
Raj, This one comes straight from RFC 2328. The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10). The only packets not sent as unicasts are on broadcast networks; on these networks Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update. HTH, Elmer - Original Message - From: Rajesh Kumar To: Sent: Thursday, February 14, 2002 9:38 AM Subject: Hello packets mcast or ucast in Multipoint networks? [7:35395] Hi all, Here is the question that I have. In Routing TCP/IP vol 1 by Jeff Doyle - OSPF chapter pg 417 under P- MP paragraph - it says OSPF packets are mcast. On Pg 433, 1st paragraph, 4th line it says Hellos are ucast in Point to Multipoint networks. Can somebody share with their explanation? Thanks rajesh Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=35461t=35461 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CISCO PIX handling of RST packets [7:35474]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, During a recent tcpdump analysis, we noticed that the RST packets has the exact same packet sizes as the inbound packets that were denied. Why is this so? What happens if I send large spoofed packets to the PIX and they get denied. Will the victim client (of the IP address I spoofed) end up getting DoS'ed by large RST packets from the PIX? Thanks in advance. Regards. -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBPGymrqKjNF+pKI8PEQKY5gCgjGzgZi/yeW3XPBTgRBputurg24gAn0vy i3Mdns+wFnuFzoCBArlWNZ7C =MVNg -END PGP SIGNATURE- Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=35474t=35474 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DDR works but doesn't pass packets [7:28605]
I seem to think its a route issue. IF u see on the first router, you have a default pointing outside, fine. But on the second one you have a router to 192.168.100.x now, when u ping from remote router, it will use the ip address of the BRI as the source and there doesnt seem to be a return path on the Central Site router. Nick Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=28790t=28605 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
DDR works but doesn't pass packets [7:28605]
Hello everyone, it's been a while, good to be on the list again. Studying for my BCRAN, and have quick question for you. My lab for testing DDR is working. . . almost. When I try to ping or telnet from a PC to a terminal server, going across the ISDN DDR link: 1. the ISDN line comes up, connects, authenticates with CHAP (I did debug ppp auth, and there was CHAP SUCCESS), and stays up, so that much works, but 2. I can't get ping replies or telnet through! PC is 192.168.201.101/24, connected to the remote router. Terminal server is 192.168.200.100/24. Any ideas are appreciated. Thanks! Here are the configs: REMOTE SITE: RemoteSite1#SH RUN Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname RemoteSite1 ! ! username CentralSite password 7 05080F1C2243 ip subnet-zero isdn switch-type basic-ni ! ! ! interface Ethernet0 ip address 192.168.201.100 255.255.255.0 no ip directed-broadcast ! interface Serial0 no ip address no ip directed-broadcast shutdown no fair-queue service-module 56k clock source line service-module 56k network-type dds ! interface BRI0 ip address 192.168.10.2 255.255.255.252 no ip directed-broadcast encapsulation ppp dialer map ip 192.168.10.1 name CentralSite 6024384982 dialer-group 1 isdn switch-type basic-ni isdn spid1 6024384633 isdn spid2 6024384701 ppp authentication chap ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.1 ! dialer-list 1 protocol ip permit ! line con 0 transport input none line vty 0 4 ! end RemoteSite1# CENTRAL SITE: CentralSite#SH RUN Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname CentralSite ! ! username RemoteSite1 password 7 070C285F4D06 ip subnet-zero no ip domain-lookup isdn switch-type basic-ni ! ! ! interface Ethernet0 ip address 192.168.200.1 255.255.255.0 no ip directed-broadcast ! interface Serial0 no ip address no ip directed-broadcast shutdown no fair-queue service-module 56k clock source line service-module 56k network-type dds ! interface BRI0 no ip address no ip directed-broadcast encapsulation ppp dialer pool-member 1 isdn switch-type basic-ni isdn spid1 6024384982 isdn spid2 6024384993 ! interface Dialer1 ip address 192.168.10.1 255.255.255.252 no ip directed-broadcast encapsulation ppp dialer remote-name RemoteSite1 dialer pool 1 dialer-group 10 ppp authentication chap ! ip classless ip route 192.168.201.100 255.255.255.255 Dialer1 ! access-list 10 permit 192.168.201.0 0.0.0.255 access-list 10 permit any dialer-list 1 protocol ip list 10 ! line con 0 transport input none line vty 0 4 ! end CentralSite# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=28605t=28605 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: DDR works but doesn't pass packets [7:28605]
maybe because you're referring to the wrong dialer list in the dialer1 interface on the CentralSite router? I couldn't find dialer-list 10 anywhere in that config. And just as an 'oh by the way', your access-list 10 does nothing except use CPU cycles. - Original Message - From: Sean Wolfe To: Sent: Sunday, December 09, 2001 2:23 PM Subject: DDR works but doesn't pass packets [7:28605] Hello everyone, it's been a while, good to be on the list again. Studying for my BCRAN, and have quick question for you. My lab for testing DDR is working. . . almost. When I try to ping or telnet from a PC to a terminal server, going across the ISDN DDR link: 1. the ISDN line comes up, connects, authenticates with CHAP (I did debug ppp auth, and there was CHAP SUCCESS), and stays up, so that much works, but 2. I can't get ping replies or telnet through! PC is 192.168.201.101/24, connected to the remote router. Terminal server is 192.168.200.100/24. Any ideas are appreciated. Thanks! Here are the configs: REMOTE SITE: RemoteSite1#SH RUN Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname RemoteSite1 ! ! username CentralSite password 7 05080F1C2243 ip subnet-zero isdn switch-type basic-ni ! ! ! interface Ethernet0 ip address 192.168.201.100 255.255.255.0 no ip directed-broadcast ! interface Serial0 no ip address no ip directed-broadcast shutdown no fair-queue service-module 56k clock source line service-module 56k network-type dds ! interface BRI0 ip address 192.168.10.2 255.255.255.252 no ip directed-broadcast encapsulation ppp dialer map ip 192.168.10.1 name CentralSite 6024384982 dialer-group 1 isdn switch-type basic-ni isdn spid1 6024384633 isdn spid2 6024384701 ppp authentication chap ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.1 ! dialer-list 1 protocol ip permit ! line con 0 transport input none line vty 0 4 ! end RemoteSite1# CENTRAL SITE: CentralSite#SH RUN Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname CentralSite ! ! username RemoteSite1 password 7 070C285F4D06 ip subnet-zero no ip domain-lookup isdn switch-type basic-ni ! ! ! interface Ethernet0 ip address 192.168.200.1 255.255.255.0 no ip directed-broadcast ! interface Serial0 no ip address no ip directed-broadcast shutdown no fair-queue service-module 56k clock source line service-module 56k network-type dds ! interface BRI0 no ip address no ip directed-broadcast encapsulation ppp dialer pool-member 1 isdn switch-type basic-ni isdn spid1 6024384982 isdn spid2 6024384993 ! interface Dialer1 ip address 192.168.10.1 255.255.255.252 no ip directed-broadcast encapsulation ppp dialer remote-name RemoteSite1 dialer pool 1 dialer-group 10 ppp authentication chap ! ip classless ip route 192.168.201.100 255.255.255.255 Dialer1 ! access-list 10 permit 192.168.201.0 0.0.0.255 access-list 10 permit any dialer-list 1 protocol ip list 10 ! line con 0 transport input none line vty 0 4 ! end CentralSite# _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=28618t=28605 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF packets, point-to-multipoint [7:20115]
At 01:56 AM 9/17/01, Chuck Larrieu wrote: without repeating my private response to your private mail, Please do repeat it!? ;-) Seriously, is the BSCN statement wrong?? bcause the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighbors dynamically, and statically configuring neighbors is not required. Priscilla on NMBA networks, one usually configures OSPF neighbors. The whole NMBA issue is complex. There is the frame relay configuration, and then there is the OSPF configuration on top of that. You can have point to multipoint frame relay interfaces connected to physical, or point-to-point interfaces on the distant end. Inverse arp maps a remote IP address to the associated other side dlci. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Lee Sent: Sunday, September 16, 2001 7:05 PM To: [EMAIL PROTECTED] Subject: Re: OSPF packets, point-to-multipoint [7:20115] Still do not understand, Building Scalable Cisco Networks, CiscoPress, page 123 However,bcause the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighbors dynamically, and statically configuring neighbors is not required. Routing TCP/IP, Vol. 1, page 433 On broadcast and point-to-point network types, hellos are multicast to AllSPFRouters (224.0.0.5). On NBMA, point-to-multipoint, and virtual link network types, hello are unicast to individual neighbors. The implication of unicasting is that router must first learn of the existence of its neighbors either through manual configuration or an underlying mechanism such as Inverse ARP. What have I missed ? Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20193t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF packets, point-to-multipoint [7:20115]
Group, Can someone help me to understand or point me to a link so that I can get a definitive answer. Thanks. Routing TCP/IP, Vol. 1, Jeff Doyle : (a) Page # 417, 'Point-to-multipoint networks are a special configuration .. because the network are seen as point-to-point links, OSPF packets are multicast'. (b) Page # 451, 'On point-to-multipoint and virtual link networks, updates are unicasted to the interface addresses of adjacent neighbors'. (c) Page # 561, 'The OSPF point-to-multipoint network type treats the underlying as a collection of point-to-point links ..., and OSPF packets are multicast to the neighbor.' Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20115t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF packets, point-to-multipoint [7:20115]
Welcome to the world of OSPF. I trust you are prepared for a long and rewarding journey through the maze of possibilities. Much OSPF study is best done with a router at hand so you can set up various things and look and see how the protocol behaves. page 417: taken out of context. If you check how OSPF defaults on an NMBA interface or multipoint subinterface you will find the default is NMBA Serial2/3.1 is down, line protocol is down Internet Address 99.99.99.99/24, Area 0 Process ID 1000, Router ID 192.168.1.1, Network Type NON_BROADCAST, Cost: 48 Transmit Delay is 1 sec, State DOWN, Priority 1 No designated router on this network No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 one can change this interface to an OSPF point-to-multipoint by using the interface command ip ospf network point-to-multipoint, at which time you get Serial2/3.1 is down, line protocol is down Internet Address 99.99.99.99/24, Area 0 Process ID 1000, Router ID 192.168.1.1, Network Type POINT_TO_MULTIPOINT, Cost : 48 Transmit Delay is 1 sec, State DOWN, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 if you check RFC 2328, you will find that behaviour in terms of LSA's is different for both of these cases. As are the configuration contortions you must now perform. a couple of more quotes from the RFC are found below best wishes in your OSPF pursuits Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Lee Sent: Sunday, September 16, 2001 9:30 AM To: [EMAIL PROTECTED] Subject: Re: OSPF packets, point-to-multipoint [7:20115] Group, Can someone help me to understand or point me to a link so that I can get a definitive answer. Thanks. Routing TCP/IP, Vol. 1, Jeff Doyle : (a) Page # 417, 'Point-to-multipoint networks are a special configuration .. because the network are seen as point-to-point links, OSPF packets are multicast'. (b) Page # 451, 'On point-to-multipoint and virtual link networks, updates are unicasted to the interface addresses of adjacent neighbors'. (c) Page # 561, 'The OSPF point-to-multipoint network type treats the underlying as a collection of point-to-point links ..., and OSPF packets are multicast to the neighbor.' -- CL inserted: From the RFC: 12.4.1.4. Describing Point-to-MultiPoint interfaces For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows: o A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0x (indicating a host route), and cost set to 0. o For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to- point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost. And also: The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10). The only packets not sent as unicasts are on broadcast networks; on these networks Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20117t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF packets, point-to-multipoint [7:20115]
Still do not understand, Building Scalable Cisco Networks, CiscoPress, page 123 However,bcause the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighbors dynamically, and statically configuring neighbors is not required. Routing TCP/IP, Vol. 1, page 433 On broadcast and point-to-point network types, hellos are multicast to AllSPFRouters (224.0.0.5). On NBMA, point-to-multipoint, and virtual link network types, hello are unicast to individual neighbors. The implication of unicasting is that router must first learn of the existence of its neighbors either through manual configuration or an underlying mechanism such as Inverse ARP. What have I missed ? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20132t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF packets, point-to-multipoint [7:20115]
Hi Alex In point-to-multipoint network, a DR will be elected and the DR will multicast the message to all the ospf routers. Where else in point-to-point network, there are no DR selection and thats why either we rely on the inverse arp or manually configure it. William Alex Lee wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Still do not understand, Building Scalable Cisco Networks, CiscoPress, page 123 However,bcause the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighbors dynamically, and statically configuring neighbors is not required. Routing TCP/IP, Vol. 1, page 433 On broadcast and point-to-point network types, hellos are multicast to AllSPFRouters (224.0.0.5). On NBMA, point-to-multipoint, and virtual link network types, hello are unicast to individual neighbors. The implication of unicasting is that router must first learn of the existence of its neighbors either through manual configuration or an underlying mechanism such as Inverse ARP. What have I missed ? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20138t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF packets, point-to-multipoint [7:20115]
without repeating my private response to your private mail, on NMBA networks, one usually configures OSPF neighbors. The whole NMBA issue is complex. There is the frame relay configuration, and then there is the OSPF configuration on top of that. You can have point to multipoint frame relay interfaces connected to physical, or point-to-point interfaces on the distant end. Inverse arp maps a remote IP address to the associated other side dlci. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Lee Sent: Sunday, September 16, 2001 7:05 PM To: [EMAIL PROTECTED] Subject: Re: OSPF packets, point-to-multipoint [7:20115] Still do not understand, Building Scalable Cisco Networks, CiscoPress, page 123 However,bcause the point-to-multipoint mode treats the network as a collection of point-to-point links, multicast hello packets discover neighbors dynamically, and statically configuring neighbors is not required. Routing TCP/IP, Vol. 1, page 433 On broadcast and point-to-point network types, hellos are multicast to AllSPFRouters (224.0.0.5). On NBMA, point-to-multipoint, and virtual link network types, hello are unicast to individual neighbors. The implication of unicasting is that router must first learn of the existence of its neighbors either through manual configuration or an underlying mechanism such as Inverse ARP. What have I missed ? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=20144t=20115 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Ip precedence of GRE packets [7:19125]
Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19125t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? A very interesting problem. Without researching it, I'd be inclined to say no on a Cisco router, unless you terminate the tunnel at each router hop, and then set precedence with a route map as you re-encapsulate it. In formal terms, you have to define the desired per-hop behavior (PHB) at each hop rather than end-to-end. There might be a really kludgy way to do it with BGP QoS Policy Propagation, if the destination addresses were different. You MIGHT be able to do it on a Bay/Nortel RS router, because it does allow the equivalent of access lists on pure byte strings. I _think_ the string match is long enough to reach the second IP header. Even if I could, I don't think I would. I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. But here's where I start to question. Why do you consider two tunnels to be suboptimal? I'd say the general consensus among MPLS traffic engineering people is to associate a priority with a tunnel, merge different flows of the same priority onto what is now called a traffic trunk, then put the multipriority traffic back together at the egress. It's MUCH easier to do traffic engineering when the tunnel/trunk has a single priority. Remember that traffic engineering implies the reservation of bandwidth. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19131t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
Chris, I've tested that 4-5 months ago, on 2621 with 12.1T. TOS field is propagated from encapsulated packets into TOS of GRE packets. The same happens with IPSec tunnels; TOS from encrypted packets is copied into IPSec headers. Regards, Sasa Chris Read wrote: Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19132t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
I think it is possible to have the GRE tunnel packets have the same IP precedence (or DSCP) as the encapsulated packets. I happened to run into a document that talked about this for VPNs that are built on GRE tunnels. Check this out: http://www.cisco.com/warp/public/cc/pd/iosw/iore/iomjre12/prodlit/816_pb.htm Search for GRE Precedence in that document. It might do what you're talking about. I think there are some other documents that discuss this also if you search at Cisco's site for IP Precedence or DSCP. Priscilla At 01:54 PM 9/8/01, Chris Read wrote: Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19150t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
need definations for Frames, Packets, Segments [7:18629]
Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18629t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: need definations for Frames, Packets, Segments [7:18629]
Frame = layer 2 packet format (ethernet for example) Packet = Layer 3 packet format (IP for example) Segment = Layer 4 packet format (TCP for example) Hope it helps Lionel At 12:20 PM 9/5/2001 -0400, [EMAIL PROTECTED] wrote: Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18638t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: need definations for Frames, Packets, Segments [7:18629]
Have you checked out Comer's Internetworking with TCP/IP?? Dave [EMAIL PROTECTED] wrote: Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you -- David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 Emotion should reflect reason not guide it Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18645t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: need definations for Frames, Packets, Segments [7:18629]
A lot of people use the term frame only when discussing a data-link-layer protocol data unit. The term packet is used only when discussing a network-layer protocol data unit. Many experts are loose with these terms, however. I'm working with an expert right now who doesn't bother with those definitions and uses the terms interchangeably. Segment, on the other hand, does have a specific meaning. It is the protocol data unit used by TCP. Priscilla At 12:20 PM 9/5/01, [EMAIL PROTECTED] wrote: Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18647t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: need definations for Frames, Packets, Segments [7:18629]
From what I understand, the term segment is used to describe a connection-oriented protocol at the Transport layer. The term datagram is used to describe a connectionless protocol at the Transport layer. Segment isn't specific to TCP - but rather all connection-oriented protocols that operate at the Transport layer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Wednesday, September 05, 2001 11:51 AM To: [EMAIL PROTECTED] Subject: Re: need definations for Frames, Packets, Segments [7:18629] A lot of people use the term frame only when discussing a data-link-layer protocol data unit. The term packet is used only when discussing a network-layer protocol data unit. Many experts are loose with these terms, however. I'm working with an expert right now who doesn't bother with those definitions and uses the terms interchangeably. Segment, on the other hand, does have a specific meaning. It is the protocol data unit used by TCP. Priscilla At 12:20 PM 9/5/01, [EMAIL PROTECTED] wrote: Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18688t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: need definations for Frames, Packets, Segments [7:18629]
At 02:51 PM 9/4/01, Leigh Anne Chisholm wrote: From what I understand, the term segment is used to describe a connection-oriented protocol at the Transport layer. The term datagram is used to describe a connectionless protocol at the Transport layer. Segment isn't specific to TCP - but rather all connection-oriented protocols that operate at the Transport layer. What are some other examples? AppleTalk Transaction Protocol (ATP) doesn't use the term segment. Neither does the AppleTalk Datastream Protocol (ADSP). They are both connection-oriented transport-layer protocols. NetWare Core Protocol (NCP) doesn't use segment. Neither does NetWare Sequenced Packet Exchange (SPX). Some explanations of the DECnet Network Services Protocol (NSP) do use segment. I can't remember for Banyan VINES! Maybe it does!? ;-) A quick look at Tannenbaum, who does a nice job with generic but technical descriptions of the layers, found no use of the word segment. He uses the OSI term Transport Protocol Data Unit (TPDU) and the term message. He doesn't even use segment when discussion TCP. Priscilla -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Wednesday, September 05, 2001 11:51 AM To: [EMAIL PROTECTED] Subject: Re: need definations for Frames, Packets, Segments [7:18629] A lot of people use the term frame only when discussing a data-link-layer protocol data unit. The term packet is used only when discussing a network-layer protocol data unit. Many experts are loose with these terms, however. I'm working with an expert right now who doesn't bother with those definitions and uses the terms interchangeably. Segment, on the other hand, does have a specific meaning. It is the protocol data unit used by TCP. Priscilla At 12:20 PM 9/5/01, [EMAIL PROTECTED] wrote: Hello All: I'm reading a lot of TCP/IP books and it seems no one author breaks down what a frame, packet or segment is. Can anyone define what these are or where I might find a site that explains? thank you Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18714t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: need definations for Frames, Packets, Segments [7:18629]
I can't remember for Banyan VINES! Maybe it does!? ;-) A quick look at Tannenbaum, who does a nice job with generic but technical descriptions of the layers, found no use of the word segment. He uses the OSI term Transport Protocol Data Unit (TPDU) and the term message. He doesn't even use segment when discussion TCP. From my discussion with the software engineers at Banyan, we used the term message. FYI: I use to work for Banyan. A good deal of the software engineers were hired by Microsoft. -- Through Complexity there is Simplicity, Through Simplicity there is Complexity David L. Blair - CCNP, CCNA, MCSE, CBE, A+, 3Wizard Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=18739t=18629 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17364]
Nice catch Dan :) Dan Faulk wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Since ping uses returning packets to work its those that are being blocked. Use a sniffer to see the process. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 26, 2001 11:16 PM To: [EMAIL PROTECTED] Subject: Re: Does access list work for router originated packets [7:17357] Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla,
Re: Does access list work for router originated packets [7:17365]
You can use a local policy route to get packets generated by the router to go through an ACL. Not as straight forward but... --- [EMAIL PROTECTED] wrote: Try making it an outbound access list only and see what happens. I haven't played around with it much myself, but I think that the outbound packets (originating from the router) will pass through the ACL OK. However I think your ping replies are being blocked on the way back - I'm not going to dig through manuals right now, but I think the ACL will be checked and acted on before the router works out that the ping reply is for itself. So I think (without testing myself) that Priscilla is only half correct with the statement ACLs on Router B do not apply to pings to and from Router B. - I think they apply to pings *to* router B but not *from* router B. JMcL John Hardman To: [EMAIL PROTECTED] Subject: Re: Does access list work for router Sent by: originated packets [7:17357] nobody@groups tudy.com 27/08/2001 02:16 pm Please respond to John Hardman Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was ob
Re: Does access list work for router originated packets [7:17376]
Yes, that's right! I have a configuration where I set up an ACL to completely filter telnet FROM and TO a certain network connected to it. I applied the ACL both inbound and outbound on an Ethernet interface. Done this, no one could telnet my router or any host on that Ethernet segment passing through my router. But I WAS ABLE to telnet any host on that segment as long as I originated the telnet from the router itself! From which you may conclude that an ACL doesn't affect packets originated on the router on which it is applied... Regards, Ednilson Rosa - Original Message - From: John Hardman To: Sent: Monday, August 27, 2001 1:16 AM Subject: Re: Does access list work for router originated packets [7:17357] Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.op
Re: Does access list work for router originated packets [7:17383]
Hi Yep sure enough! I knew I should have put the sniffer on the test, but it was late and I wanted to get to bed. Oh well, it was a good learning experience. -- John Hardman CCNP MCSE Jason Couch wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The access list is actually only blocking the icmp packets on the return path from the pinged router or host. The icmp packets sent outbound by the router sourcing the pings are actually allowed through the outbound access list. This can be seen by adding the log extension to your access list commands. Then you should see the following message: %SEC-6-IPACCESSLOGDP: list 100 denied icmp 192.168.10.50 - 192.168.10.20 (0/0), 1 packet The key is that you won't see the same log message for the outbound icmp packets. You can also run debug ip packet to see something similar to the following: IP: s=192.168.10.20 (local), d=192.168.10.50 (Ethernet0), len 100, sending ICMP type=8, code=0 IP: s=192.168.10.50 (Ethernet0), d=192.168.10.20 , len 100, access denied ICMP type=0, code=0 The outbound packets were sent, but the return packets were access denied. Hence you get: C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . because the entire ping path consists of both the forwarding AND the return path. HTH, Jason John Hardman wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings
Re: Does access list work for router originated packets [7:17389]
On Mon, 27 Aug 2001, John Hardman wrote: Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. Right, the packets leaving the router are not blocked, they are sourced from the router and bypass the ACL. The reply packets are blocked however, they are not sourced from the router. --- I'm buying / selling used CISCO gear!! email me for a quote Brian Feeny, CCIE #8036 Netjam, LLC [EMAIL PROTECTED] http://www.netjam.net VISA/MC/AMEX/COD phone: 318-212-0245 30 day warranty fax: 318-212-0246 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17389t=17389 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Does access list work for router originated packets [7:17406]
technically, the access-list applies only to packets that have passed through the routing process. this all gets down to understanding the difference between the routing / forwarding process versus the router architecture process and how packets get from here to there. let's hope I word this correctly, because it is a bit complex, and subject to misunderstanding. 1) case for inbound - a router receives a packet on an interface, checks the headers against any inbound access-list on that interface, accepts or denies the packet based on that list, then places the packet into the forwarding process 2) case for outbound - forwarding process determines the outbound interface, checks for the existence of an access-list outbound on that interface, processes the packet headers against that list, and if it passes, places the packet into the interface buffer for forwarding. 3) locally originated packet ( router doing something, for example ping, or routing protocol update ) router creates the packet, places it directly into the interface buffer for processing. local ping has a function which allows one to create a packet, and send that packet through the forwarding processes, which in turn forces that packet to follow one of the rules above. confused? hope this helped a little. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brian Sent: Monday, August 27, 2001 7:52 AM To: [EMAIL PROTECTED] Subject: Re: Does access list work for router originated packets [7:17389] On Mon, 27 Aug 2001, John Hardman wrote: Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. Right, the packets leaving the router are not blocked, they are sourced from the router and bypass the ACL. The reply packets are blocked however, they are not sourced from the router. --- I'm buying / selling used CISCO gear!! email me for a quote Brian Feeny, CCIE #8036 Netjam, LLC [EMAIL PROTECTED] http://www.netjam.net VISA/MC/AMEX/COD phone: 318-212-0245 30 day warranty fax: 318-212-0246 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17406t=17406 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17413]
Well, I said I couldn't remember under exactly what situations it happens!? And, I understand Brad's comment now. He thought I was saying of course not to his comment. I would never say that to a CCIE. ;-) I was saying of course not to his question are you saying Sorry, I'm in such a rush. Priscilla At 12:16 AM 8/27/01, John Hardman wrote: Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the rout
Re: Does access list work for router originated packets [7:17416]
At 08:38 AM 8/27/01, Ednilson Rosa wrote: Yes, that's right! I have a configuration where I set up an ACL to completely filter telnet FROM and TO a certain network connected to it. I applied the ACL both inbound and outbound on an Ethernet interface. Done this, no one could telnet my router or any host on that Ethernet segment passing through my router. But I WAS ABLE to telnet any host on that segment as long as I originated the telnet from the router itself! Ah hah! ;-) This is the type of anomaly that I'm talking about. I know I need to test it, but I don't have time right now It sounds like the bottom line is that output traffic from the router itself does not actually go through the ACL. Pings may still fail, however, if the Ping reply does go through an ACL that blocks it. Telnet from the router does not go through the ACL either. The replies may get through, depending on the ACL, as Ednilson describes below. In the classroom, our students get confused by this. They set up an ACL and test from the router where the ACL is configured and the ACL doesn't block traffic as expected. If I'm still off base, just let me know. I don't mind at all! ;-) Priscilla From which you may conclude that an ACL doesn't affect packets originated on the router on which it is applied... Regards, Ednilson Rosa - Original Message - From: John Hardman To: Sent: Monday, August 27, 2001 1:16 AM Subject: Re: Does access list work for router originated packets [7:17357] Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's wha
Re: Does access list work for router originated packets [7:17485]
Priscilla, This is NOT a anomaly !! This is well documented behavior. In fact, in ICND course, this is the first thing that we highlighted when we started discussing ACL... ACL does not act on the packets that originate in the same router as where the ACL is defined. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:38 AM 8/27/01, Ednilson Rosa wrote: Yes, that's right! I have a configuration where I set up an ACL to completely filter telnet FROM and TO a certain network connected to it. I applied the ACL both inbound and outbound on an Ethernet interface. Done this, no one could telnet my router or any host on that Ethernet segment passing through my router. But I WAS ABLE to telnet any host on that segment as long as I originated the telnet from the router itself! Ah hah! ;-) This is the type of anomaly that I'm talking about. I know I need to test it, but I don't have time right now It sounds like the bottom line is that output traffic from the router itself does not actually go through the ACL. Pings may still fail, however, if the Ping reply does go through an ACL that blocks it. Telnet from the router does not go through the ACL either. The replies may get through, depending on the ACL, as Ednilson describes below. In the classroom, our students get confused by this. They set up an ACL and test from the router where the ACL is configured and the ACL doesn't block traffic as expected. If I'm still off base, just let me know. I don't mind at all! ;-) Priscilla From which you may conclude that an ACL doesn't affect packets originated on the router on which it is applied... Regards, Ednilson Rosa - Original Message - From: John Hardman To: Sent: Monday, August 27, 2001 1:16 AM Subject: Re: Does access list work for router originated packets [7:17357] Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PR
Does access list work for router originated packets [7:17335]
Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17335t=17335 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17339]
Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17339t=17339 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17341]
At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17341t=17341 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17344]
Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17344t=17344 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17346]
At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscilla -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17346t=17346 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17349]
Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscilla -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17349t=17349 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17353]
I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscilla -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17353t=17353 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Does access list work for router originated packets [7:17357]
Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscilla -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will f
RE: Does access list work for router originated packets [7:17359]
Since ping uses returning packets to work its those that are being blocked. Use a sniffer to see the process. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 26, 2001 11:16 PM To: [EMAIL PROTECTED] Subject: Re: Does access list work for router originated packets [7:17357] Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscill
Re: Does access list work for router originated packets [7:17360]
The access list is actually only blocking the icmp packets on the return path from the pinged router or host. The icmp packets sent outbound by the router sourcing the pings are actually allowed through the outbound access list. This can be seen by adding the log extension to your access list commands. Then you should see the following message: %SEC-6-IPACCESSLOGDP: list 100 denied icmp 192.168.10.50 - 192.168.10.20 (0/0), 1 packet The key is that you won't see the same log message for the outbound icmp packets. You can also run debug ip packet to see something similar to the following: IP: s=192.168.10.20 (local), d=192.168.10.50 (Ethernet0), len 100, sending ICMP type=8, code=0 IP: s=192.168.10.50 (Ethernet0), d=192.168.10.20 , len 100, access denied ICMP type=0, code=0 The outbound packets were sent, but the return packets were access denied. Hence you get: C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . because the entire ping path consists of both the forwarding AND the return path. HTH, Jason John Hardman wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial b
Re: Does access list work for router originated packets [7:17361]
Try making it an outbound access list only and see what happens. I haven't played around with it much myself, but I think that the outbound packets (originating from the router) will pass through the ACL OK. However I think your ping replies are being blocked on the way back - I'm not going to dig through manuals right now, but I think the ACL will be checked and acted on before the router works out that the ping reply is for itself. So I think (without testing myself) that Priscilla is only half correct with the statement ACLs on Router B do not apply to pings to and from Router B. - I think they apply to pings *to* router B but not *from* router B. JMcL John Hardman To: [EMAIL PROTECTED] Subject: Re: Does access list work for router Sent by: originated packets [7:17357] nobody@groups tudy.com 27/08/2001 02:16 pm Please respond to John Hardman Hi I can't believe I am challenging Priscilla! I just tried what you are talking about, i.e. that the ACL on the router does not effect the traffic generated by the router it's self. I created an extended ACL to block all ICMP traffic and applied it to E0 as both IN and OUT. Before appling the ACL I can ping just fine to any host on the network and any host on the network can ping the router. After Appling the ACL I am not able to ping from the router, or to the router. I am running 11.1 IOS, maybe it would yield different results with a different IOS version. What IOS and platform did you see this behavior? Here's my config. Windoze PC 192.168.10.50 --- E0 Router2 192.168.10.20 RedHat PC 192.168.10.2 -Router config-- Current configuration: ! version 11.1 service udp-small-servers service tcp-small-servers ! hostname C2501-R2 ! enable secret 5 XXX enable password none ! ip subnet-zero ! interface Ethernet0 ip address 192.168.10.20 255.255.255.0 ip access-group 100 in ip access-group 100 out no ip mroute-cache no ip route-cache ! interface Serial0 ip address 192.168.50.1 255.255.255.252 no ip mroute-cache encapsulation ppp no ip route-cache ! interface Serial1 no ip address no ip mroute-cache no ip route-cache shutdown ! ip classless logging buffered access-list 100 deny icmp any any access-list 100 permit ip any any ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password login ! end ---Router Config-- ---Ping results- C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: . Success rate is 0 percent (0/5) C2501-R2#conf t Enter configuration commands, one per line. End with CNTL/Z. C2501-R2(config)#int e0 C2501-R2(config-if)#no ip access-group 100 in C2501-R2(config-if)#no ip access-group 100 out C2501-R2(config-if)#^Z C2501-R2# %SYS-5-CONFIG_I: Configured from console by console C2501-R2#ping 192.168.10.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 192.168.10.50, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms C2501-R2# Windoze Ping with ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Reply from 192.168.10.20: Destination net unreachable. Ping statistics for 192.168.10.20: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Windoze Ping without ACL C:\ping 192.168.10.20 Pinging 192.168.10.20 with 32 bytes of data: Reply from 192.168.10.20: bytes=32 time wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM
Re: Does access list work for router originated packets [7:17363]
BTW, If you do an extended ping and source the ping from an interface that is not connected in the path to the destination the ACL will filter the packet. Lance Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I know it's not what you said. What you said was obvious. I guess it comes about because I said to test with end devices. Router A is acting like an end device in your example. I should have been more clear. What is not obvious is that ACLs on Router B do not apply to pings to and from Router B. Every newbie has probably been bitten by that one, especially in simple labs. Priscilla At 09:42 PM 8/26/01, Brad Ellis wrote: Priscilla, that's not what I said. Here's what I said: ...pings sent by one router will not be filtered by another router? Hence my diagram for further explanation: Router A -=- Router B -=- Device A (-=- can be ethernet x-over, serial back-to-back, etc) An ACL is applied on Router B's interface (applied inbound) that is connected to Router A. What I originally said, and continue to say, is that Router B will most certainly block packets (pings or whatever) coming from Router A...and it is irrelevant if Router A is a router or a host device. The ACL on Router B doesnt care if the device sending packets is a router or an end host device! If Router B was initiating the ping and Router B had the ACL applied, that would be a different story. ttyl, -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 08:06 PM 8/26/01, Brad Ellis wrote: Priscilla, Are you saying that pings sent by one router will not be filtered by another router? I beg to differ. Of course not. Pings sent by the router where the ACL is configured are not affected by the ACL. Try it. Priscilla -Brad Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 06:26 PM 8/26/01, Brad Ellis wrote: Sami, You'll need to give more info than that. The router does not care if the packets are originated from a host or another router. It will filter packets based on packet information, ie, source address, destination address, port #... This filtering happens as part of the packet-forwarding process. Packets sent by the router (such as pings) may not go through this process. Sorry that I don't have the details, but I have run into surprising results in a lab environment when testing access lists from a router. You need to test them from end hosts. I can't believe I'm challenging a CCIE, ;-) but I was afraid nobody else would, and I think the question bears more research. Priscilla Are you saying the router wont filter packets originated from the router itself? How are your access-lists applied? Inbound or Outbound? What are you trying to filter? Explain your situation a little better, and include your access-list if you so desire. -Brad Ellis CCIE#5796 [EMAIL PROTECTED] used Cisco: www.optsys.net sami natour wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi All , When I made standard access list I discoverd that it prevented packets originated form PC's and host but not packets originated from other routers.Any idea why this will happen. Best Regards , sami , __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17363t=17363 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Packets per second [7:17005]
Does anyone know of any URL's or have any info on the paket budgets (pps) of all of the router range. Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17005t=17005 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Packets per second [7:17005]
I don't know all of them, but there is definitly info out there on some routers, is there any particular router your specifically wanting this data for? If you search the net or cisco.com for pps you can turn up some stuff. Brian On Thu, 23 Aug 2001, Burnham, Chris wrote: Does anyone know of any URL's or have any info on the paket budgets (pps) of all of the router range. Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] I'm buying / selling used CISCO gear!! email me for a quote Brian Feeny, CCIE #8036 Scarlett Parria [EMAIL PROTECTED] [EMAIL PROTECTED] 318-213-4709 318-213-4701 Netjam, LLC http://www.netjam.net 333 Texas St. VISA/MC/AMEX/COD Suite 140130 day warranty Shreveport, LA 71101 Cisco Channel Partner toll free: 866-2NETJAM phone: 318-212-0245 fax: 318-212-0246 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=17076t=17005 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Frame Relay acceptable DE packets [7:9746]
Michael, My comments are inline with **: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael L. Williams Sent: Monday, June 25, 2001 9:02 PM To: [EMAIL PROTECTED] Subject: Re: Frame Relay acceptable DE packets [7:9746] Kent. I have some questions they're inline Kent Hundley wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Symon, Unfortunately, its not as simple as looking at the DE packets. Simply looking at DE packets alone doesn't tell you anything really. The reason is that if the FR cloud doesn't experience congestion, those DE packets will get there just as well as the non-DE packets. Some carriers encourage their customers to use 0K CIR because we don't oversubscribe our network, so _all_ packets are marked DE. (Sprint used to do this, don't know if they still do or not) This is good.. I often heard that people would suggest 0 CIR so that they could oversubscribe the #*$ out of their network =) Then when people's traffic didn't go through they could go well we agreed to carry 0 ** Can't speak to that, the only carrier I have seen that recommended 0 CIR is ** Sprint, and it seemed to work fairly well at the time, this is circa 1997. ** They always claimed that they didn't over-subscribe they're network, so no ** reason to pay for CIR. Course, they're pricing for 0 CIR was inline with buying ** CIR from other carriers, so in the end from a cost point it was a bit of a ** wash. If you see the FECN's spike without a corresponding spike in the DE, that means your provider is experiencing congestion, but its on a backbone link and not your link. This means the provider's links are over-subscribed and your packets are likely getting dropped without being marked DE. If this happens, and you sniff both sides and show that you're sending more than you're receiving (i.e. you prove that you have packets being lost without being marked DE), isn't that a violation of your CIR agreement (assuming it's 0)? Since nothing should get marked DE except for packets over CIR, I can see how the logic makes sense, but does this happen often? ** Yes, and no. It depends on how the carriers SLA's are written. A lot of ** SLA's are written such that you could lose quite a bit of traffic for very ** short periods of time and they would still be well within their SLA's. For ** example, if they guarantee %99.99 packet delivery and you transfer 1 Terabyte ** of data per month, they could still drop 10 Mbytes of traffic, which could ** cause problems depending on how much was dropped in a given period. ** CIR is guaranteed only if the subscriber is not over-subscribed, but even ** then if the carrier has an outage its probable that they will be ** over-subscribed for the duration of the outage. When the bits fill the ** queues, a switch must drop traffic, DE or not. ** ** IME, you usually only see consistent congestion on international links. ** Due to cost, it seems that every carrier is over-subscribed on the ** international links and some even mark every packet going across the link ** as DE regardless of CIR. (yes, I've seen it happen) This sort of thing ** is obviously not in keeping with the spirit of the CIR agreement, but again ** one needs to read SLA contracts very carefully as there are usually a lot ** of weasel words that benefit the carrier. ** ** In practice, FR seems to continue to work well and be cost effective, but ** it needs to be understood that sometimes packets will get dropped even if ** you don't exceed CIR. If this happens consistently, its definitely an issue ** to take up with the carrier. With the exception of outages, its definitely ** violating the spirit of agreements for a provider to oversubscribe their CIR. ** ** Regards, ** Kent Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10091t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Frame Relay acceptable DE packets [7:10095]
Michael, My comments are inline with **: -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]]On Behalf Of Michael L. Williams Sent: Monday, June 25, 2001 9:02 PM To: [EMAIL PROTECTED] Subject: Re: Frame Relay acceptable DE packets [7:9746] Kent. I have some questions they're inline Kent Hundley wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Symon, Unfortunately, its not as simple as looking at the DE packets. Simply looking at DE packets alone doesn't tell you anything really. The reason is that if the FR cloud doesn't experience congestion, those DE packets will get there just as well as the non-DE packets. Some carriers encourage their customers to use 0K CIR because we don't oversubscribe our network, so _all_ packets are marked DE. (Sprint used to do this, don't know if they still do or not) This is good.. I often heard that people would suggest 0 CIR so that they could oversubscribe the #*$ out of their network =) Then when people's traffic didn't go through they could go well we agreed to carry 0 ** Can't speak to that, the only carrier I have seen that recommended 0 CIR is ** Sprint, and it seemed to work fairly well at the time, this is circa 1997. ** They always claimed that they didn't over-subscribe they're network, so no ** reason to pay for CIR. Course, they're pricing for 0 CIR was inline with buying ** CIR from other carriers, so in the end from a cost point it was a bit of a ** wash. If you see the FECN's spike without a corresponding spike in the DE, that means your provider is experiencing congestion, but its on a backbone link and not your link. This means the provider's links are over-subscribed and your packets are likely getting dropped without being marked DE. If this happens, and you sniff both sides and show that you're sending more than you're receiving (i.e. you prove that you have packets being lost without being marked DE), isn't that a violation of your CIR agreement (assuming it's 0)? Since nothing should get marked DE except for packets over CIR, I can see how the logic makes sense, but does this happen often? ** Yes, and no. It depends on how the carriers SLA's are written. A lot of ** SLA's are written such that you could lose quite a bit of traffic for very ** short periods of time and they would still be well within their SLA's. For ** example, if they guarantee %99.99 packet delivery and you transfer 1 Terabyte ** of data per month, they could still drop 10 Mbytes of traffic, which could ** cause problems depending on how much was dropped in a given period. ** CIR is guaranteed only if the subscriber is not over-subscribed, but even ** then if the carrier has an outage its probable that they will be ** over-subscribed for the duration of the outage. When the bits fill the ** queues, a switch must drop traffic, DE or not. ** ** IME, you usually only see consistent congestion on international links. ** Due to cost, it seems that every carrier is over-subscribed on the ** international links and some even mark every packet going across the link ** as DE regardless of CIR. (yes, I've seen it happen) This sort of thing ** is obviously not in keeping with the spirit of the CIR agreement, but again ** one needs to read SLA contracts very carefully as there are usually a lot ** of weasel words that benefit the carrier. ** ** In practice, FR seems to continue to work well and be cost effective, but ** it needs to be understood that sometimes packets will get dropped even if ** you don't exceed CIR. If this happens consistently, its definitely an issue ** to take up with the carrier. With the exception of outages, its definitely ** violating the spirit of agreements for a provider to oversubscribe their CIR. ** ** Regards, ** Kent Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10095t=10095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame Relay acceptable DE packets [7:9746]
Kewl.. Thanks! Mike Hundley, Kent wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Michael, My comments are inline with **: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael L. Williams Sent: Monday, June 25, 2001 9:02 PM To: [EMAIL PROTECTED] Subject: Re: Frame Relay acceptable DE packets [7:9746] Kent. I have some questions they're inline Kent Hundley wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Symon, Unfortunately, its not as simple as looking at the DE packets. Simply looking at DE packets alone doesn't tell you anything really. The reason is that if the FR cloud doesn't experience congestion, those DE packets will get there just as well as the non-DE packets. Some carriers encourage their customers to use 0K CIR because we don't oversubscribe our network, so _all_ packets are marked DE. (Sprint used to do this, don't know if they still do or not) This is good.. I often heard that people would suggest 0 CIR so that they could oversubscribe the #*$ out of their network =) Then when people's traffic didn't go through they could go well we agreed to carry 0 ** Can't speak to that, the only carrier I have seen that recommended 0 CIR is ** Sprint, and it seemed to work fairly well at the time, this is circa 1997. ** They always claimed that they didn't over-subscribe they're network, so no ** reason to pay for CIR. Course, they're pricing for 0 CIR was inline with buying ** CIR from other carriers, so in the end from a cost point it was a bit of a ** wash. If you see the FECN's spike without a corresponding spike in the DE, that means your provider is experiencing congestion, but its on a backbone link and not your link. This means the provider's links are over-subscribed and your packets are likely getting dropped without being marked DE. If this happens, and you sniff both sides and show that you're sending more than you're receiving (i.e. you prove that you have packets being lost without being marked DE), isn't that a violation of your CIR agreement (assuming it's 0)? Since nothing should get marked DE except for packets over CIR, I can see how the logic makes sense, but does this happen often? ** Yes, and no. It depends on how the carriers SLA's are written. A lot of ** SLA's are written such that you could lose quite a bit of traffic for very ** short periods of time and they would still be well within their SLA's. For ** example, if they guarantee %99.99 packet delivery and you transfer 1 Terabyte ** of data per month, they could still drop 10 Mbytes of traffic, which could ** cause problems depending on how much was dropped in a given period. ** CIR is guaranteed only if the subscriber is not over-subscribed, but even ** then if the carrier has an outage its probable that they will be ** over-subscribed for the duration of the outage. When the bits fill the ** queues, a switch must drop traffic, DE or not. ** ** IME, you usually only see consistent congestion on international links. ** Due to cost, it seems that every carrier is over-subscribed on the ** international links and some even mark every packet going across the link ** as DE regardless of CIR. (yes, I've seen it happen) This sort of thing ** is obviously not in keeping with the spirit of the CIR agreement, but again ** one needs to read SLA contracts very carefully as there are usually a lot ** of weasel words that benefit the carrier. ** ** In practice, FR seems to continue to work well and be cost effective, but ** it needs to be understood that sometimes packets will get dropped even if ** you don't exceed CIR. If this happens consistently, its definitely an issue ** to take up with the carrier. With the exception of outages, its definitely ** violating the spirit of agreements for a provider to oversubscribe their CIR. ** ** Regards, ** Kent Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10219t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame Relay acceptable DE packets [7:9746]
That's a smokin' suggestion.. taking advantage of all of your tools. nice going... Aside from his suggestion, the high DE percentage would indicate exactly what you believe it does. there's a high amount of traffic coming into you that is over CIR. Not that it is a bad thing.. it just means you're over CIR on the sending end. If anything, be thankful that that much traffic is making it through the cloud over CIR ;-). The problem arises (as you pointed out) when the provider's cloud gets congested and starts dropping your packets. You may want to configure basic traffic shaping so that when there is congestion, the interfaces will at least slow down their traffic rate and obey the CIR. Other than that, about the only thing to do is knock up the CIR =) Mike W. Mark Odette II wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I'm not sure what to say for the DE packet performance, but another way to address the slow login issue is to build really inexpensive servers (we're talking not even PII) with NT Server on them, and have them operate in the role of BDC's. Configure the registry on these units to perform their Directory and WINS replication in the off-peak times of the day of WAN usage, and you'll definitely see a performance increase. This is what I did for a client that had 4 offices connected via FR with 256k PVCs/128k CIR's (it first started out as 128k PVC's/64k CIR's, but then threw VoIP into the mix) with NT 4, WINS, Printing across the frame (special purpose situation for batch order print-outs) and of course the 128k connection to the Internet that all the employees immediately went crazy over. I too would be interested in the DE possibilities. - Original Message - From: To: Sent: Monday, June 25, 2001 4:40 AM Subject: Frame Relay acceptable DE packets [7:9746] Hi All, I have a PVC with a large amount of packets recieved with the DE bit set, and in the mornings the users complain of slow access. This is logical, as they are frequently over their CIR, and I guess the Frame cloud must be congested in the mornings. What I was looking for was some sort of guideline as to what is an acceptable percentage of packets to recieve with the DE bit set. I understand that this depends on the type of traffic that you are sending over the PVC, my use is just typical NT based remote office, being log in, email and and some file access. Below is snipped from a sh frame pvc input pkts 42007721output pkts 33246300 in bytes 4262623522out bytes 1153916597 dropped pkts 53 in FECN pkts 182632in BECN pkts 0 out FECN pkts 0out BECN pkts 0 in DE pkts 10348052out DE pkts 0 out bcast pkts 1385303 out bcast bytes 110678462 As you can see, the percentage of input packets with DE set is about 25%. This seems high, but probably ok? PVC is 512k, CIR is 256. Any words of wisdom/experience greatly appreciated. Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=9875t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Frame Relay acceptable DE packets [7:9746]
Symon, Unfortunately, its not as simple as looking at the DE packets. Simply looking at DE packets alone doesn't tell you anything really. The reason is that if the FR cloud doesn't experience congestion, those DE packets will get there just as well as the non-DE packets. Some carriers encourage their customers to use 0K CIR because we don't oversubscribe our network, so _all_ packets are marked DE. (Sprint used to do this, don't know if they still do or not) In order to make any sense of the DE packets, you also need to look at the ECN bits in the direction of the traffic flows. In your case, the Forward direction (FECN's). Looking at your info, only .4% of the inbound packets had the FECN bit set. This is very low obviously, but without knowing _when_ those FECN's occured and the rate, you still don't know much. You really need to do some qualatative analysis here during the periods when users are complaining and look at total line utilization and packets marked FECN and DE. If there is spike in the packets marked FECN and DE, chances are good that significant amount of packets are getting dropped in the FR cloud. You could run sniffers on each side of the link to verify this. If you see the FECN's spike without a corresponding spike in the DE, that means your provider is experiencing congestion, but its on a backbone link and not your link. This means the provider's links are over-subscribed and your packets are likely getting dropped without being marked DE. If there are no FECN spikes when the users complain, you will need to start looking at other things like TCP seq. and ack. numbers for site to site traffic flows. Bottom line, there's not really any number for DE, not even a rule of thumb. If your provider is not over-subscribed, 100% DE is not bad, if they are very over-subscribed, 10% DE could be bad if all 10% get dropped due to switch congestion. All the DE tells you is that _you_ are over-subscribing your CIR, to know what is happening in the FR cloud you need to look at the FECN's and BECN's. (depending on the traffic flow direction) HTH, Kent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, June 25, 2001 2:41 AM To: [EMAIL PROTECTED] Subject: Frame Relay acceptable DE packets [7:9746] Hi All, I have a PVC with a large amount of packets recieved with the DE bit set, and in the mornings the users complain of slow access. This is logical, as they are frequently over their CIR, and I guess the Frame cloud must be congested in the mornings. What I was looking for was some sort of guideline as to what is an acceptable percentage of packets to recieve with the DE bit set. I understand that this depends on the type of traffic that you are sending over the PVC, my use is just typical NT based remote office, being log in, email and and some file access. Below is snipped from a sh frame pvc input pkts 42007721output pkts 33246300 in bytes 4262623522out bytes 1153916597 dropped pkts 53 in FECN pkts 182632in BECN pkts 0 out FECN pkts 0out BECN pkts 0 in DE pkts 10348052out DE pkts 0 out bcast pkts 1385303 out bcast bytes 110678462 As you can see, the percentage of input packets with DE set is about 25%. This seems high, but probably ok? PVC is 512k, CIR is 256. Any words of wisdom/experience greatly appreciated. Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=9800t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame Relay acceptable DE packets [7:9746]
Kent. I have some questions they're inline Kent Hundley wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Symon, Unfortunately, its not as simple as looking at the DE packets. Simply looking at DE packets alone doesn't tell you anything really. The reason is that if the FR cloud doesn't experience congestion, those DE packets will get there just as well as the non-DE packets. Some carriers encourage their customers to use 0K CIR because we don't oversubscribe our network, so _all_ packets are marked DE. (Sprint used to do this, don't know if they still do or not) This is good.. I often heard that people would suggest 0 CIR so that they could oversubscribe the #*$ out of their network =) Then when people's traffic didn't go through they could go well we agreed to carry 0 If you see the FECN's spike without a corresponding spike in the DE, that means your provider is experiencing congestion, but its on a backbone link and not your link. This means the provider's links are over-subscribed and your packets are likely getting dropped without being marked DE. If this happens, and you sniff both sides and show that you're sending more than you're receiving (i.e. you prove that you have packets being lost without being marked DE), isn't that a violation of your CIR agreement (assuming it's 0)? Since nothing should get marked DE except for packets over CIR, I can see how the logic makes sense, but does this happen often? Mike W. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=9916t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Frame Relay acceptable DE packets [7:9746]
Hi All, I have a PVC with a large amount of packets recieved with the DE bit set, and in the mornings the users complain of slow access. This is logical, as they are frequently over their CIR, and I guess the Frame cloud must be congested in the mornings. What I was looking for was some sort of guideline as to what is an acceptable percentage of packets to recieve with the DE bit set. I understand that this depends on the type of traffic that you are sending over the PVC, my use is just typical NT based remote office, being log in, email and and some file access. Below is snipped from a sh frame pvc input pkts 42007721output pkts 33246300 in bytes 4262623522out bytes 1153916597 dropped pkts 53 in FECN pkts 182632in BECN pkts 0 out FECN pkts 0out BECN pkts 0 in DE pkts 10348052out DE pkts 0 out bcast pkts 1385303 out bcast bytes 110678462 As you can see, the percentage of input packets with DE set is about 25%. This seems high, but probably ok? PVC is 512k, CIR is 256. Any words of wisdom/experience greatly appreciated. Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=9746t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame Relay acceptable DE packets [7:9746]
I'm not sure what to say for the DE packet performance, but another way to address the slow login issue is to build really inexpensive servers (we're talking not even PII) with NT Server on them, and have them operate in the role of BDC's. Configure the registry on these units to perform their Directory and WINS replication in the off-peak times of the day of WAN usage, and you'll definitely see a performance increase. This is what I did for a client that had 4 offices connected via FR with 256k PVCs/128k CIR's (it first started out as 128k PVC's/64k CIR's, but then threw VoIP into the mix) with NT 4, WINS, Printing across the frame (special purpose situation for batch order print-outs) and of course the 128k connection to the Internet that all the employees immediately went crazy over. I too would be interested in the DE possibilities. - Original Message - From: To: Sent: Monday, June 25, 2001 4:40 AM Subject: Frame Relay acceptable DE packets [7:9746] Hi All, I have a PVC with a large amount of packets recieved with the DE bit set, and in the mornings the users complain of slow access. This is logical, as they are frequently over their CIR, and I guess the Frame cloud must be congested in the mornings. What I was looking for was some sort of guideline as to what is an acceptable percentage of packets to recieve with the DE bit set. I understand that this depends on the type of traffic that you are sending over the PVC, my use is just typical NT based remote office, being log in, email and and some file access. Below is snipped from a sh frame pvc input pkts 42007721output pkts 33246300 in bytes 4262623522out bytes 1153916597 dropped pkts 53 in FECN pkts 182632in BECN pkts 0 out FECN pkts 0out BECN pkts 0 in DE pkts 10348052out DE pkts 0 out bcast pkts 1385303 out bcast bytes 110678462 As you can see, the percentage of input packets with DE set is about 25%. This seems high, but probably ok? PVC is 512k, CIR is 256. Any words of wisdom/experience greatly appreciated. Cheers, Symon Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=9792t=9746 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
SNIFFING TCP PACKETS ? [7:8683]
When sniffing a TCP conversation on NAI Sniffer pro. why do ack only packets show a length of 60 bytes when the minimum ether frame should be 64 ?/ where are the other 4 bytes Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] This e-mail and any files transmitted with it are intended solely for the addressee and are confidential. They may also be legally privileged. Copyright in them is reserved by Delphis Consulting PLC [Delphis] and they must not be disclosed to, or used by, anyone other than the addressee. If you have received this e-mail and any accompanying files in error, you may not copy, publish or use them in any way and you should delete them from your system and notify us immediately.E-mails are not secure. Delphis does not accept responsibility for changes to e-mails that occur after they have been sent. Any opinions expressed in this e-mail may be personal to the author and may not necessarily reflect the opinions of Delphis. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8683t=8683 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
SNIFFING TCP PACKETS [7:8684]
I've just thought of something .The only part of an 802.3 or EV2 frame that is 4 bytes is the FCS. Is the sniffer not reading these bytes??? Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] This e-mail and any files transmitted with it are intended solely for the addressee and are confidential. They may also be legally privileged. Copyright in them is reserved by Delphis Consulting PLC [Delphis] and they must not be disclosed to, or used by, anyone other than the addressee. If you have received this e-mail and any accompanying files in error, you may not copy, publish or use them in any way and you should delete them from your system and notify us immediately.E-mails are not secure. Delphis does not accept responsibility for changes to e-mails that occur after they have been sent. Any opinions expressed in this e-mail may be personal to the author and may not necessarily reflect the opinions of Delphis. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8684t=8684 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: SNIFFING TCP PACKETS ? [7:8683]
64 bytes is the minimum length of the entire frame. The mininum size of the data portion of the frame is 38 bytes for 802.3 and 46 bytes for Ethernet. TCP/IP Illustrated Volume 1 is the source of this data and altough slightly dated probably the best book on TCP/IP in print. Burnham, Chris wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... When sniffing a TCP conversation on NAI Sniffer pro. why do ack only packets show a length of 60 bytes when the minimum ether frame should be 64 ?/ where are the other 4 bytes Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] This e-mail and any files transmitted with it are intended solely for the addressee and are confidential. They may also be legally privileged. Copyright in them is reserved by Delphis Consulting PLC [Delphis] and they must not be disclosed to, or used by, anyone other than the addressee. If you have received this e-mail and any accompanying files in error, you may not copy, publish or use them in any way and you should delete them from your system and notify us immediately.E-mails are not secure. Delphis does not accept responsibility for changes to e-mails that occur after they have been sent. Any opinions expressed in this e-mail may be personal to the author and may not necessarily reflect the opinions of Delphis. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8707t=8683 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: SNIFFING TCP PACKETS [7:8684]
CRC field is also 4 bytes on 802.2/3 frames and RFC 894 Ethernet frames.. Burnham, Chris wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I've just thought of something .The only part of an 802.3 or EV2 frame that is 4 bytes is the FCS. Is the sniffer not reading these bytes??? Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] This e-mail and any files transmitted with it are intended solely for the addressee and are confidential. They may also be legally privileged. Copyright in them is reserved by Delphis Consulting PLC [Delphis] and they must not be disclosed to, or used by, anyone other than the addressee. If you have received this e-mail and any accompanying files in error, you may not copy, publish or use them in any way and you should delete them from your system and notify us immediately.E-mails are not secure. Delphis does not accept responsibility for changes to e-mails that occur after they have been sent. Any opinions expressed in this e-mail may be personal to the author and may not necessarily reflect the opinions of Delphis. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8709t=8684 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: SNIFFING TCP PACKETS ? [7:8683]
Yes, Minimum Ethernet frame is 64 but Sniffers do not include CRC when displaying packets Gio Burnham, Chris wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... When sniffing a TCP conversation on NAI Sniffer pro. why do ack only packets show a length of 60 bytes when the minimum ether frame should be 64 ?/ where are the other 4 bytes Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] This e-mail and any files transmitted with it are intended solely for the addressee and are confidential. They may also be legally privileged. Copyright in them is reserved by Delphis Consulting PLC [Delphis] and they must not be disclosed to, or used by, anyone other than the addressee. If you have received this e-mail and any accompanying files in error, you may not copy, publish or use them in any way and you should delete them from your system and notify us immediately.E-mails are not secure. Delphis does not accept responsibility for changes to e-mails that occur after they have been sent. Any opinions expressed in this e-mail may be personal to the author and may not necessarily reflect the opinions of Delphis. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8734t=8683 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: SNIFFING TCP PACKETS ? [7:8683]
FCS. I use EtherPeek these days, which does account for the 4-byte FCS, but Sniffer does not, as I recall. Priscilla At 04:30 AM 6/15/01, Burnham, Chris wrote: When sniffing a TCP conversation on NAI Sniffer pro. why do ack only packets show a length of 60 bytes when the minimum ether frame should be 64 ?/ where are the other 4 bytes Chris Burnham, Systems Engineer, Delphis Consulting Plc. Tel: +(44) 020 7916 0200 Mob: +(44) 07799403576 [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8737t=8683 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Generate Packets for the Lab [7:8347]
I would like to use router to generate data packets (IP and/or IPX) what commands can accomplish this? Thank you Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=8347t=8347 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
L2/L3 Framing or packets? [7:7867]
Newbie question If a device is using the fast switching method and only the first packet is handled* by the router, does the switch look any deeper than the frame level to determine the switching for the remaining packets/frames? How does it read the rewritten frame to know that it should send the remaing packets of the session to the same switch port as the first frame without going through the router? Cisco site info *The frame is rewritten and sent to the exit interface that services the destination. Subsequent packets for the same destination use the same switching path TIA Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=7867t=7867 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: L2/L3 Framing or packets? [7:7867]
Yes. The switch examines past the normal layer 2/MAC info to the IP layer 3 information, to find, depending on the mode, the destination and source IP addresses and sometimes the port numbers (layer 4). I recently posted a (rather) lengthy post outlining the process of multilayer switching I can e-mail you a copy if you let me know Basically, here's a quick overview. (for reference a flow is unidirection traffic from a given source IP and port to a give destination IP and port) When a frame arrives, it has a source MAC of the host that sent the frame and a destination MAC of the IP gateway (which is the router interface). The switch looks past the layer 2 headers at the source/destination IP and port #s and checks in the Mulilayer Switching (MLS) cache. If there is not entry matching this info, it makes a partial entry using the source/destination IP and port #s and sends the frame to the router. The router routes the packet and, in the process, rewrites the layer 2 info now showing the source MAC as the outgoing interface on the router and the destination MAC as the MAC of the destination host and sends it back to the switch. The switch then examines the source/destination IP and port #s, and sees the partial cache entry for this flow, and takes note of the new rewritten source/destination MAC addresses and which switchport it will exit and that completes the MLS cache entry. For every frame in that flow after that, when the switch examines the source/destination IP and port #s, it sees the MLS cache entry for that flow, takes the MAC info that it saw from the first routed packet, and simply rewrites the layer 2 info itself just as if the packet has been sent through the router, and sends it out itself without every passing it to the router. This is a very basic summary of how this works because there are difference kinds of flows, etc... but this should give you a good idea of what they mean when they say The frame is rewritten and sent to the exit interface. Mike W. Larry trav wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Newbie question If a device is using the fast switching method and only the first packet is handled* by the router, does the switch look any deeper than the frame level to determine the switching for the remaining packets/frames? How does it read the rewritten frame to know that it should send the remaing packets of the session to the same switch port as the first frame without going through the router? Cisco site info *The frame is rewritten and sent to the exit interface that services the destination. Subsequent packets for the same destination use the same switching path TIA Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=7869t=7867 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Lots of brodacast packets [7:6018]
Thanks for clearing broadcast issue, so I do need broadcast on Ethernet interface. I do get quite few input errors and everything is seems okay on the switch connected including duplex, speed settings so not sure why it's getting CRCs and input errors. For ping latency to ISDN sites issue, I gone through talking TAC and this newsgroup but no luck yet Cisco is offering new router but I do not think it's router. We have T1 going out to ISDN sites using Cisco 7505. weird thing is ping latency goes in circle meaning it's not only one site but to all sites one by one.. Thanks Inamul Here is sh int from router Serial2/1:23 is up, line protocol is up (spoofing) Hardware is cxBus T1 MTU 1500 bytes, BW 64 Kbit, DLY 2 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 1 seconds on reset Last input 00:00:06, output 00:00:06, output hang never Last clearing of show interface counters 2d18h Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 28070 packets input, 133292 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 28153 packets output, 194170 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions no alarm present Timeslot(s) Used:24, subrate: 64Kb/s, transmit delay is 0 flags Transmit queue length 23 FastEthernet3/0/0 is up, line protocol is up Hardware is cyBus FastEthernet Interface, address is 00e0.fea0.ec60 (bia 00e0. fea0.ec60) Internet address is 204.239.50.3/24 MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 2d18h Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 492 drops 5 minute input rate 41000 bits/sec, 36 packets/sec 5 minute output rate 41000 bits/sec, 38 packets/sec 4679482 packets input, 878944627 bytes, 0 no buffer Received 425728 broadcasts, 0 runts, 0 giants, 34 throttles 1026 input errors, 1026 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 5871168 packets output, 1153644205 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets --More-- -Original Message- From: Dennis R [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 26, 2001 4:41 AM To: [EMAIL PROTECTED] Subject: Re: Lots of brodacast packets [7:6018] I am getting lot of broadcast packets on FastEthernet interface when I do sh interface on cisco 7505. What does, Lots, mean? Broadcasts are part of life in a network, cf. ARP, GNS, SAP, RIP updates, etc. I also get input errors on that interface What percentage of your input packets is it? Are they collisions (normal in an unswitched environment), CRC's, or ?? You may want to check your cabling, and your speed/duplex settings if the router is plugged into a switch. and big ping (up to 1200ms) latency to isdn sites. Could be caused by many, many things. It's unlikely this has anything to do with your ethernet interface. You might start by looking for overutilized circuits causing routers to drop packets from their output queues. What to expect if I turn off these broadcasts? ARP won't work, therefore TCP/IP won't work. Do I need receive broadcast packets on interface? Yes. HTH, doctorcisco _ Get your FREE download of MSN Explorer at http://explorer.msn.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=6138t=6018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Lots of brodacast packets [7:6018]
I am getting lot of broadcast packets on FastEthernet interface when I do sh interface on cisco 7505. I also get input errors on that interface and big ping (up to 1200ms) latency to isdn sites. What to expect if I turn off these broadcasts ? Do I need receive broadcast packets on interface ? Thanks Inamul Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=6018t=6018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Lots of brodacast packets [7:6018]
I am getting lot of broadcast packets on FastEthernet interface when I do sh interface on cisco 7505. What does, Lots, mean? Broadcasts are part of life in a network, cf. ARP, GNS, SAP, RIP updates, etc. I also get input errors on that interface What percentage of your input packets is it? Are they collisions (normal in an unswitched environment), CRC's, or ?? You may want to check your cabling, and your speed/duplex settings if the router is plugged into a switch. and big ping (up to 1200ms) latency to isdn sites. Could be caused by many, many things. It's unlikely this has anything to do with your ethernet interface. You might start by looking for overutilized circuits causing routers to drop packets from their output queues. What to expect if I turn off these broadcasts? ARP won't work, therefore TCP/IP won't work. Do I need receive broadcast packets on interface? Yes. HTH, doctorcisco _ Get your FREE download of MSN Explorer at http://explorer.msn.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=6022t=6018 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Frame relay and dropped packets... [7:4529]
Hi all, We have reason to believe we are experiencing Dropped packets between us and our remote branch. What I need Is proof, so I can go to my manager and say, here, look at this. He believes just because he looks at the router and does a show frame pvc and the Dropped Pkts statistic is 0, that there are no packets being dropped. Logical Assumption, but I've been told that just isn't the case. Let me throw this out to the groupForget about the FECN's, BECN's and the DE pkts...If you were to telnet to both routers and look at the statistics of the point-to-point DLCI and compare the Output pkts on one end to the Input pkts on the other end, and if you see a discrepancy of 500,000correct me if I'm wrong here, but wouldn't that symbolize Dropped packets???Thanks! -Rizzo Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=4529t=4529 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Frame relay and dropped packets... [7:4529]
Just a couple quick questions. Have you cleared the counters on both sides? How long after clearing the counters is it taking for the 500,000 packet difference to materialize? Do you have any other remote branches going to this interface? Hi all, We have reason to believe we are experiencing Dropped packets between us and our remote branch. What I need Is proof, so I can go to my manager and say, here, look at this. He believes just because he looks at the router and does a show frame pvc and the Dropped Pkts statistic is 0, that there are no packets being dropped. Logical Assumption, but I've been told that just isn't the case. Let me throw this out to the groupForget about the FECN's, BECN's and the DE pkts...If you were to telnet to both routers and look at the statistics of the point-to-point DLCI and compare the Output pkts on one end to the Input pkts on the other end, and if you see a discrepancy of 500,000correct me if I'm wrong here, but wouldn't that symbolize Dropped packets??? Thanks! -Rizzo FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=4535t=4529 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Frame relay and dropped packets... [7:4529]
I clear the counters usually every 30 days. And no there are no other branches going into this interface. -Original Message- From: Bob Timmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:59 AM To: [EMAIL PROTECTED] Subject: Re: Frame relay and dropped packets... [7:4529] Just a couple quick questions. Have you cleared the counters on both sides? How long after clearing the counters is it taking for the 500,000 packet difference to materialize? Do you have any other remote branches going to this interface? Hi all, We have reason to believe we are experiencing Dropped packets between us and our remote branch. What I need Is proof, so I can go to my manager and say, here, look at this. He believes just because he looks at the router and does a show frame pvc and the Dropped Pkts statistic is 0, that there are no packets being dropped. Logical Assumption, but I've been told that just isn't the case. Let me throw this out to the groupForget about the FECN's, BECN's and the DE pkts...If you were to telnet to both routers and look at the statistics of the point-to-point DLCI and compare the Output pkts on one end to the Input pkts on the other end, and if you see a discrepancy of 500,000correct me if I'm wrong here, but wouldn't that symbolize Dropped packets??? Thanks! -Rizzo FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=4541t=4529 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
