[c-nsp] Strange cache flow seen on SB release for PPPoE/A connections

[Andy Saykao]

Hi All,
 
Another interesting thing about the SB release we're using has to do
with flows.
 
After upgrading to the SB release (12.2(31)SB13) on a few production
7301 routers we noticed the usage was down for our PPPoE/A customers
connecting to that router. Based on historical data, one PPPoE/A
business customer would download 1-2G/day but after the upgrade to the
SB release, they are now only doing 200-300M/day. Further investigation
showed that the SB release were sending some flows to Null as the
destination interface and this is probably why flows were not being
collected properly.
 
Here's an example of what I mean with me downloading something using the
SB release.
 
router#sh ip cache flow | inc 210.15.230.84
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP
Pkts
Gi0/0.11      216.239.113.224 Vi3.2         210.15.230.84   06 0050 0753
1
Gi0/0.11      216.239.122.60  Null          210.15.230.84   06 0050 0792
6199
Vi3.2         210.15.230.84   Gi0/0.11*     216.239.122.60  06 0792 0050
3206
Vi3.2         210.15.230.84   Gi0/0.11      216.239.122.60  06 0792 0050
3206
Vi3.2         210.15.230.84   Gi0/0.11      216.239.113.224 06 0753 0050
2
Vi3.2         210.15.230.84   Gi0/0.11*     216.239.113.224 06 0753 0050
2
 
You can see that a download from 216.239.122.60 is being sent to the
Null interface instead of to the Virtual-Access interface. And looking
at our collector, no flows were collected for this download session.
Also not sure why there appears to be duplicate flows, one with w/o a
STAR and one with a STAR for some flows.
 
We thought it might have something to do with the Virtual-Template as we
were use to having "ip route-cache flow" enabled on it. But the SB
release removes this command.
 
Our PPP config looks like this:
 
bba-group pppoe global
 virtual-template 2
!
interface GigabitEthernet0/1.21
 description DSLAM VLAN
 encapsulation dot1Q 21
 ip flow ingress
 pppoe enable group global
!
interface Virtual-Template2
 bandwidth 1500
 ip unnumbered Loopback0
 ip flow ingress
 ip tcp adjust-mss 1412
 peer default ip address pool PPP-ADSL
 ppp mtu adaptive
 ppp authentication chap pap PPPCustomers
 ppp authorization PPPCustomers
 ppp accounting PPPCustomers
 ppp chap hostname PPP-VIC

What we then discovered was that with the SB release we needed to add
"ip flow egress" to the Virtual-Template to be able to capture flows
properly. I had read somewhere that this appears to be work around for
not being able to have "ip route-cache flow" on the Virtual-Template.
 
Flows appear to be collecting properly now with both "ip flow ingress"
and "ip flow egress" applied to the Virtual-Template. We're seeing two
flows now, one going to Null and another going to the correct
Virtual-Access interface for my download from 216.239.113.112. Without
the "ip flow egress" in the Virtual-Template, the flow would go just to
the Null interface.
 
router#sh ip cache flow | inc 210.15.230.84
Gi0/0.11      74.80.127.24    Vi3.2         210.15.230.84   06 0050 0AC6
1
Gi0/0.11      74.80.127.24    Vi3.2*        210.15.230.84   06 0050 0AC6
1
Gi0/0.11      216.239.113.112 Vi3.2*        210.15.230.84   06 0050 0B13
6199
Gi0/0.11      216.239.113.112 Null          210.15.230.84   06 0050 0B13
6199
Vi3.2         210.15.230.84   Gi0/0.11      74.80.127.24    06 0AC6 0050
1
Vi3.2         210.15.230.84   Gi0/0.11      216.239.113.112 06 0B13 0050
3166
 
I'm still puzzled as to what the STAR means in the flow and why there
appears to be two "duplicate" flows. Any ideas??? This is also a PE
router so not sure if MPLS has anything to do with it.
 
Also, as discussed above we've had to apply both "ip flow ingress" and
"ip flow egress" to the Virtual-Template for flows to be collected
properly. How should I be collecting flows on the Virtual-Template??

Thanks in advance.
 
Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.