Routing

Hello,

I'm looking for a way to announce a /32 route to a MX80 router so it can be readvertised to EBGP peers but

it can't affect the forwarding table.

I want to use it to trigger blackholling of specyfic hosts on specified EBGP peers networks (by announcing a /32 with a specified community) without altering local routing to those hosts.

Will announcing a route with MX80 ip as a next-hop achive that ?

I think it won't be installed but will id be readvertized ?

Alternativly I was thinking about using a separate routing instance to trap announced black holling routes in a separate not used for forwarding table and a rob grout to export it to EBGP peers but I'm not 100% sure it will work.

-- 

Michal Grzedzicki

Hi,

It looks like you want to implement destination based remote-triggered black holes.

You should agree on a community inside your AS and use that community to identify those routes to blackhole. Apply an import policy on your MX80 matching on that community and change the next-hop to discard. This way incoming traffic on your edge will be discarded. next-hop reject would cause ICMP unreachables which will consume CPU so you must avoid it.

policy-options {
  policy-statement blackhole-traffic {
    term 1 {
      from {
        protocol bgp;
        type internal;
        community blackhole
      }
      then {
        next-hop discard;
      }
    }
  }
  community blackhole members 100:666;
}

And that /32 route will be active and will be readvertised to your EBGP by default. You can also decice to delete the blackhole internal community and add another one as you agreed with your peer AS.

--

If this post solves your problem, please mark this post as "Accepted Solution".
Kudos are appreciated.

Thank You for the answer, Yes I want implement destination based remote-triggered black holes, but with a twist.

For exaple

my local network is 10.10.0.0/24 advertised to the MX80 router by a core switch using OSPF

ISP 1 ==bgp== MX80 ===bgp==ISP 2

                            | 10.0.0.1/24

                            |

                         OSPF

                            |

                            | 10.0.0.2/24

                    CORE SWITCH -10.10.0.1/24

ISP 1 will black hole routes with community 123:666.

i Want to advertise 10.10.0.10/32 with community 1234:666 to MX80 by bgp from some internal peer, so it will readvertise this route only to ISP 1.

I need 10.10.0.10/32 still be rechable from ISP 2 and this is impossible if I import 10.10.0.10/32 directly and apply next-hop discard to it. Next-hop for 10.10.0.0/24 network is dynamic and I dont want to specify static next-hoop address for the 10.10.0.10/32 route.

I need MX80 to readvertize this route to some peers (this is easy) but don't install this route in to the forwarding engine and for 10.10.0.10 use less specyfic 10.10.0.0/24 route advertized by core

The route table on MX80 should be

10.10.0.10/32 next-hop discard [not installed]

10.10.0.10/24 next-hop 10.0.0.2

packets from iSP 2 for 10.10.0.10 should be forwarded to 10.0.0.2 not discarded

packets from iSP 1 for 10.10.0.10 should be discarded (ISP 2 got 10.10.0.10/32 with community 123:666)

In that case you should forget the "then next-hop discard" and the import policy.

I hope you trust ISP1 : it will be him that enforces the policy to black-hole some traffic based on the community 123:666.

I would create two distinct BGP export policies for each ISP.
Routes you received internally tagged with your own black-hole community are readvertised to ISP1 with the community 123:666.
Those routes can have any next hop of your choice : as long as they are active on the MX80 they can be readvertised.
To ISP2 you just don't even need to export those routes.

You can also prevent those routes from being installed in the PFE on the MX80.

routing-options {
  forwarding-table {
    export export-forwarding-table;
  }
}
policy-options {
  policy-statement export-bgp-isp1 {
    term 1 {
      from {
        protocol bgp;
        type internal;
        community blackhole-internal
      }
      then {
	community delete blackhole-internal;
        community add blackhole-isp1;
	accept;
      }
    }
    term 2 {
      from {
        protocol ospf;
      }
      then {
	 accept;
      }
    }
  }
  policy-statement export-bgp-isp2 {
    term 1 {
      from {
        protocol bgp;
        type internal;
        community blackhole-internal
      }
      then {
	reject;
      }
    }
    term 2 {
      from {
        protocol ospf;
      }
      then {
	accept;
      }
    }
  }
  policy-statement export-forwarding-table {
    term 1 {
      from {
        community blackhole-internal
      }
      then {
	 reject;
      }
    }
    term 2 {
      then {
	accept;
      }
    }
  }
  community blackhole-internal members 100:666;
  community blackhole-isp1 members 123:666;
}

Now if you don't trust ISP1 to enforce the black-holing of the traffic we can do it by ourselves:

I suggest to

1. as in my first post ensure that your IBGP tagged routes are imported and apply then next-hop discard
2. make sure you advertise those tagged routes only to ISP1, something like my second post. ISP2 don't need them
3. create two distinct forwarding routing-instances. One for each ISP.
   • Populate the routing-instance associated with ISP1 with all routes
   • Populate the routing-instance associated with ISP2 with all routes but the tagged ones
4. apply input FW filters on your interfaces towards your ISP to route the traffic toward the corresponding routing-instance

For the routing-instances part it shoud be something like that:

routing-instances {
  FBF-ISP1 {
    instance-type forwarding;
    routing-options {
      instance-import IMPORT-FOR-ISP1;
    }
  }
  FBF-ISP2 {
    instance-type forwarding;
    routing-options {
      instance-import IMPORT-FOR-ISP2;
    }
  }
}
firewall {
  family inet {
    filter from-ISP1 {
      term 1 {
        then routing-instance FBF-ISP1;
      }
    }
    filter from-ISP2 {
      term 1 {
        then routing-instance FBF-ISP2;
      }
    }
  }
}
routing-options {
  interfaces-routes {
    rib-group inet populate-both-FBF;
  }
  rib-groups {
    populate-both-FPF {
      import-rib [ inet.0 FBF-ISP1.inet.0 FBF-ISP2.inet.0 ];
    }
  }
}
policy-options {
  policy-statement IMPORT-FOR-ISP1 {
    term 1 {
      from {
        instance master;
      }
      then accept;
    }
  }
  policy-statement IMPORT-FOR-ISP2 {
    term 1 {
      from {
        instance master;
        community blackhole-internal;
      }
      then reject;
    }
    term 2 {
      from {
        instance master;
      }
      then accept;
    }
  }
  community blackhole-internal members 100:666;
}

--> I didn't test this solution. Let me know if it works.

--
If this post solves your problem, please mark this post as "Accepted Solution".
Kudos are appreciated.

Actually the routing-instance for the ISP1 is not necessary.

Yes, it will use the default inet.0

Thank You !

This was the thing I was looking for

We want to nullroute at upstream providers to avoid our downlink congestion.

routing-options {
  forwarding-table {
    export export-forwarding-table;
  }
}