ASR9010 BNG ROUTE ISSUE

[Elvin Gilleard]

Hi folks,

deplyoing BNG IOS XR 4.3.1 we are able to establish pppoe session between CPE and BNG with radius and without it. All customer traffic is terminating into the correct vrf but no able to route traffic to internet. the vrf is receiving a default route to internet, also an ip address from the pool is configured into a loopback interface, and pingable from internet, but no CPE is able to reach internet. any workaround or recomendation to solve the issue?

[xthuijs]

Hi Elvin,

Following up to your email message. Stripped some sensitive data out.

This onfig looks fine! This should work. When pinging the CPE from the BNG, you may need to define and specify the source address specifically as the soruce selection sometimes is not right.

So do a "ping vrf INET form the BNG with "source loop 1" as suffix to force the right source addr selection.

Can the CPE ping the loopback properly?

If we can eliminate those 2 it will help.

Also when you have a rapid ping running with a timeout 0 and count 10000 we can track the np counters to see where we lose them.

MAke sure that SVD is disabled also especially when you have an MPLS core.

Your original message:

Ping from the BNG to the internet  is possible, also from the internet is possible to ping the interface  loopback configured. pppoe request reach the BNG and authentication is  succesfull. The weird thing is that none CPE is able to reach the  internet as well no ping response from the BNG to CPE. CPE reach BNG  through a L2 transport using vlan. One more thing I notice is that the  Mac address from all CPE is the same. I made a mac lookup and the mac  address of all CPE is the DSLAM mac. maybe this is the reason no ping is  possible from BNG to CPE.

Below is the configuration for pppoe session as well how I advertise the pool.

Thanks in advance.

aaa group server radius RADIUS

vrf INET

server-private x.y.46.147 auth-port 1645 acct-port 1646

  key 7

!

source-interface Loopback1

!

aaa authorization subscriber default group radius group RADIUS

aaa authentication subscriber default group radius group RADIUS

pool vrf INET ipv4 ADDRESS_POOL

address-range x.y.241.50 x.y.241.62

interface Loopback1

vrf INET

ipv4 address x.y.241.49 255.255.255.255

interface TenGigE0/0/1/1

description Link to 30MZ_PE_3 TenG 1/2 Layer L2

cdp

!

interface TenGigE0/0/1/1.600

service-policy type control subscriber PPPoE_Policy

pppoe enable bba-group CUSTOMER

encapsulation dot1q 600

router bgp 65500

vrf INET

  rd 1:1

  address-family ipv4 unicast

   network x.y.241.49/32

   aggregate-address x.y.241.48/28 summary-only

dynamic-template

type ppp PPP_PTA_TEMPLATE

  ppp authentication pap

  ppp ipcp dns p.q.81.5 p.q.81.132

  ppp ipcp peer-address pool ADDRESS_POOL

  vrf INET

  ipv4 unnumbered Loopback1

subscriber

pta tcp mss-adjust 1452

!

pppoe bba-group CUSTOMER

service selection disable

Class-map type control subscriber match-any PTA_CLASS

match protocol ppp

end-class-map

!

!

policy-map type control subscriber PPPoE_Policy

event session-activate match-first

  class type control subscriber PTA_CLASS do-until-failure

   10 authenticate aaa list default

  !

!

event session-start match-first

  class type control subscriber PTA_CLASS do-until-failure

   1 activate dynamic-template PPP_PTA_TEMPLATE

  !

Need  a bit more info to say what the reason is... it could be sVD is acting  up, is a ping from the BNG to the internet possible, is the ip pool  advertised properly into the internet vrf,

if there are traffic drops, the np counters should be easy to verify what is going on also.

verify with a upstream test/traceroute and downstream and see where it stops.

common  forgotten things is routing of the ip pool subnet and SVD when packets  are arriving on the core facing LC not having enough info to route the  traffic through (make a dummy, fake subinterface on that core LC, with  some addr in that same vrf to workaround that)

xander

[Elvin Gilleard]

Hi Alexander,

I tried ping using the correct vrf and source loopback1 before write on this forum with no success result. No ping response from CPE when pinging from BNG as well in reverse. I also did the "show route vrf subscriber" and I'm able to see the subscriber route installed in the vrf.

Below is the svd state result.

ROUTER#sh svd state

Selective VRF Download (SVD) Feature State:

SVD Configuration State        Unsupported

SVD Operational State          Unsupported

ROUTER#sh svd role 

Codes: (C) : user Configured role

Node Name       IPv4 Role                 IPv6 Role               

--------------------------------------------------------------------

0/RSP0/CPU0     Standard                  Standard                

0/RSP1/CPU0     Standard                  Standard                

0/0/CPU0        Standard                  Standard                

0/1/CPU0        Standard                  Standard

Best regards,

[xthuijs]

Elvin, looks like the SVD is already disabled, you're probably running 4.3.1.

what type of CPE do you have over there? if it is an IOS device, maybe we can do a debug ip icmp to see if we are getting the requests in.

Also lets not forget to trace the np counters when traffic is sent in either direction, this can be super useful when you're pining with a timeout of zero and a high count as that will give a defined rate on the np counters that we can track for the loss.

regards

xander

[xthuijs · Accepted solution]

hey wait a minute, I am looking at the config again and I see you are trying to terminate the subs on the phy interface.

this would mean that the ppp and iedge runs on the LC, that is currently not supported yet.

you need to move it to a bundle config.

interface TenGigE0/0/1/1.600

service-policy type control subscriber PPPoE_Policy

pppoe enable bba-group CUSTOMER

encapsulation dot1q 600

See for the config example here:

https://supportforums.cisco.com/docs/DOC-23170#Bundles_vs_Phyiscal_interfaces

can you give that a try and let us know?

xander

[Elvin Gilleard]

Hi,

You are correct, after moving the config to bundle interface everything in running ok. I will keep playing customizing features for pppoe clients.

Best regards,

[xthuijs]

Elvin, glad to hear that that was the issue and that things are working now as we expect.

There are some good deployment guides on the support forums for bng that might be of use for these type of cases.

regards

xander