BGP Security
Lab file
Startup configs
IP addressing, OSPF, and BGP are already configured.
Currently eBGP is not up between CE1 and R1, nor between CE2 and XR3. Use an MD5 authentication string of asn-101 for the CE1/R1 session, and asn-102 for the CE2/XR3 session. Only configure the SP equipment. The neighborship will not come up. Proceed to step 2 anyways.
Configure TTL security on each eBGP session, using a maximum hop of 1.
Ensure that R1 and XR3 receive three prefixes each on the eBGP session.
Currently R1 and XR3 only know BGP routes learned via their eBGP sessions. Why is this? Fix it so that all SP routers know all three prefixes.
5. Configure R1 and XR3 to send a default route to the CE, but they should do this without having a default route present in the RIB. The CEs should receive only a default route and no other prefixes.
CE1 should now be able to ping CE2.
6. On XR3, only allow CE2 to advertise two prefixes, but don’t bring down the session if CE2 advertises more than this. On R1, only allow CE1 to advertise two prefixes and do bring down the session if this is exceeded. On CE1, remove the advertisement for 101.1.3.0/24.
Dropping Traffic
7. Configure destination-based RTBH within the SP network and drop traffic destined for 101.1.1.1 at the edge.
A trace from CE2 should not even make it one hop:
8. Remove the destination-based RTBH and configure source-based RTBH for 102.1.2.1.
CE2 should be able to ping 101.1.1.1 from the other loopback that is being accepted by XR3 (in my case, lo3) but not from lo2.
9. Remove all RTBH configuration on all routers. Drop traffic sourced from 101.1.2.1 using flowspec. (You will have to enable flowspec and peer the SP BGP speakers over flowspec first. Keep in mind that XR3 cannot run flowspec locally on interfaces due to being an XRv).
CE1 should be able to ping CE2 using Lo1 but not Lo2:
Answers
Use neighbor x.x.x.x password to use MD5 authentication
Use neighbor x.x.x.x ttl-security hops 1
Add a PASS_ALL route policy to XR3 and apply it inbound for routes received from CE2.
Use next-hop-self on R1 and XR3 on the peering session with the RR (XR2). Additionally configure each peer as a RR client on XR2.
On R1 you need two commands, default-information originate and neighbor x.x.x.x default-originate. On XR3 you just need the default-originate under the neighbor. Additionally, configure a route-map that only permits 0/0 and is applied outbound on R1. You have to soft clear out. XR3 already doesn’t have an outbound route-policy so you could leave it as-is.
On R1, use neighbor x.x.x.x maximum-prefix 2 and fix CE1 to only advertise two routes. IOS-XR allows you to use discard-extra-paths which keeps the session up. Use neighbor x.x.x.x address-family ipv4 uni maximum-prefix 2 discard-extra-paths.
On all SP routers, add a static null route such as 192.0.2.0/24 null0. On XR2, add another static route for 101.1.1.1 via 192.0.2.0 with some tag (such as 666) and redistribute statics with this tag into BGP.
On XR2, remove the 101.1.1.1/32 route and add 102.1.2.1/32. On XR3 configure uRPF loose-mode to drop the traffic based on the source address.
On all routers, remove all static routes. Technically, because XR3 does not support flowspec at the edge, you can only enable flowspec on R1 and XR2. On R1 locally-install for all interfaces. Enable peering on the ipv4 flowspec address-family between R1 and XR2. On XR2 configure a flowspec policy that matches source 101.1.2.1/32 and drops it. See the Flowspec article for configuration details.
Last updated
