Solved: Why this prefix-list does not block incoming traffic?

news2010a · ‎07-27-2009

Hi there, I reviewed this multiple times, but I still can't understand why my prefix-list does not block ingress traffic from neighbor 150.1.0.2.

EdgeRouter---ISP2 (150.1.0.2)

Can you help me find what I am missing? I already did 'clear ip bgp *' and result is still the same.

Please find attached config and output from show ip bgp.

Giuseppe Larosa · ‎07-27-2009

Hello Marlon,

yes it is correct unless you use a feature called ORF that sends your inbound filter to peer you still see 10/8 as a received route but it is not installed in BGP table.

Edge#show ip bgp neig 150.1.0.2 received-routes

BGP table version is 15, local router ID is 172.16.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 10.0.0.0 150.1.0.2 0 0 387 i <==== This prefix is still in my route table in spite of my prefix-list deny 10.0.0.0/8

the right place to check is the local node BGP table that is seen with sh ip bgp.

you have achieved your objective

Hope to help

Giuseppe

View solution in original post

Chetan Kumar Ress · ‎07-27-2009

Plz show the configuration

ccaptari · ‎07-27-2009

Try to soft clear the neighbor

clear ip bgp 150.1.0.2 in

The filtering will not be applied to anything that is already in the routing table. After modifying the prefix lists you need to clear the neighbors

Follow up: sorry i saw that you indeed cleared the neighbors.

You may try to soft clear the neighbor and try a

debug ip bgp updates in

This usually gives you valuable information.

news2010a · ‎07-27-2009

I did the clear the neighbors.

Then after starting 'debug ip bgp updates in' on my Edge router I see:

(...)

Edge#

18:22:23: BGP(0): no valid path for 10.0.0.0/8

(...)

Then I do show ip bgp and I see that on Edge the 10.0.0.0/8 no longer appears - OK that's what I want.

Then if I do Edge#show ip bgp neig 150.1.0.2 received-routes I se the 10.0.0.0/8. My understanding is that is correct because it was the route sent by the ISP router, but it was filtered on my ingress interface on Edge router so it no longer gets installed on the Edge BGP routing table.

If understand this output right, problem is solved!!!

Thanks!!

Giuseppe Larosa · ‎07-27-2009

Hello Marlon,

yes it is correct unless you use a feature called ORF that sends your inbound filter to peer you still see 10/8 as a received route but it is not installed in BGP table.

Edge#show ip bgp neig 150.1.0.2 received-routes

BGP table version is 15, local router ID is 172.16.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 10.0.0.0 150.1.0.2 0 0 387 i <==== This prefix is still in my route table in spite of my prefix-list deny 10.0.0.0/8

the right place to check is the local node BGP table that is seen with sh ip bgp.

you have achieved your objective

Hope to help

Giuseppe

news2010a · ‎07-27-2009

Hi, partial configuration was on attachment but I am sending the full config for Routers Edge and Primary just to make sure.

Giuseppe Larosa · ‎07-27-2009

Hello Marlon,

in your prefix-list last line is:

seq 35 permit 0.0.0.0/0 le 24

what is the objective of this line?

this allows each prefix less specific then /24 or /24

if you want to allow only a default route you need to use a line like

seq 35 permit 0.0.0.0/0

without any le or ge parameters

Hope to help

Giuseppe

news2010a · ‎07-27-2009

Hey Giuseppe, that was to fulfill this requirement:

â€¢ Never accept prefixes longer than /24

news2010a · ‎07-27-2009

Hi, partial configuration was on attachment but I am sending the full config for Routers Edge and Primary just to make sure.

Peter Paluch · ‎07-28-2009

Hello,

Can you please try to remove the command

neighbor 150.1.0.2 soft-reconfiguration inbound

from your BGP configuration and do the "clear ip bgp *"? This command forces your router to maintain both UNFILTERED and FILTERED database of routes sent to you from the neighbor 150.1.0.2. That might perhaps be responsible for the 10.0.0.0/8 still lurking in your BGP table. This "soft reconfiguration" was a kludge before Route Refresh message was added to BGP but as far as I know, all recent BGP implementations support it so there is no reason to use the soft reconfiguration feature.

Best regards,

Peter