> Today.. I only have one ISP and uRPF works fine with this syntax

> -> ” ip verify unicast source reachable-via any 2699″

> I’m moving to a router with multiple  ISP and IX connections and some of our traffic is now asymmetric.

The above uRPF config didn’t work and was removed.

 

Does the router have a default-route? If so, “ip verify unicast source reachable-via any allow-default” should accomplish what you want.

 

If the router is default-free, is it not able to receive reachability information from the rest of your network for the prefixes that are getting incorrectly dropped? (assuming that was the symptoms of “didn’t work”)

 

Finally, what are the contents of access-list 2699? I assume it’s a whitelist of IPs to not drop traffic from, even if there aren’t discrete routes in the routing table for?

> Finally, what are the contents of access-list 2699? I assume it’s a

> whitelist of IPs to not drop traffic from, even if there aren’t

> discrete routes in the routing table for?

 

I’d forgotten about that option – always a bad idea, as it causes performance issues.

Allow-default is useful in circumstances where a default is present – it essentially renders the uRPF ‘S/RTBH-only’

 

This should work, but there’s little detail provided.

 

Did you configure it on both of the uplinks?

How did you monitor the drops and concluded that it ‘didn’t work’?

How you get the default route, is it pointing on one of the uplinks? ‘allow-default’ may be important here.

 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 

Usually it is done on the same session, and the customer adds a special community for blackhole routes.

 

The method I saw was:

 

1) add a null route for a private or test address (e.g. 192.0.2.1/32) on each router.

2) enable ‘ip verify unicast source reachable-via any’ on edge interfaces so that traffic in both directions is dropped for a null-routed prefix.

3) add a route-map that looks for your special community and changes the next hop for those prefixes to 192.0.2.1 (also to make sure that the prefix belongs to that customer, and that the mask length is not too small (e.g. >28))

 

Here’s an example for a different purpose, but basically the same idea:

 

http://www.team-cymru.org/bogon-reference-bgp.html

 

This method also allows you to republish the same blackhole prefix to your upstream providers if they support it, too (e.g. Level3 use community 3356:9999 for blackhole) to stop the traffic before it fills your upstream link.

-=-==-=-=-=–=

You want to just provide a community for your customer to tag which will take the route and change the next hop to null 0.  The idea here if URPF loose mode is enabled you can take any route that your customer tags with the appropriate community, set it’s next hop to null0 and as a result drop the traffic at your edges where you implement this action.

 

There’s a good all be it JunOS example of configuration in the RFC itself and a ton available via google for Cisco.

 

The basic idea is very simple though and just requires changing next hop when a tag is presented.

 

 

 

> Hi

>

> I have a network with ~10 router cisco with the full table BGP.

> I want add for my customer a blackhole possibility.

>

> Anyone have a tuto for this ?

>

> i think’s add a second bgp session with my customer and when he sent a

> prefix in this session, that put a route null on all of my router,

> it’s possible ?

>

 

Does the MPLS ping works between the two routers? -that would verify that the transport (i.e. LDP) labels for PE loopbacks are in place.

ping mpls ipv4 x.x.x.x/32 source y.y.y.y

 

Try cmd ” sh mpls forwarding-table” on both PEs and try to search for each other’s loopback IP /32 address.

On each PE -for the other PEs loopback in Outgoing Label column there should either be a “label value” or a “Pop Label” if the PEs are directly connected.

If it displays No Label then labels are not advertised/received for some reason.

-most of the times the problem is that LDP neighbours don’t see each other via Hello messages multicasted over the directly connected interface but only via the targeted LDP session.

– this can be caused when the interface is not enabled for MPLS i.e. cmd “mpls ip” is not enabled under the interface.

– or LDP passwords do not match.

(this will also be accompanied by OSPF advertising maximum metric for the link to avoid forwarding of MPLS packets over the link when the MPLS is actually not functional on the interface).

 

-or there’s a problem with access-list controlling the label advertisement on the neighbouring router.

 

-if the above is not the case it might be a HW programing issue.

The outgoing label for the other PE’s loopback IP address should be visible when you issue cmd “sh ip cef x.x.x.x/32 detail” *not sure about the exact syntax.