[c-nsp] Cisco 4900M and Layer2 Broadcasts

[Chris Marget]

Your case reminds me of something Tim Stevenson said about N7K and IPv4
multicast.

I don't remember the details exactly, but he left me with the impression
that the L2 filtering stuff for multicast frames, which usually doesn't do
*exactly* what you want (subscribe to 239.1.2.3 and you'll get L2 traffic
for 239.2.2.3 as well) was "fixed" on N7K: It filters/forwards at L2 using
L3 criteria.

Your problem is almost exactly the other way around. Sorry I don't have any
answers, thanks for filling me in on the application. It makes sense that
these crazy frames are generated by a "magic box" HA setup.

Good luck, and please follow up with the list if TAC gives you anything
helpful..

/chris


On Mon, Jun 30, 2014 at 4:21 PM, Ivan <cisco-nsp at itpro.co.nz> wrote:

> Hi Chris,
>
> The traffic is some kind of state replication mechanism between to
> geographically diverse appliances.  My guess is that the appliances are
> sending layer 3 headers inside layer 2 broadcast over the HA vlan.
>
> Someone asked out the config - can't get much more simpler.  Also remember
> is working fine for IPv6.
>
> Ingress port:
>
> interface GigabitEthernet2/13
>  switchport trunk allowed vlan 327
>  switchport mode trunk
>  switchport nonegotiate
>  mtu 9198
>  load-interval 30
>  flowcontrol receive off
>  flowcontrol send off
>  no cdp enable
>  spanning-tree portfast trunk
>  spanning-tree bpdufilter enable
>
> Egress port (same device for testing):
>
> interface TenGigabitEthernet2/7
>  switchport access vlan 327
>  switchport trunk allowed vlan none
>  switchport mode access
>  switchport nonegotiate
>  mtu 9198
>  load-interval 30
>  flowcontrol receive off
>  flowcontrol send off
>  no cdp enable
>
> Also the counters someone was suggesting looking at;
>
> AKNNR-ISP-SW1#show int counters detail | in 2/13|Port
> Port                     InBytes       InUcastPkts      InMcastPkts
> InBcastPkts
> Gi2/13              222183306824                 0                0
>  2114072064
> Port                    OutBytes      OutUcastPkts     OutMcastPkts
>  OutBcastPkts
> Gi2/13                 682063116                 0            61300
> 5592900
> Port                   InPkts 64        OutPkts 64    InPkts 65-127
> OutPkts 65-127
> Gi2/13                         0                 1       2106943835
> 5103190
> Port              InPkts 128-255   OutPkts 128-255   InPkts 256-511
> OutPkts 256-511
> Gi2/13                   7128226            551009                0
>       0
> Port             InPkts 512-1023  OutPkts 512-1023
> Gi2/13                         0                 0
> Port            InPkts 1024-1518 OutPkts 1024-1518 InPkts 1519-1548
> OutPkts 1519-1548
> Gi2/13                         0                 0                0
>       0
> Port            InPkts 1549-9216 OutPkts 1549-9216
> Gi2/13                         0                 0
> Port            Tx-Bytes-Queue-1  Tx-Bytes-Queue-2 Tx-Bytes-Queue-3
> Tx-Bytes-Queue-4
> Gi2/13                   4413448                 0                0
>       0
> Port            Tx-Bytes-Queue-5  Tx-Bytes-Queue-6 Tx-Bytes-Queue-7
> Tx-Bytes-Queue-8
> Gi2/13                         0                 0                0
> 677643104
> Port            Tx-Drops-Queue-1  Tx-Drops-Queue-2 Tx-Drops-Queue-3
> Tx-Drops-Queue-4
> Gi2/13                         0                 0                0
>       0
> Port            Tx-Drops-Queue-5  Tx-Drops-Queue-6 Tx-Drops-Queue-7
> Tx-Drops-Queue-8
> Gi2/13                         0                 0                0
>       0
> Port            Dbl-Drops-Queue-1 Dbl-Drops-Queue-2 Dbl-Drops-Queue-3
> Dbl-Drops-Queue-4
> Gi2/13                          0                 0                 0
>           0
> Port            Dbl-Drops-Queue-5 Dbl-Drops-Queue-6 Dbl-Drops-Queue-7
> Dbl-Drops-Queue-8
> Gi2/13                          0                 0                 0
>           0
> Port              Rx-No-Pkt-Buff     RxPauseFrames    TxPauseFrames
> PauseFramesDrop
> Gi2/13                         0                 0                0
>       0
> Port            UnsupOpcodePause
> Gi2/13                         0
>
> Have logged a support case so hopefully can report back more soon.
>
> Thanks
>
> Ivan
>
> On 1/Jul/2014 1:20 a.m., Chris Marget wrote:
>
>> Hi Ivan,
>>
>> Your L2 broadcast / L3 unicast traffic has piqued my curiosity.
>>
>> Can you share some details about the use case for this unusual traffic?
>>
>> I have a project in mind where I'll be doing exactly the opposite: IPv4
>> multicast in Ethernet unicast.
>>
>> My use case is a multicast application with an un-graceful startup. If
>> the application restarts mid-day, there's a long delay while it collects
>> state information from incoming multicast packets. There is no mechanism
>> for priming this application - the only option right now is to wait
>> while the infrequent state messages re-build the state database. I plan
>> to cache incoming state data in an L2 adjacent server, and blast this
>> traffic at any instances which have recently restarted. I can't mess
>> with the traffic at all because it's cryptographically signed by the
>> sender, and I have to do it with unicast frames because the anti-replay
>> mechanisms mean it's trouble if I deliver these packets to the wrong box.
>>
>> Thanks!
>>
>> /chris
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>