show bgp route all Output

R4.67 # show bgp route all
Routes:
Destination
Peer
Next-Hop
LPref
Weight
MED
AS-Path
----------------------------------------------------------------------------
*>i 192.51.100.0/28
10.0.0.1
10.0.0.1
100
1
0
64500
*>i 192.51.100.16/28
10.0.0.1
10.0.0.1
100
1
0
64500
*>i 192.51.100.32/28
10.0.0.1
10.0.0.1
100
1
0
64500
*>i 192.51.100.48/28
10.0.0.1
10.0.0.1
100
1
0
64500
*>i 192.51.100.64/28
10.0.0.1
10.0.0.1
100
1
0
64500
*>i 203.0.113.1/32
10.0.0.1
192.168.2.66
100
1
0
64500
Flags: (*) Preferred BGP route, (>) Active, (d) Suppressed, (h) History
(s) Stale, (m) Multipath, (u) Unfeasible
Origin: (?) Incomplete, (e) EGP, (i) IGP
BGP Route Statistics
Total Rxed Routes : 6
Feasible Routes : 6
Active Routes : 6
Rejected Routes : 0
Unfeasible Routes : 0
Route Statistics on Session Type
Routes from Int Peer: 0
Routes from Ext Peer: 6
Switch.68 # rtlookup 203.0.113.1
Ori  Destination      Gateway         Mtr  Flags        VLAN      Duration
#be  203.0.113.1/32   192.168.2.66    1   UG-D---um--f BH_VLAN   0d:1h:5m:5s
Note

Note

For the above solution, the edge routers, R1 through R4, may still export the route to the target network to external AS(s), but the traffic is dropped at the edge of the provider network.

An alternative solution for protecting the network is to perform step 1 only on a designated sink router, (R5 in the following figure) and redistributes the black hole next-hop using iBGP to R2 through R4. When traffic arrives at routers R2 through R4, it is forwarded to R5, since R2–R4 have iBGP routes that resolve the black hole next-hop to R5. Router R5 then discards the traffic.