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

  • MVR over DOT1Q-TUNNEL

    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
    Christian

    Hi 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 help

    Hello
    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
    Pete

    OK - 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 Shamjee

    Hello 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 have a Program written in VC++ using NI App Wizard, I want to use VISA ActiveX control to communicate over Serial interface, Is there any sample program, which shows init, Read, Write routines?

    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.

  • Unreachable statement error

    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