On Tue, October 14, 2014 15:14, jure brkljacic wrote: > Hi, Hi Jure, > ->>Linecards used on 7606 routers 76-ES+T-8TG > ->>IPv6 configuration is valid,it seems that pseudowire is "eating" traffic > > any suggestions?
We have almost the same issue here, accept that we are switching through bridge-domains, and TAC is trying to solve this since June without success yet.. "The packets are lost in the microcode" Our Setup: We have two customer facing EVPLs matching on Vlan 98 on port gi4/17 and gi4/19. The direct attached customer hosts sends singletagged vlan 98 ethernet packets with ipv6 payload (ping6). With IOS 15.3.1-S2 both hosts can ping each other. After booting same config with IOS 15.3.3-S2 the hosts can't ping each other. Looking in Wireshark the "Neighbor solication" packets of one host are not being forwarded to the other host. interface GigabitEthernet4/17 description Test mtu 1998 ip arp inspection limit none no ip address logging event link-status load-interval 30 speed auto storm-control broadcast level 50.00 storm-control multicast level 50.00 storm-control action trap no keepalive no cdp enable spanning-tree bpdufilter enable service instance 98 ethernet 98 description Test encapsulation dot1q 98 rewrite ingress tag pop 1 symmetric l2protocol forward bridge-domain 98 ! ! interface GigabitEthernet4/19 description Test mtu 1998 ip arp inspection limit none no ip address logging event link-status load-interval 30 speed auto storm-control broadcast level 50.00 storm-control multicast level 50.00 storm-control action trap no keepalive no cdp enable spanning-tree bpdufilter enable service instance 98 ethernet 98 description Test encapsulation dot1q 98 rewrite ingress tag pop 1 symmetric l2protocol forward bridge-domain 98 ! Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 5 Route Switch Processor 720 10GE (Activ RSP720-3C-10GE SAL15034YJ5 2 4 7600 ES+T 76-ES+T-4TG SAL1642QEM8 4 40 7600 ES+T 76-ES+T-40G SAL1626F93K Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ----- ------------- ------------ ------- 1 c89c.1dfb.49d4 to c89c.1dfb.49db 1.2 12.2(33r)SR 15.3(3)S Ok 2 30f7.0d8d.6cf0 to 30f7.0d8d.6cff 1.6 12.2(33r)SRD 15.3(3)S Ok 4 2c54.2d55.03e0 to 2c54.2d55.043f 1.5 12.2(33r)SRD 15.3(3)S Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 7600-PFC3C-10GE SAL1635LLKF 1.1 Ok 1 C7600 MSFC4 Daughterboard 7600-MSFC4 SAL1635LMFQ 7.0 Ok 2 7600 ES+ DFC XL 7600-ES+3CXL SAL1642QBWL 1.3 Ok 2 7600 ES+T 4x10GE XFP ITU 76-ES+T-4TGQ SAL1642QDQ8 1.2 Ok 4 7600 ES+ DFC XL 7600-ES+3CXL SAL1619C67K 1.2 Ok 4 7600 ES+T 40x1GE SFP 76-ES+T-40GQ SAL1619C762 1.2 Ok We have two "Workarounds" found. First is to stay with 15.3.1-S2 which keeps some other bugs unsolved. Second is applying service-policies to our service instances. After applying an ingoing and outgoing service-policy on both interfaces, IPv6 is a live again.. - Holger L _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
