BNG - question on "arp learning disable"

[matthew.almen]

Can someone tell me why it is recommended that dynamic arp learning be disabled on the access-interface in BNG?  Here's a link to the documentation

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/bng/configuration/guide/b-bng-cg53xasr9k/b-bng-cg53xasr9k_chapter_0101.html

All I can see in the documentation is the recommendation but there is no explanation for it.  My l2connected DHCP sessions are working with or without the command but it makes it harder to troubleshoot whether a customer is actually connected and working or not when there is no arp entry to look for.  Is this just recommended so the router does not have to learn ARP for each subscriber to save resources?  We're migrating off an old 10008SSG to 9006s running BNG and I'm debating whether to turn it off or not.  Is there a different reason in IOS-XR or BNG in general that this should be turned off?

Another thing to note is my subnet l2connected sessions (where a customers IPV4 gateway resides directly on the subinterface) do NOT work with arp learning disable applied to the subinterface.  I'm assuming since it doesn't use ip unnumbered it needs to have arp to find the remote connected devices like normal.  If anyone can shed some light on this I would appreciate it.  Thanks, Matt

[Aleksandar Vidakovic]

hi Matt,

it is about saving resources. This document should help:

https://supportforums.cisco.com/document/12766486/troubleshooting-arp-asr9000-routers

Let me know if you have more questions.

regards,

/Aleksandar

[xthuijs]

yeah in addition for subscribers, we have no need to "learn" the arp entries because for the downstream, that is bng to subscriber, we can use the DHCP binding, all the info is there.

as part of speed of learning on normal, non subscriber interfaces, when we see a new mac we can associate that with an ip on the upstream direction and insert it in the ARP table in case we need to go downstream.

since this opens the door for arp poisoning, we decided a more secure implementation for subsribers to leverage the dhcp binding in both directions.

upstream: mac/ip/access interace match? accept packet

downstream: use mac from dhcp binding

this way a malicious user (or application like ettercap) that wants to become the default gateway and route packets THROUGH him to SEE everything will never fly.

so yeah, we dont really need to learn arp entries, so lets save the mem resources.

gotta love it :)

cheers!

xander

[matthew.almen]

Yes that is a great step for security.  Thanks for the explanation.  Just for clarification is DHCP ("initiator dhcp" for subscriber sessions) a requirement for using the command arp learning disable? 

The reason I ask is we have a bunch of sub interfaces terminating smaller ipv4 subnets like /29s and /30s for static customers.  They work fine with "ipsubscriber ipv4 l2-connected initiator uncalssified-source" for sessions but if I apply the arp learning disabled command that's recommended in the documentation to these interfaces they stop working.  Is that expected behavior or should the subinterfaces that don't utilize DHCP just not be configured with arp learning disable?

Thanks, Matt

[xthuijs]

hi matt,

correct, you need either snooping (l2) or proxy (l3) to maintain the binding.

while snooping/proxy consume resources maintaining that binding since they are stateful (as opposed to relay, whereby it is just dhcp packet forwarding really), they also allow for that extra check of the forwarding engine to leverage that binding info.

with that said, if you use proxy or snooping, you dont need arp learning, or better said, the learnt arp info is not used anyway. you could make a nice snooky capture from that by verifying the learnt arp dbase to the proxy/snoop list and if there is a discrepancy you found a possible hacker :).

arp learning is like mac learning. we associate a port with a mac (mac learning) whereas arp learning is associating an ip addr with a mac. but if we know the mac/ip combo already (by bindign) there is no need for me to learn this and might as well skip that phase :)

since ip subs without dhcp like the unclassified source, there is no binding, and we likely need to arp for the destination etc.

if you have static subs, consider conveting them to a dhcp model but handing out static adds either from dhcp OR using radius with framed-ip-addresss/netmask

that way you have bindigns, provide static addresses and can leverage the security proxy provides.

regards

xander

[matthew.almen]

Thanks for all the infomation! 

Would it cause any problems with BNG if we were to remove the command so enable arp learning is enabled?  We have 5000 customers connecting to the router using BNG sessions.

[xthuijs]

when you have bng ip subs, there is really no need for arp learning, because on upstream (that is cpe to bng) we only respond with our default gateway, and we are not listening/updating the subscriber mac with the ip anyway

and on down stream we dont arp because we use the dhcp binding (yeah nice eh! :) for the path to the sub.

xander

[smeftahi]

Great thread !

Typically on access layer, I would deploy DAI and DHCP snooping.  What is best practice deployment in scenarios where I have no management over access layer and Opt82 is not used ?

I am looking at additional security on top of subscriber ACLs.

For now, all what I have to go with is C-Tag/S-Tag and access technology can be a combo of FTTH or PON.