The configuration snippets provided for conformance check only, they are not intended as the implementation guidance. Specific set of features depend on the specific platform that is being used. Not all the products may support these features.

Description for Scenarios

ScenarioProgrammeAction

Scenario 1 Filtering

Network Operators

Action1. Prevent propagation of incorrect routing information

CDN & Cloud Providers

Scenario 2 Anti-spoofing

Network Operators

Action 2: Prevent traffic with spoofed source IP addresses

CDN & Cloud Providers

Action 2. Prevent traffic with illegitimate source IP addresses

Scenario 3 Filtering (IXP)

IXPs

Action 1. Prevent propagation of incorrect routing information. (Route Server)

Scenario 4 Protect L2 (IXP)

IXPs

Action 3. Protect the peering platform (layer 2)

Implementation of MANRS Action 1

Scenario 1 Filtering

Creating filters based on prefix lists: 
ip prefix-list PL-CUSTOMER-4
    seq 1 permit 192.0.2.0/24
!
ipv6 prefix-list PL-CUSTOMER-6
    seq 1 permit 2001:db8:1001::/48
!
route-map PREFIX permit 10
   match ip address prefix-list PL-CUSTOMER-4
!
route-map PREFIX permit 20
   match ipv6 address prefix-list PL-CUSTOMER-6
!
route-map PREFIX deny 65535
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 route-map PREFIX in
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 route-map PREFIX in

---- OR ----

ip prefix-list PL-CUSTOMER-4
    seq 1 permit 192.0.2.0/24
!
ipv6 prefix-list PL-CUSTOMER-6
    seq 1 permit 2001:db8:1001::/48
!
router general
   control-functions
      code
      function CUSTOMER() {
return (
            ( prefix match prefix_list_v4 PL-CUSTOMER-4 ) or
            ( prefix match prefix_list_v6 PL-CUSTOMER-6 )
);
      }
      EOF
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 rcf in CUSTOMER()
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 rcf in CUSTOMER()
Creating filters based on as-path: 
ip as-path access-list CUSTOMER permit 65000 any
!
route-map ASPATH permit 10
   match ip address prefix-list PL-CUSTOMER-4
!
route-map ASPATH permit 20
   match ipv6 address prefix-list PL-CUSTOMER-6
!
route-map ASPATH deny 65535
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 route-map ASPATH in
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 route-map ASPATH in

---- OR ----

ip as-path access-list CUSTOMER permit 65000 any
!
router general
   control-functions
      code
      function CUSTOMER() {
         return as_path match as_path_list CUSTOMER;
      }
      EOF
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 rcf in CUSTOMER()
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 rcf in CUSTOMER()
Creating filters based on RPKI: 
route-map RPKI deny 10
   match origin-as validity invalid
!
route-map RPKI permit 20
   match origin-as validity valid
   set local-preference 200
!
route-map RPKI permit 30
   match origin-as validity not-found
   set local-preference 100
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 route-map RPKI in
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 route-map RPKI in

---- OR ----

router general
   control-functions
code
function RPKI_CHECK() {
if rpki.origin_as_validity is ROA_VALID {
local_preference = 200;
return true;
}
if rpki.origin_as_validity is ROA_NOT_FOUND {
local_preference = 100;
return true;
}
if rpki.origin_as_validity is ROA_INVALID {
return false;
}
return true;
}
EOF
!
router bgp 65530
   address-family ipv4
      neighbor 192.168.230.1 activate
      neighbor 192.168.230.1 rcf in RPKI_CHECK()
!
   address-family ipv6
      neighbor fc00::1 activate
      neighbor fc00::1 rcf in RPKI_CHECK()
Applicability: 
Arista EOS / Platform independent

Scenario 2 Anti-spoofing

Creating filters based on prefix lists: 
Strict mode:
ip verify unicast source reachable-via rx
ipv6 verify unicast source reachable-via rx


Strict mode w/ default route:
ip verify unicast source reachable-via rx allow-default
ipv6 verify unicast source reachable-via rx allow-default

Loose mode:
ip verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
Implementing source address validation using access lists: 
ip access-list customer1-in-ipv4
   10 permit ip 192.0.2.0/24 any
   65000 deny ip any any
!
ipv6 access-list customer1-in-ipv6
   10 permit ipv6 2001:db8:1001::/48 any
   65000 deny ipv6 any any
!
interface EthernetX
   ip access-group customer1-in-ipv4 in
   ipv6 access-group customer1-in-ipv6 in
Applicability: 
Arista EOS / 7050X2/X3 and 7280R/R2/R3 series

Enabling uRPF might come with certain limitations around route scale. Additional configuration can be required on R/R2/R3 series devices. Please consult your Arista Account Team for more details and which type of configuration is best for your setup.

Scenario 4 Protect L2 (IXP)

Creating controls preventing unwanted traffic: 
mac access-list CUSTOMER
  10 remark !! IPv4 Multicast
  11 deny any 01:00:5e:00:00:00 00:00:00:7f:ff:ff log
  20 remark !! IPv6 Link-Local and Neighbor Discovery
  21 permit any 33:33:ff:00:00:00 00:00:00:ff:ff:ff
  30 remark !! IPv6 Multicast
  31 deny any 33:33:00:00:00:00 00:00:ff:ff:ff:ff log
  40 remark !! Allowed traffic on IXP
  41 permit 12:34:12:34:12:34 00:00:00:00:00:00 any arp
  42 permit 12:34:12:34:12:34 00:00:00:00:00:00 any ip
  43 permit 12:34:12:34:12:34 00:00:00:00:00:00 any ipv6
  1000 remark !! Deny all other
  1001 deny any any log

interface EthernetX
   mac access-group CUSTOMER in
Applicability: 
Arista EOS / 7050X2/X3 and 7280R/R2/R3 series

Implementation of MANRS Action 2

Describe your implementation of Action 2-1:

Action 2-1 status: Planned

Describe your implementation of Action 2-2:

Action 2-1 status: Implemented

Describe your implementation of Action 2-3:

Action 2-1 status: Implemented

Describe your implementation of Action 2-4:

Action 2-1 status: Planned

Why Arista Networks Supports MANRS

For Arista, security is a key attribute of our overall solution, starting at the routing perimeter for worldwide Internet resiliency. As a global industry leader in cloud networking, we want to take part in the efforts to secure the Internet as well. MANRS is providing great guidelines to achieve that goal and Arista Networks is proud to be a founding participant of the MANRS Vendor Program.

Ashwin Kohli Senior Vice President, Customer Engineering for Arista Networks