MVRF over dot1q interfaces
Attached is the network connectivity showing the connectivity between our CE's and the PE's
All sites which have a ethernet lastmile are terminated on a switch which is then trunked to the PE. Subinterfaces are used on the PE to create BGP adjacencies between the CE and the PE
Now i have to connect another site again via EoSDH. This site needs to be MVRF capable and hence i am planning to use subinterfcaes and dot1q even on the CE to segregate the traffic.
Will the CE-PE peering work if i just create a dot1q trunk on the agg switch towards the CE as well or do i need some other configuration
Narayan
Hi Narayan
Funnily enough i have just been doing something similiar in our lab because i need to do the same kind of thing.
In answer to your question yes you need to make the link from your agg switch to your new CE an 802.1q trunk and then obviously apply the subinterfaces and vlan interfaces into the relevant vrf's.
This type of setup worked well in my lab using a mixture of 7200/2600 routers and 3560 switches.
I would like to say it has gone well in production but i'm having issues with my SP getting some answers on QOS/Shaping/subinterfaces so i might be picking your brains on that if you don't mind.
Jon
Similar Messages
-
Is it possible to use MVR for delivering multicast to customers over dot1q-tunnel interface ?
Can QinQ and MVR work together ?I think the muticast vlan registration shortly termed MVR is not supported in dot1Q tunnelling interface.Because, there is a criteria for configuring MVR.That is, while configuring MVR, receiver ports cannot be trunk ports. Since, do11q is a trunking protocol,I believe MVR can't be transmitted over trunk port, and hence over dot1q tunnel interface.For detailed info on this mvr,
refer to the configuration guidelines sections of mvr at:
http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a008007e8d9.html#xtocid14 -
LOST TCP SESSION, LDP AND BGP, OVER ONE INTERFACE
On 7609 PE router, lost only TCP session attach to one interface (Te3/3). The router shows this log
Aug 4 13:17:31.424: %LDP-5-NBRCHG: LDP Neighbor 200.111.117.251:0 (1) is DOWN (Session KeepAlive Timer expired)
Aug 4 13:19:52.493: %BGP-5-ADJCHANGE: neighbor 200.11.96.126 Down BGP Notification sent
Aug 4 13:19:52.493: %BGP-3-NOTIFICATION: sent to neighbor 200.11.96.126 4/0 (hold time expired) 0 bytes
Aug 4 13:42:11.265: %BGP-5-ADJCHANGE: neighbor 200.11.96.126 Up
Aug 4 13:42:23.549: %LDP-5-NBRCHG: LDP Neighbor 200.111.117.251:0 (1) is UP
The device did not present a interface flap.
The device did not present lost of OSPF adyacency, over the same interface
The device did not present lost of TCP session over oher interfaces
Please help me,
I suspect a bug, but I failed to find
ChristianHi Nagendra
This is output og sh tcp brief
PE2-PCS-RANCAGUA#sh tcp brief
TCB Local Address Foreign Address (state)
4B558124 200.11.98.9.646 200.11.98.37.51654 ESTAB
53336910 200.11.98.9.646 200.111.117.61.49833 ESTAB
4B4CF2A0 200.11.98.9.646 200.111.117.20.64138 ESTAB
536E56A4 200.11.98.9.61369 200.11.96.126.179 ESTAB
53359454 200.11.98.9.22913 200.11.96.81.646 ESTAB
4B6C25EC 200.11.98.9.646 200.111.117.251.53802 ESTAB
537CFBE4 200.11.98.9.62975 200.11.96.125.179 ESTAB
5330A774 200.11.98.9.646 200.111.117.86.62367 ESTAB
4B4D97EC 200.11.98.9.18753 200.11.96.88.646 ESTAB
4B018A28 200.11.98.9.61292 200.11.98.8.646 ESTAB
4B0B176C 200.11.98.9.23 190.151.64.218.36508 ESTAB
4B1976F0 200.11.98.9.17760 190.151.97.92.646 ESTAB
4B261BD0 200.11.98.9.646 200.72.146.42.64641 ESTAB
537CEFF8 200.11.98.9.646 200.111.117.74.54785 ESTAB
531F4890 200.11.98.9.15536 190.151.97.77.646 ESTAB
5359F5B4 200.11.98.9.24658 190.151.97.74.646 ESTAB
PE2-PCS-RANCAGUA#
Christian -
File Sharing over web interface?
I am trying to figure out a solution.
We are an advertising agency that we need to transfter files between our studio and clients (which are mostly PC based and cannot connect to conventional ftp server) so we are looking at creating something like dropbox.com.
I don't mind to work over afp, smb, ftp or WebDav, but I need an nice enough interface and it's got to support OS X server's user/ permission ACL.
I know for calendars, Mac OS X server has built an web interface out-of-the-box, but how about file sharing over web?
Anyone sharing any thoughts?As I said in my original post, I'm not using Firewire Target Disk mode because it requires a full shutdown of one of the computer (usually my laptop) each time I want to access files from the other computer.
I don't know about you, but usually I've got several things going at the same time on my computers and I'd rather not have to fully shut down the MacBook Pro several times a day.
ps - directing me to a different solution doesn't explain why things aren't working properly in the first place, but thanks anyway -
How to measure the number of ping over a interface
Hello
I need to setup a measurement of the number of ping that goes throug an ethernet interface over a duration of 3min
How can I do that ?
thanks for helpHello
thanks for help
I have an application which sent pings to hundred of routers to test connectivity for pro-active monitoring purpose. there are some strange performance problem on this application and I want to measure the number of pings sent during a time interval -
Non-global zone sending TCP SYN-ACK packet over wrong interface.
After spending many hours looking at ipmon/ethereal logs, I believe I've found
a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
=====
The non-global zone has this setup:
zonecfg:ws1> info
...snip...
net:
address: 62.146.25.34
physical: e1000g2
zonecfg:ws1>
=====
The relevant (as of the IPF log) IPF rules are:
rule 1: block out log all
rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
=====
If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
Any hints?
Thx,
Tobias
"att1.txt":
LINE PACKET_DT PACKET_FS PACKET_IFC RULE_NUMBER RULE_ACTION SOURCE_IP SOURCE_PORT DEST_IP DEST_PORT PROTOCOL TCP_FLAGS
1 08.05.2006 21:24:09 786741 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp S
2 08.05.2006 21:24:09 786863 e1000g0 16 p 62.146.25.34 80 84.56.16.159 60693 tcp AS
3 08.05.2006 21:24:09 808218 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp A
4 08.05.2006 21:24:09 837170 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
5 08.05.2006 21:24:09 837189 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
6 08.05.2006 21:24:09 837479 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
7 08.05.2006 21:24:12 823801 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
8 08.05.2006 21:24:12 823832 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
9 08.05.2006 21:24:13 210039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
10 08.05.2006 21:24:18 839318 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
11 08.05.2006 21:24:18 839351 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
12 08.05.2006 21:24:19 970040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
13 08.05.2006 21:24:24 840073 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AF
14 08.05.2006 21:24:30 870503 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
15 08.05.2006 21:24:30 870538 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
16 08.05.2006 21:24:33 480059 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
17 08.05.2006 21:24:45 347464 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AF
18 08.05.2006 21:24:45 347498 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
19 08.05.2006 21:24:47 857068 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp S
20 08.05.2006 21:24:47 857118 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AS
21 08.05.2006 21:24:47 878257 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
22 08.05.2006 21:24:47 907630 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
23 08.05.2006 21:24:47 907644 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
24 08.05.2006 21:24:47 907892 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
25 08.05.2006 21:24:47 976361 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
26 08.05.2006 21:24:47 976375 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
27 08.05.2006 21:24:47 976487 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
28 08.05.2006 21:24:48 127599 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
29 08.05.2006 21:24:54 932569 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
30 08.05.2006 21:24:54 932595 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
31 08.05.2006 21:25:00 490052 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
32 08.05.2006 21:25:02 980057 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AF
33 08.05.2006 21:25:03 1890 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
34 08.05.2006 21:25:09 907916 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AF
35 08.05.2006 21:25:09 907949 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
36 08.05.2006 21:25:42 948502 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
37 08.05.2006 21:25:42 948535 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
38 08.05.2006 21:25:54 500051 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
39 08.05.2006 21:26:54 510046 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
40 08.05.2006 21:27:54 520041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
41 08.05.2006 21:28:54 530040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
42 08.05.2006 21:29:54 540039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
43 08.05.2006 21:30:54 550039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
44 08.05.2006 21:31:54 560041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
"dump_failed.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x0269 (617)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde9d [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x5c3c [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x002f (47)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ed8 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1079 (1079)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xd017 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x026a (618)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdea4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbdac]
No. Time Source Destination Protocol Info
4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x026b (619)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcfd [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 5 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0276 (630)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcf2 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 6 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x027f (639)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce9 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 7 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0284 (644)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x029a (666)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde74 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbc05]
"dump_success.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x02a3 (675)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde63 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x70ca [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x006b (107)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2e9c [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xb530 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02a4 (676)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde6a [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xa2c5]
No. Time Source Destination Protocol Info
4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x02a5 (677)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcc3 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xb2be]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006c (108)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea3 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xe046 [correct]
No. Time Source Destination Protocol Info
6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
Frame 6 (413 bytes on wire, 413 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 399
Identification: 0x006d (109)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d3b [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Next sequence number: 360 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x29b8 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
Frame 7 (407 bytes on wire, 407 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 393
Identification: 0x02aa (682)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdd03 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Next sequence number: 776 (relative sequence number)
Acknowledgement number: 360 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65176
Checksum: 0x1b3d [incorrect, should be 0x1e0c]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006e (110)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea1 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xdd7e [correct]
No. Time Source Destination Protocol Info
9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
Frame 9 (464 bytes on wire, 464 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 450
Identification: 0x006f (111)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d06 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Next sequence number: 770 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x7a71 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02af (687)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde5f [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 776 (relative sequence number)
Acknowledgement number: 770 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64766
Checksum: 0x19dc [incorrect, should be 0x9fbe]lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
Thus I created a bug report: https://bugs.archlinux.org/task/40089
i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
Client connecting to 10.10.10.6, TCP port 5001
TCP window size: 416 KByte
[ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
[ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
[ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
[ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
[ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
[ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
[ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec -
Volatile DLU will not work over wired interface.
Hi all,
I've got a weird one that has me stumped. We've got a DLU policy that is working well for our teacher accounts. It is set to user user source credentials, is not volatile, and hasn't caused us issues.
We're starting to move over and get new Windows 7 machines on the student workstation side. For our students, attempting to get a volatile DLU user set up, with a cache. In testing on desktop machines, it is failing. I'm working now on testing with a laptop and the weirdest thing keeps happening. The DLU policy applies and logins work great with a test student user - but only when attached to the wireless network. Over the wired interface (with wireless completely off), it will not work. The novell client login works, then the dreaded Zen login box comes up, with the name of the volatile login account (that should be local) in the user box. It will not go forward from that point unless I put in a local user name/password. If I do this, I can login thru the zen icon all day long, over the wired interface. This is very similar to the issues we are having on the student workstation machines, or I would just call it odd and move on.
I've simplified out my network locations to just be one network for now, so that is out as a cause. Completely disabling the wireless adapter, so that it does not show in the zmg-messages log at all did not help either. I can remote control it in that state, and it talks to ZCC.
The servers are 11.2.2 - Vmware Appliances, have not applied the monthly updates but have them in the queue. Agent the same on the workstation. If anyone has any ideas, I'd love to hear them.
Thanks
PeteOK - Got this solved. Had applied a registry edit for teacher laptops in the summer based on this TID Support | How to configure "Computer Only Logon If Not Connected" functionality . The login issues only occurred after a teacher account had logged in. The student workstation image had the wired interface listed as 'Public', which caused the novell client to passthru and silently not attempt the login, hence the odd behavior. Oops. Have now limited that regedit to only applying to the teacher laptop workstations. Since these are some of our first student workstations, its not reared its head before. Oh well.
Pete -
Playing Video to TV over RGB interface
I have X61 & X200. When I attach either PC to my 42 inch Toshiba LCD TV via an RGB interface, there are two blank spaces running down each side of the desktop displayed on the TV. I understand that this may be caused as I cannot select an image resolution of 1360 x 768. On the X61 I have Mobile Intel 965 Express Chipset, with 7.14.10.1437 driver - when I click update driver after search on web I am told it is the most up to date. on the X 200 I have 4 Series Express Chipset with dirver 7.15.10.1502 again I have tried to udpate the driver with same result.
The Intel web site has a driver update revision 15.12.4.1666 which i have downloaded to my X61 however when I try to load I am told the dirver is not validated for this computer. I have not tried the same for X200 as I expect the same result.
Given that I seem to have the most up to date drivers, & I seem to have exhausted all possible display options & selections from Intel Graphics Media Accelerator Driver, trying Intel Tv wizard (possible on X61 but not X200), output to extended display monitor primary/notebook primary, single display monitor only, Intel dual display, etc, etc I still cannot get the desktop on the TV to be the same size/resolution as the TV screen nor do I have an option to select any resolution like 1360 x 768.
Does this mean that I cannot use my X series ntoebook to watch movies on my TV? i have seen people do this with Maconto TV & it seems to work very well.It is a 3rd party supplier. My wife has the 1st generation IPT and has the same cable, but is from Apple. I will try it out later today. I will also see if her IPT works with my cable.
I think it would be pretty strange that the manufacturer of this 3rd party cable would not try out the cable first. -
Routing outgoing packets over multiple interfaces?
I have two network interfaces (eth0 and eth1) with separate IP addresses on the same subnet. All outgoing traffic uses eth0 regardless of the interface the incoming traffic came in on.
I assume the outgoing packets still have the correct source IP address (not always eth0's), and I'd like the packets to go out on the interface with the corresponding IP address.
I think I have half the solution to my problem:
http://www.novell.com/support/viewConte … Id=7000318
The other half is that my IPs are dynamic, so ddclient could change my IPs and then the routing would be invalid.
Last edited by MindlessXD (2009-02-10 07:06:16)Setup custom route tables to be used depending on the iptables conntrack marks below
ip route flush table 1
ip rule del fwmark 101 table 1
ip route add table 1 default via <ETH0 IP ADDRESS>
ip rule add fwmark 101 table 1
ip route flush table 2
ip rule del fwmark 102 table 2
ip route add table 2 default via <ETH1 IP ADDRESS>
ip rule add fwmark 102 table 2
I'm not 100% sure if you can add a route via the interfaces IP address. This code has been modified from a box using 2 different ISP's so they have different upstream routers. You might need to replace the 'via' parts with 'src'
# Ensure traffic in one interface goes back out the same interface
iptables -t mangle -F PREROUTING
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -m state --state NEW -j MARK --set-mark 101
iptables -t mangle -A PREROUTING -i eth1 -m state --state NEW -j MARK --set-mark 102 -
Data drop on multicast over virtual interfaces
I have two interfaces, one normal and one virtual (though I tested this with two virtuals on the same physical card with the same results).
I found that if the same multicast group is joined on both interfaces, then one leaves the group, the other ceases to receive data (until a query comes out from the switch if it is set up to do so).
When two programs join the same group on the same interface and one leaves, the ip stack does not send out a leave, but decrements the reference count interested in that group.
I would assume this is not the desired behavior because, for example, if two distinct zones were both listening to the same multicast, one would affect the other when one left the group.
I was wondering if there are some parameters somewhere that can be set to take care of this or if this is truly a bug.I have two interfaces, one normal and one virtual (though I tested this with two virtuals on the same physical card with the same results).
I found that if the same multicast group is joined on both interfaces, then one leaves the group, the other ceases to receive data (until a query comes out from the switch if it is set up to do so).
When two programs join the same group on the same interface and one leaves, the ip stack does not send out a leave, but decrements the reference count interested in that group.
I would assume this is not the desired behavior because, for example, if two distinct zones were both listening to the same multicast, one would affect the other when one left the group.
I was wondering if there are some parameters somewhere that can be set to take care of this or if this is truly a bug. -
Bridge over Cellular interface
Hi all,
I'm looking for a way to bridge between a cellular interace and vlan interface on a 881. Is it possible? I failed to find relevant examples. (I also have a dialer interface connected to this cellular interface, though I it can be removed with some configs if not possible like this) My goal is to forward the IP assigned by the ISP(via cellular and/or dialer) directly to the client behind.
Thanks for the ideas in advance
Regards,Please find the cellular interface config.
1. Create a Profile specific to your mobile ISP
Router# cellular 0/2/0 gsm profile create 1 chap cisco cisco
* --> provided by ISP.
2. Unlock SIM
Router# cellular 0/2/0 gsm sim unlock 1234
3. Define ATDT command
Router#chat-script gsm "" "ATDT*99#" TIMEOUT 60 CONNECT
4. Configure the line interface
line 0/2/0
script dialer gsm
modem InOut
no exec
transport input all
rxspeed 7200000
tspeed 5760000
5. Configure cellular interface
interface Cellular0/2/0
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer in-band
dialer idle-timeout 0
dialer string gsm
dialer-group 1
async mode interactive
ppp chap hostname cisco
ppp chap password cisco
ppp ipcp dns request
6. Create access-list for interesting traffic.
ip access-list extended cellular_traffic
permit ip 192.168.1.0 0.0.0.255 any
7. Initiate cellular dialer interface
dialer-list 1 protocol ip list cellular_traffic
6. Verifying the cellular interface
Router#show cellular 0/2/0 all -
Slow tcp traffic over ge0 interface
I have a server that while using ge0 for UDP traffic, it uses full bandwidth, but for tcp is slow as hell.... ttcp is showing how slow it is, into the kbps rather than mbps. I want to know if there is a specific patch to fix this.
I've been double checking everything this morning and I feel we were not attacked. All the MAC addresses in my capture are valid system addresses. ISE does not show any authorized machines attempting to connect to the switch. We have DHCP snooping enabled throughout the organization. That was a great article to learn from though.
I've included a visio of the setup and a snippet of the wire capture and arp/mac tables as were captured during the incident. Traffic from the fileserver intended for employee 2 was flooding the port employee 1 was connected on. The destination MAC address of the packets were not meant for employee 1.
Default config for both ports:
switchport access vlan 101
switchport mode access
ip access-group ACL_DEFAULT in
authentication event fail action next-method
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication violation restrict
mab
snmp trap mac-notification change added
snmp trap mac-notification change removed
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
spanning-tree bpduguard enable
Am I missing something? Was this an attack? Was it a fluke? -
Private vlan over dot1q trunks with etherchannels
Dear Freinds,
I need to know whether can i use trunks in etherchannel for Private Vlans.
regards
Manish ShamjeeHello manish,
You would need to elaborate more on that.
Are you trying to 'trunk' primary private vlan's or secondary private vlans? Or are you trying to configure private vlans on ports that are etherchannels?
Read this "Do not configure private VLAN ports as EtherChannels. While a port is part of the private VLAN configuration, any EtherChannel configuration for it is inactive"
The above is from the pvlan guidelines and restrictions found here:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/pvlans.htm#wp1090979 -
I want to reset comport?
I want to write to comport?
I want terminated read?As far as examples go, do you have a CNiVisaSession example that includes asynchronous communication. I'm having trouble getting the callback handler working.
class SerialDlg : public CDialog
CNiVisaSession *m_Session;
ViStatus AsynchEventHandler(CNIVisaEvent& event);
BOOL SerialDlg:nInitDialog()
m_Session = new CNiSession((NiString)"ASRL1::INSTR", VI_NULL, (uInt32)1000);
m_Session->InstallEventHandler(VisaEventIoComplete,AsynchEventHandler,userData);
I've had limited success in doing this. So far, I can only get it working if the callback is a c declared, I'm hoping to have the callback a class member function as shown above. I've spent quite a bit of time trying the OnVisaEventHandler macro without any luck.
Tha
nks,
Lyle -
DLSW ethernet redundancy for multiple vlans
Can dlsw ethernet redundancy support mutliple vlans with the following configuration?
host dlsw router1 host dlsw router2
| |
local dlsw router 1 local dlsw router2
| |
ethernet switch1-------ethernet switch2
Ethernet switch1 and 2 are supporting multiple vlans and connected to local dlsw router1 and 2 through 802.1Q. SNA support is required for the vlans of ethernet switch1 and 2 .
We found that configuration of dlsw ethernet redundancy is not allowed on the 802.1Q sub-interface of the local dlsw router1 and 2. In this case, how can dlsw ethernet redundancy can be supported for SNA server attached to multiple vlans? Can you provide us some reference / sample for dlsw ethernet redundancy to support SNA servers attached to different vlans in a switch environment.
Thanks.I think that I understand the problem. I am thinking the following:
dlsw local-peer peer-id 2.2.2.2 promiscuous
dlsw transparent switch-support
interface Ethernet0
mac-address 0000.3333.3333
dlsw transparent redundancy-enable 9999.9999.9999 master-priority 10
dlsw transparent map local-mac 0000.6666.0000 remote-mac 0200.eca2.0000 neighbor 0000.5555.5555
interface Ethernet1
mac-address 0000.4444.4444
dlsw transparent redundancy-enable 9999.9999.0001 master-priority 10
dlsw transparent map local-mac 0000.6666.0001 remote-mac 0200.eca2.0000 neighbor 0000.7777.7777
Of course, you need an ethernet interface per VLAN. If you need DLSw ER over dot1q interface, please contact the local Cisco Sales Rep or partner. You are not the first one to ask for it. Hope that there is a strong business case to initiate the new feature.
Maybe you are looking for
-
Lost the ability to Spotlight Index my Time Machine drive
I have an external, Firewire Time Machine drive which has been working without problems up to now. This evening I had a backup which hung up in the "preparing" stage (no file transfers begun yet). When I went to look in the console, there was a devic
-
TTY (Q90D) not compatible with BlackBerry Z10
Please fix this. I purchased a TTY machine (Q90D) for a deaf friend to use and it will not function properly on the Z10. I called the TTY company which makes this product and they concluded I was doing everything right, but that the BlackBerry Z10
-
MDM or XI for a workflow consultant...
Hi there, I have been working in SAP ABAP workflow for 3+ years now. Now I am looking to add some more skills. I am thinking of either taking up MDM (work with MDM workflows) or XI (work with ccBPM). I am confused, please help me. Thanks, Sukumar.
-
Could you please help me figure out what the problem with my code is? I get: C:\Documents and Settings\Sandy\My Documents\Payroll2.java:31: unreachable statement System.out.println( "Enter Hourly Rate: "); // prompt ^ 1 error when I compile this: //
-
Approval Stage & Template Problem
Hi Experts, I have created approval stages and template for outgoing payments where document total is the only criteria for approval templates. Is it possible to restrict specific user with outgoing payment series wise by writing query ?? If possible