[c-nsp] xconnect problem between C7606

[Holger L]

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