11-29-2011 05:38 AM - edited 03-04-2019 02:27 PM
hi all,
i've ran into an issue on one of our EBGP peer and discovered the command "ip verify unicast source reachable-via rx" blocked their incoming traffic when their prefix is not advertised to us.
#sh run int vl473
Building configuration...
Current configuration : 257 bytes
!
interface Vlan473
ip address 203.x.x.x 255.255.255.252
ip verify unicast source reachable-via rx >>>
ip flow ingress
service-policy input INGRESS-45M
service-policy output EGRESS-45M
end
i've found the link below but i would appreciate if someone could explain it how it relates to BGP. thanks in advance!
http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html
Solved! Go to Solution.
12-01-2011 09:26 AM
John
I do not believe that Reverse Path Forwarding check relates specifically to BGP. What it does is to make sure that packets received on an interface are not "spoofed" and it does this by checking to see if the path to the source address does use this interface as the way to get to that source network. From what you are describing the source address of the BGP peer is through that interface but not in the connected subnet. Is that correct?
So what is happening seems to be that the RPF check is denying their traffic when their prefix is not advertised to you. And if their traffic is being denied then they can not establish the neighbor relationship that is necessary to advertise their prefix to you.
In most implementations of RFP there is an option to use an access list in the command. The access list gives exceptions which should be allowed even if they fail the RPF check. That would seem to be the best solution if it is available in your version of code.
HTH
Rick
12-01-2011 09:26 AM
John
I do not believe that Reverse Path Forwarding check relates specifically to BGP. What it does is to make sure that packets received on an interface are not "spoofed" and it does this by checking to see if the path to the source address does use this interface as the way to get to that source network. From what you are describing the source address of the BGP peer is through that interface but not in the connected subnet. Is that correct?
So what is happening seems to be that the RPF check is denying their traffic when their prefix is not advertised to you. And if their traffic is being denied then they can not establish the neighbor relationship that is necessary to advertise their prefix to you.
In most implementations of RFP there is an option to use an access list in the command. The access list gives exceptions which should be allowed even if they fail the RPF check. That would seem to be the best solution if it is available in your version of code.
HTH
Rick
12-01-2011 10:32 PM
hi rick,
thanks for your feedback! yes, what you've described is exactly correct.
i also believe it has nothing to do with BGP. probably this command line is some sort of anti-spoof or security feature.
i'll consider tagging an ACL for this.
12-01-2011 11:54 AM
Allow ip or just icmp from your source address, create a acl as Richard suggests.
access-list 101 permit ip ( source ip + wildcard mask ) any
or
access-list 101 permit icmp ( source ip + wildcard mask ) any
interface Vlan473
ip verify unicast source reachable rx 101
res
Paul
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide