[j-nsp] ISG dropping BGP Keepalives

[Jason Dearborn]

After a few more rounds with JTAC, it appears the problem lies with
the core not properly switching BGP packets destined for it's own
loopback address.    Troubleshooting with Force 10 has indicated a
potentially new FTOS bug.

Thanks for all the replies, both on and off-list.

Jason Dearborn

2009/4/30 Pavel Lunin <plunin at senetsy.ru>:
>
> Hi Jason,
>
> Unfortunately the information you provided is not really helpful :)
>
> All the cases with unexpected packet dropping are usually tied with wrong
> policy, zones or routing.
> So you should consider those things as well as provide them here to be more
> informative.
>
> But I believe, instead of theoretical research, the best way to resolve you
> trouble is to use a sort of brute force method called debug :)
>
> Here are the commands you need:
>
> set ff src-ip <peer1> dst-ip <peer2>
> set ff src-ip <peer2> dst-ip <peer1>
>
> clear db
> debug flow basic
> get db stream
>
> Than you should see all the packet processing steps for particular packets
> matched against flow filters configured above. If you see any "packet
> dropped" notification, than the answer is a line or two above it.
>
> Than type 'undeb all' or just press escape and two times 'uns ff' to clear
> flow filters.
>
> --
> Pavel
>
> Jason Dearborn wrote:
>>
>> When the firewall is in single-armed mode, BGP keepalives for sessions
>> that traverse the firewall appear to be filtered out, resulting in
>> session flapping.  If I put the firewall in a two-armed configuration,
>> BGP sessions traversing the firewall are stable.
>>
>> Policies are all set to "allow any any"
>>
>> Example:
>>
>> FAIL: peer1 -> ISG_eth2.1 -> ISG_ethe2.2  -(L2 via peer1)-> peer2
>>
>> SUCCESS: peer1 -> - ISG_ethe2.1 -> ISG_ethe3.1 -> peer2
>>
>>
>> JTAC has been slow to respond and fairly unhelpful so far.
>>
>> I'm happy to send a simple arch diagram or further clarification to
>> off-list replies.
>>
>