Tag: Juniper

Migrating to BGP-Free Core in Juniper Environment

Discussion on how to migrate to BGP-Free Core by deploying MPLS as network tunneling mechanism. Document provides step-by-step migration steps for a Juniper-based network.  
Continue reading “Migrating to BGP-Free Core in Juniper Environment”

Juniper High Availability Customer Site using AS-Prepend

Configuring Dual-CE BGP High Availability Site. This article provides Juniper Configuration Example that uses BGP AS-Prepend to identify primary and secondary paths.
Continue reading “Juniper High Availability Customer Site using AS-Prepend”

Advertising Aggregates Routes

As a BGP admin, you will often need to make decisions on the ways to partition your IP Space, which routes to advertise to the Internet and which routes to suppress.

Ideally, you’d want to aggregate your IPv4/IPv6 Space as much as possible, by only advertising aggregate prefixes (also known as supernets and summary routes) to the Internet. Practically, this would mean that your Autonomous System (AS) will originate IP prefixes assigned to you by Regional Internet Registries (RIRs) or delegated to you by Upstream Providers, while suppressing all other advertisements. If everybody were to follow this rule, the Internet routing table would be much smaller and we would not have issues with FIB exhaustion.
Continue reading “Advertising Aggregates Routes”

Juniper Configuration Blueprint – Single-Homed CE Device with EBGP

Introduction

In this example, we will show recommended configuration for a Single-homed Single CE device using private AS with an upstream ISP. It is assumed that management of this device will be performed from a dedicated server residing within Customer’s Network.

This type of setup is quite common in an environment where a dedicated firewall performing source NAT function is setup to protect customer infrastructure.

Single-homed CE Device with EBGP
Single-homed CE Device with EBGP.

Please note, that the Management Station is connected directly to the LAN interface for illustration purpose only. In real production deployments it must be protected by a firewall.

BGP Configuration

BGP configuration can be split in the following tasks:

  • Accept the default route from the ISP while discarding all other advertisements that might be sent to your CE
  • Advertise your subnet (120.0.30.0/24) while making sure that no other routers are erroneously injected
  • Secure BGP session by configuring a MD5 key

 

The actual configuration is comprised of the following blocks:

  1. Configure Local AS Number:
set routing-options autonomous-system 65001 
  1. Configure Two prefix lists – one with the subnet you’ll advertise upstream and the other one with the default route you’ll be receiving from your ISP:
set policy-options prefix-list LocallyOriginated 120.0.30.0/24

set policy-options prefix-list Default 0.0.0.0/0
  1. Create Policy Statements for the locally originated and default route:
set policy-options policy-statement Direct-To-BGP term 10 from protocol direct

set policy-options policy-statement Direct-To-BGP term 10 from prefix-list LocallyOriginated

set policy-options policy-statement Direct-To-BGP term 10 then accept

set policy-options policy-statement Direct-To-BGP term 999 then reject

set policy-options policy-statement Default term 10 from prefix-list Default

set policy-options policy-statement Default term 10 then accept

set policy-options policy-statement Default term 999 then reject
  1. Configure BGP Group for your Upstream ISP. Configure the “export” statement to advertise your 120.0.30.0/24 subnet to the Internet and “import” statement to receive the default route. Configure MD5 Authentication Key. Make sure the description field includes the Circuit ID assigned to your link and ISP’s contact phone so you would not need to search for this information in an event of an outage.
set protocols bgp log-updown

set protocols bgp group ISP-AS100 type external

set protocols bgp group ISP-AS100 import Default

set protocols bgp group ISP-AS100 authentication-key "$9$9UPDt0IylMNdsEcds24DjCtu"

set protocols bgp group ISP-AS100 export Direct-To-BGP

set protocols bgp group ISP-AS100 peer-as 100

set protocols bgp group ISP-AS100 neighbor 120.0.4.9 description "ISP FastAccess: Circuit GD8AJ12B: ISP NOC 800-111-2222"

Securing the Router

Next step is to secure the router itself. But default, it will pass any traffic (with some exceptions, not covered in this article) and accept connections from anywhere on the Internet. Your job is to make sure that only trusted sources can communicate with your device (control plane protection) and spoofed traffic is not allowed in and out of your network (data plane protection).

Data Plane Protection

We’ll start with the data plane, where we need to take care of packets leaving your network and packets coming in.

In our example, we were assigned a single IP subnet to be used within our network – 120.0.30.0/24. As such, we should only allow traffic originated from this network as well our ISP-facing WAN interface to go out. There are a few ways to achieve this goal – configure uRFP on LAN interface, inbound firewall filter on LAN, or outbound filter on WAN. We’ll use the latter approach by setting up outbound WAN filter:

set firewall family inet filter accept-local term 10 from source-address 120.0.30.0/24

set firewall family inet filter accept-local term 10 then accept

set firewall family inet filter accept-local term 20 from source-address 120.0.4.10/32

set firewall family inet filter accept-local term 20 then accept

set firewall family inet filter discard-any term 10 then discard

set interfaces ge-0/0/1 unit 0 family inet filter output-list accept-local

set interfaces ge-0/0/1 unit 0 family inet filter output-list discard-any

We also need to make sure that the traffic coming from the Internet has a valid source IP. As we do not receive the full BGP feed from our upstream provider and cannot rely on uRPF, we will need to configure static filter that will discard all known “bad” sources also known as Martian blocks, while allowing all other traffic in:

set firewall family inet filter discard-martian term rfc919 from source-address 255.255.255.255/32

set firewall family inet filter discard-martian term rfc919 then discard

set firewall family inet filter discard-martian term rfc1122 from source-address 0.0.0.0/8

set firewall family inet filter discard-martian term rfc1122 from source-address 127.0.0.0/8

set firewall family inet filter discard-martian term rfc1122 from source-address 240.0.0.0/4

set firewall family inet filter discard-martian term rfc1122 then discard

set firewall family inet filter discard-martian term rfc1918 from source-address 10.0.0.0/8

set firewall family inet filter discard-martian term rfc1918 from source-address 172.16.0.0/12

set firewall family inet filter discard-martian term rfc1918 from source-address 192.168.0.0/16

set firewall family inet filter discard-martian term rfc1918 then discard

set firewall family inet filter discard-martian term rfc2544 from source-address 198.18.0.0/15

set firewall family inet filter discard-martian term rfc2544 then discard

set firewall family inet filter discard-martian term rfc3171 from source-address 224.0.0.0/4

set firewall family inet filter discard-martian term rfc3171 then discard

set firewall family inet filter discard-martian term rfc3927 from source-address 169.254.0.0/16

set firewall family inet filter discard-martian term rfc3927 then discard

set firewall family inet filter discard-martian term rfc5736 from source-address 192.0.0.0/24

set firewall family inet filter discard-martian term rfc5736 then discard

set firewall family inet filter discard-martian term rfc5737 from source-address 192.0.2.0/24

set firewall family inet filter discard-martian term rfc5737 from source-address 198.51.100.0/24

set firewall family inet filter discard-martian term rfc5737 from source-address 203.0.113.0/24

set firewall family inet filter discard-martian term rfc5737 then discard

set firewall family inet filter discard-martian term rfc6598 from source-address 100.64.0.0/10

set firewall family inet filter discard-martian term rfc6598 then discard 

set firewall family inet filter accept-any term 10 then accept

set interfaces ge-0/0/1 unit 0 family inet filter input-list discard-martian

set interfaces ge-0/0/1 unit 0 family inet filter input-list discard-local

set interfaces ge-0/0/1 unit 0 family inet filter input-list accept-any

Control Plane Protection

While it is important to discard malicious traffic that tries to pass through your router, it is even more important to drop bad packets destined to your infrastructure device. All router-bound traffic must be dropped unless it comes from a known and trusted source. In our example, we can trust ISP’s PE router as we’ll be establishing EBGP session with that device and dedicated server (120.0.30.10) used for device management. We will also allow Ping and Traceroute packets. Everything else will be dropped.

set firewall family inet filter accept-protocols term bgp from source-address 120.0.4.9/32

set firewall family inet filter accept-protocols term bgp from protocol tcp

set firewall family inet filter accept-protocols term bgp from port bgp

set firewall family inet filter accept-protocols term bgp then accept

set firewall family inet filter accept-management term ssh from source-address 120.0.30.10/32

set firewall family inet filter accept-management term ssh from source-address 192.168.3.0/24

set firewall family inet filter accept-management term ssh from protocol tcp

set firewall family inet filter accept-management term ssh from destination-port ssh

set firewall family inet filter accept-management term ssh then accept

set firewall family inet filter accept-management term snmp from source-address 120.0.30.10/32

set firewall family inet filter accept-management term snmp from protocol udp

set firewall family inet filter accept-management term snmp from destination-port snmp

set firewall family inet filter accept-management term snmp then accept

set firewall family inet filter accept-management term ntp from source-address 120.0.30.10/32

set firewall family inet filter accept-management term ntp from protocol udp

set firewall family inet filter accept-management term ntp from port ntp

set firewall family inet filter accept-management term ntp then accept

set firewall family inet filter accept-management term dns from source-address 120.0.30.10/32

set firewall family inet filter accept-management term dns from protocol udp

set firewall family inet filter accept-management term dns from protocol tcp

set firewall family inet filter accept-management term dns from source-port 53

set firewall family inet filter accept-management term dns then accept

set firewall family inet filter accept-monitoring term icmp from protocol icmp

set firewall family inet filter accept-monitoring term icmp from icmp-type echo-reply

set firewall family inet filter accept-monitoring term icmp from icmp-type echo-request

set firewall family inet filter accept-monitoring term icmp from icmp-type time-exceeded

set firewall family inet filter accept-monitoring term icmp from icmp-type unreachable

set firewall family inet filter accept-monitoring term icmp from icmp-type parameter-problem

set firewall family inet filter accept-monitoring term icmp then accept

set firewall family inet filter accept-monitoring term traceroute-udp from protocol udp

set firewall family inet filter accept-monitoring term traceroute-udp from destination-port 33435-33450

set firewall family inet filter accept-monitoring term traceroute-udp then accept

set firewall family inet filter discard-any term 10 then discard

 

These filters will be applied to Lo0 interface (Juniper’s Control plane interface).

set interfaces lo0 unit 0 family inet filter input-list accept-protocols

set interfaces lo0 unit 0 family inet filter input-list accept-management

set interfaces lo0 unit 0 family inet filter input-list accept-monitoring

set interfaces lo0 unit 0 family inet filter input-list discard-any

Complete Router Configuration

Configuration in Set Format:

set system host-name CE3-Downstream3

set system domain-name bgphelp.com

set system time-zone America/New_York

set system no-redirects

set system root-authentication encrypted-password "abc"

set system name-server 120.0.30.10

set system login user bgphelp uid 2000

set system login user bgphelp class super-user

set system login user bgphelp authentication encrypted-password "abc"

set system services ssh root-login deny

set system services ssh protocol-version v2

set system syslog user * any emergency

set system syslog host 120.0.30.10 any info

set system syslog file messages any any

set system syslog file messages authorization info

set system syslog file interactive-commands interactive-commands any

set system ntp server 120.0.30.10

set interfaces ge-0/0/1 description "'CE3->PE2'"

set interfaces ge-0/0/1 unit 0 family inet filter input-list discard-martian

set interfaces ge-0/0/1 unit 0 family inet filter input-list discard-local

set interfaces ge-0/0/1 unit 0 family inet filter input-list accept-any

set interfaces ge-0/0/1 unit 0 family inet filter output-list accept-local

set interfaces ge-0/0/1 unit 0 family inet filter output-list discard-any

set interfaces ge-0/0/1 unit 0 family inet address 120.0.4.10/30

set interfaces ge-0/0/2 description "LAN Segment"

set interfaces ge-0/0/2 unit 0 family inet address 120.0.30.1/24

set interfaces lo0 unit 0 family inet filter input-list accept-protocols

set interfaces lo0 unit 0 family inet filter input-list accept-management

set interfaces lo0 unit 0 family inet filter input-list accept-monitoring

set interfaces lo0 unit 0 family inet filter input-list discard-any

set snmp location MarsDC:BAY12334:U123

set snmp contact "IP NOC 1-345-12-1234"

set snmp community f0ryoureyesonly clients 120.0.30.10/32

set snmp trap-group all version v2

set snmp trap-group all targets 120.0.30.10

set routing-options autonomous-system 65001

set protocols bgp log-updown

set protocols bgp group ISP-AS100 type external

set protocols bgp group ISP-AS100 import Default

set protocols bgp group ISP-AS100 authentication-key "$9$9UPDt0IylMNdsEcds24DjCtu"

set protocols bgp group ISP-AS100 export Direct-To-BGP

set protocols bgp group ISP-AS100 peer-as 100

set protocols bgp group ISP-AS100 neighbor 120.0.4.9 description "ISP FastAccess: Circuit GD8AJ12B: ISP NOC 800-111-2222"

set policy-options prefix-list LocallyOriginated 120.0.30.0/24

set policy-options prefix-list Default 0.0.0.0/0

set policy-options policy-statement Default term 10 from prefix-list Default

set policy-options policy-statement Default term 10 then accept

set policy-options policy-statement Default term 999 then reject

set policy-options policy-statement Direct-To-BGP term 10 from protocol direct

set policy-options policy-statement Direct-To-BGP term 10 from prefix-list LocallyOriginated

set policy-options policy-statement Direct-To-BGP term 10 then accept

set policy-options policy-statement Direct-To-BGP term 999 then reject

set security forwarding-options family mpls mode packet-based

set firewall family inet filter discard-martian term rfc919 from source-address 255.255.255.255/32

set firewall family inet filter discard-martian term rfc919 then discard

set firewall family inet filter discard-martian term rfc1122 from source-address 0.0.0.0/8

set firewall family inet filter discard-martian term rfc1122 from source-address 127.0.0.0/8

set firewall family inet filter discard-martian term rfc1122 from source-address 240.0.0.0/4

set firewall family inet filter discard-martian term rfc1122 then discard

set firewall family inet filter discard-martian term rfc1918 from source-address 10.0.0.0/8

set firewall family inet filter discard-martian term rfc1918 from source-address 172.16.0.0/12

set firewall family inet filter discard-martian term rfc1918 from source-address 192.168.0.0/16

set firewall family inet filter discard-martian term rfc1918 then discard

set firewall family inet filter discard-martian term rfc2544 from source-address 198.18.0.0/15

set firewall family inet filter discard-martian term rfc2544 then discard

set firewall family inet filter discard-martian term rfc3171 from source-address 224.0.0.0/4

set firewall family inet filter discard-martian term rfc3171 then discard

set firewall family inet filter discard-martian term rfc3927 from source-address 169.254.0.0/16

set firewall family inet filter discard-martian term rfc3927 then discard

set firewall family inet filter discard-martian term rfc5736 from source-address 192.0.0.0/24

set firewall family inet filter discard-martian term rfc5736 then discard

set firewall family inet filter discard-martian term rfc5737 from source-address 192.0.2.0/24

set firewall family inet filter discard-martian term rfc5737 from source-address 198.51.100.0/24

set firewall family inet filter discard-martian term rfc5737 from source-address 203.0.113.0/24

set firewall family inet filter discard-martian term rfc5737 then discard

set firewall family inet filter discard-martian term rfc6598 from source-address 100.64.0.0/10

set firewall family inet filter discard-martian term rfc6598 then discard

set firewall family inet filter discard-local term 10 from source-address 120.0.30.0/24

set firewall family inet filter discard-local term 10 then discard

set firewall family inet filter accept-any term 10 then accept

set firewall family inet filter accept-local term 10 from source-address 120.0.30.0/24

set firewall family inet filter accept-local term 10 then accept

set firewall family inet filter accept-local term 20 from source-address 120.0.4.10/32

set firewall family inet filter accept-local term 20 then accept

set firewall family inet filter discard-any term 10 then discard

set firewall family inet filter accept-protocols term bgp from source-address 120.0.4.9/32

set firewall family inet filter accept-protocols term bgp from protocol tcp

set firewall family inet filter accept-protocols term bgp from port bgp

set firewall family inet filter accept-protocols term bgp then accept

set firewall family inet filter accept-management term ssh from source-address 120.0.30.10/32

set firewall family inet filter accept-management term ssh from source-address 192.168.3.0/24

set firewall family inet filter accept-management term ssh from protocol tcp

set firewall family inet filter accept-management term ssh from destination-port ssh

set firewall family inet filter accept-management term ssh then accept

set firewall family inet filter accept-management term snmp from source-address 120.0.30.10/32

set firewall family inet filter accept-management term snmp from protocol udp

set firewall family inet filter accept-management term snmp from destination-port snmp

set firewall family inet filter accept-management term snmp then accept

set firewall family inet filter accept-management term ntp from source-address 120.0.30.10/32

set firewall family inet filter accept-management term ntp from protocol udp

set firewall family inet filter accept-management term ntp from port ntp

set firewall family inet filter accept-management term ntp then accept

set firewall family inet filter accept-management term dns from source-address 120.0.30.10/32

set firewall family inet filter accept-management term dns from protocol udp

set firewall family inet filter accept-management term dns from protocol tcp

set firewall family inet filter accept-management term dns from source-port 53

set firewall family inet filter accept-management term dns then accept

set firewall family inet filter accept-monitoring term icmp from protocol icmp

set firewall family inet filter accept-monitoring term icmp from icmp-type echo-reply

set firewall family inet filter accept-monitoring term icmp from icmp-type echo-request

set firewall family inet filter accept-monitoring term icmp from icmp-type time-exceeded

set firewall family inet filter accept-monitoring term icmp from icmp-type unreachable

set firewall family inet filter accept-monitoring term icmp from icmp-type parameter-problem

set firewall family inet filter accept-monitoring term icmp then accept

set firewall family inet filter accept-monitoring term traceroute-udp from protocol udp

set firewall family inet filter accept-monitoring term traceroute-udp from destination-port 33435-33450

set firewall family inet filter accept-monitoring term traceroute-udp then accept

Configuration in Curly Braces Format:

system {
 host-name CE3-Downstream3;
 domain-name bgphelp.com;
 time-zone America/New_York;
 no-redirects;
 root-authentication {
  encrypted-password "abc"; ## SECRET-DATA
 }
 name-server {
  120.0.30.10;
 }
 login {
 user bgphelp {
  uid 2000;
  class super-user;
  authentication {
   encrypted-password "abc"; ## SECRET-DATA
  }
 }
}
services {
 ssh {
  protocol-version v2;
 }
 netconf {
  ssh;
 }
}
syslog {
 user * {
  any emergency;
 }
 host 120.0.30.10 {
  any info;
 }
 file messages {
  any any;
  authorization info;
 }
 file interactive-commands {
  interactive-commands any;
 }
}
archival {
 configuration {
  transfer-on-commit;
  archive-sites {
   "scp://cfg:abc@192.168.3.210/home/cfg/config-backups/";
  }
 }
}
ntp {
 server 192.168.3.210;
 }
}
interfaces {
 ge-0/0/1 {
  description "'CE3->PE2'";
  unit 0 {
  family inet {
   filter {
    input-list [ discard-martian discard-local accept-any ];
    output-list [ accept-local discard-any ];
   }
   address 120.0.4.10/30;
  }
 }
}
 ge-0/0/2 {
  description "LAN Segment";
  unit 0 {
   family inet {
    address 120.0.30.1/24;
   }
  }
 }
 lo0 {
  unit 0 {
   family inet {
    filter {
    input-list [ accept-protocols accept-management accept-monitoring discard-any ];
    }
 }
 }
 }
}
snmp {
 location MarsDC:BAY12334:U123;
 contact "IP NOC 1-345-12-1234";
 community f0ryoureyesonly {
  clients {
  120.0.30.10/32;
  }
 }
 trap-group all {
  version v2;
  targets {
  120.0.30.10;
  }
 }
}
routing-options {
 static {
  route 192.168.74.0/24 {
  next-hop 192.168.3.18;
  no-readvertise;
  }
 }
 autonomous-system 65001;
}
protocols {
 bgp {
  log-updown;
  group ISP-AS100 {
   type external;
   import Default;
   authentication-key "$9$9UPDt0IylMNdsEcds24DjCtu"; ## SECRET-DATA
   export Direct-To-BGP;
   peer-as 100;
   neighbor 120.0.4.9 {
    description "ISP FastAccess: Circuit GD8AJ12B: ISP NOC 800-111-2222";
   }
  }
 }
}
policy-options {
 prefix-list LocallyOriginated {
  120.0.30.0/24;
 }
 prefix-list Default {
  0.0.0.0/0;
 }
 policy-statement Default {
  term 10 {
   from {
    prefix-list Default;
   }
  then accept;
 }
  term 999 {
   then reject;
  }
 }
 policy-statement Direct-To-BGP {
  term 10 {
   from {
    protocol direct;
    prefix-list LocallyOriginated;
    }
   then accept;
  }
  term 999 {
   then reject;
  }
 }
}
firewall {
 family inet {
  filter discard-martian {
   term rfc919 {
    from {
     source-address {
      255.255.255.255/32;
     }
    }
    then {
     discard;
    }
   }
   term rfc1122 {
    from {
     source-address {
      0.0.0.0/8;
      127.0.0.0/8;
      240.0.0.0/4;
     }
    }
    then {
     discard;
    }
   }
   term rfc1918 {
    from {
     source-address {
      10.0.0.0/8;
      172.16.0.0/12;
      192.168.0.0/16;
     }
    }
    then {
     discard;
    }
   }
   term rfc2544 {
    from {
     source-address {
      198.18.0.0/15;
     }
    }
    then {
     discard;
    }
   }
   term rfc3171 {
    from {
     source-address {
      224.0.0.0/4;
     }
    }
    then {
     discard;
    }
   }
   term rfc3927 {
    from {
     source-address {
      169.254.0.0/16;
     }
    }
    then {
     discard;
    }
   }
   term rfc5736 {
    from {
     source-address {
      192.0.0.0/24;
     }
    }
    then {
     discard;
    }
   }
   term rfc5737 {
    from {
     source-address {
      192.0.2.0/24;
      198.51.100.0/24;
      203.0.113.0/24;
     }
    }
    then {
     discard;
    }
   }
   term rfc6598 {
    from {
     source-address {
      100.64.0.0/10;
     }
    }
    then {
     discard;
    }
   }
  }
  filter discard-local {
   term 10 {
    from {
     source-address {
      120.0.30.0/24;
     }
    }
    then {
     discard;
    }
   }
  }
  filter accept-any {
   term 10 {
    then accept;
   }
  }
  filter accept-local {
   /* LAN Segment */
   term 10 {
    from {
     source-address {
      120.0.30.0/24;
     }
   }
   then accept;
  }
  /* Point-To-Point WAN Interface */
   term 20 {
    from {
     source-address {
      120.0.4.10/32;
     }
    }
    then accept;
   }
  }
  filter discard-any {
   term 10 {
    then {
     discard;
    }
   }
  }
  filter accept-protocols {
   term bgp {
    from {
     source-address {
      120.0.4.9/32;
     }
     protocol tcp;
     port bgp;
    }
    then accept;
   }
  }
  filter accept-management {
   term ssh {
    from {
     source-address {
      120.0.30.10/32;
      192.168.3.0/24;
     }
    protocol tcp;
    port ssh;
   }
   then accept;
  }
  term snmp {
   from {
    source-address {
     120.0.30.10/32;
    }
    protocol udp;
    destination-port snmp;
    }
   then accept;
   }
   term ntp {
    from {
     source-address {
      120.0.30.10/32;
     }
     protocol udp;
     port ntp;
    }
    then accept;
   }
   term dns {
    from {
     source-address {
      120.0.30.10/32;
     }
     protocol [ udp tcp ];
     source-port 53;
    }
    then accept;
   }
   term netconf {
    from {
     source-address {
      120.0.30.10/32;
      192.168.3.0/24;
     }
     protocol tcp;
     destination-port 830;
    }
    then accept;
   }
  }
  filter accept-monitoring {
   term icmp {
    from {
     protocol icmp;
     icmp-type [ echo-reply echo-request time-exceeded unreachable source-quench router-advertisement parameter-problem ];
    }
    then accept;
   }
   term traceroute-udp {
    from {
     protocol udp;
     destination-port 33435-33450;
    }
   then accept;
   }
  }
 }
}

 

Cisco / Juniper Troubleshooting Commands

 About This Document

This document provides a cheat sheet of commonly used troubleshooting commands used in Cisco and Juniper environments. The list is incomplete. Please send us a note if you want to contribute.

Management

Cisco IOS Juniper JunOS Description
show tech-support request support info
request support information | save /var/tmp/RSI.txt
file archive compress source RSI.txt destination RSI.txt.tgz		 Gather support info for vendor’s TAC
show hardware show chassis hardware Show hardware-related info
show version show system uptime Show system’s uptime
show processes cpu
show processes cpu sorted
show processes cpu history		 show chassis routing-engine
show system processes extensive
show system threads		 Verify CPU Utilization
show processes memory
show memory summary		 show system processes extensive
show task memory detail		 Verify Memory Utilization
dir bootflash: show system core-dumps Check for crash files / core dumps
dir file list Show directory structure
show system storage Verify available storage space
show users show system users List connected users
clear line X request system logout user ABC Disconnect user
start shell Enter Unix Shell
monitor traffic interface ge-0/0/1 Monitor traffic on the interface (will not show transit packets)
monitor traffic interface ge-0/0/1 write-file test.pcap Write control pacets into pcap file
show snmp mib walk .1.3.6.1.4.1.2636.3 Walk SNMP OID directly on a router
request system software rollback Request to the previous software version

L3 Routing

Static, Connected Routes and Routing Table

Cisco IOS Juniper JunOS Description
show ip route show route Show routing table
show ip cef show route forwarding-table Show forwarding table
show ip route connected show route protocol direct Show directly connected (attached) routes
show ip route static show route protocol static Show static routes
show route hidden Show hidden routes. Invalid route, e.g. route with unreachable next-hop will be marked as hidden

BGP

Cisco IOS Juniper JunOS Description
show ip bgp summary show bgp summary Show summary view of BGP neighbors
show ip bgp neighbor A.A.A.A advertised show route advertising-protocol bgp A.A.A.A Check routes advertised towards a peer
show ip bgp neighbor A.A.A.A received show route receive-protocol bgp A.A.A.A Check routes received from a peer
show ip bgp show route protocol bgp Check BGP routes

IS-IS

IOS IOS-XR JunOS Description
show clns interface show isis interface show isis interface Show IS-IS enabled interfaces
show clns neighbors show isis adjacency show isis adjacency Show protocol adjacencies
show clns traffic show isis statistics show isis statistics IS-IS statistics
show isis database show isis database show isis database Brief Database Information
show isis database verbose show isis database verbose show isis database extensive Detailed Database Information
show ip route isis show route isis show route protocol isis IS-IS learned routes
  show isis adjacency-log

 

show isis error-log

    IS-IS historical information

 

 

BGP Best Practices or Dissecting RFC 7454

In this article, we will focus on the RFC 7547. This RFC covers BGP Operations and Security best current practices and needs to be understood and implemented by any organization running BGP in production.

Introduction

RFC 7547 recommendations can be split into the following categories:

  • BGP Session Protection
  • Prefix Filtering Recommendations
  • AS-Path Filtering Recommendations
  • Next-Hop Filtering
  • Optional BGP Community Scrubbing
  • Traffic Filtering Recommendations

In this article, we will use Roman Numerals (I, II, etc) to identify BGP protection mechanisms, Arabic Numerals (1,2, etc) to identify Traffic Filtering, Uppercase Letters (A, B, etc) to identify Prefix Filtering, and Lowercase Letter (a,b, etc) to identify AS-Path filtering and Greek  Letters (α,   β)  to identify BGP scrubbing.

Figure below shows depicts peering routers connected to upstream, private, IXP and downstream peers.

RFC7454 Peering Router
RFC7454 Peering Router

As most of the modern routers do, our sample router has a dedicated forwarding engine responsible for forwarding packets and a dedicated routing engine responsible for participating in routing protocols, building Routing Information Base (RIB) and Forwarding Information Base (FIB) tables. While actual vendors’ implementations will vary between routers’ models, best practices discussed in this article are generic enough to be applicable to the majority of vendors.

BGP Protection

Group of BGP Protection mechanisms is responsible for maintaining stability of BGP sessions, as well as providing anti-spoofing and bogus route-injection protection mechanisms. We will also add “maximum-prefix” protection mechanism to this category, as it helps to protect against operators’ mistakes.

RFC7454 BGP Protection
RFC7454 BGP Protection

I. GTSM (TTL Security)

GTSM – Generalized TTL Security Mechanisms, also known as TTL security, defined in RFC 5082. GTSM (TTL Security) is a mechanism that checks TTL value of incoming IP Packets in order to make sure they have not been spoofed. Directly connected BGP peers will set IP TTL value to 255, making it impossible to deliver spoofed IP with TTL=255 packets via non-directly connected interfaces. As per section 5.2 of RFC 7454 GTSM should be implemented.

Configuration Examples:

II. TCP-AO (TCP Authentication Option)

TCP-AO – TCP Authentication Option is a stronger protection mechanism than traditionally used MD5, it is described in RFC 5925. At some point, it is expected to replace MD5 for session protection. It has not been widely adopted due to the lack of implementation from equipment vendors.

Section 5.1 of RFC 7454 recommends, although does not require, leveraging either MD5 or TCP-AO for session protection.

No configuration examples due to lack of vendors’ implementation. 

III. MD5

MD5 – Protection of the TCP session header, described in RFC 2385. MD5 is a TCP session protection mechanism that has been available for many years and is supported by the vast majority of equipment manufacturers. It has become the de-facto standard for BGP session protection. Although it has been made obsolete by TCP-AO protection, it is still used for the majority of BGP peering sessions.

Configuration Examples (Simple Key and Key-Chains):

IV. Max-Prefix

Maximum-Prefix Limit is one of the commonly used safety mechanisms that will bring down BGP session if the number of routes advertised by the peer exceeds pre-configured limit. Section 8 of RFC 7454 provides the following recommendations:

  • From public and private peers, it is recommended to have the limit set to either a lower than the number of routes on the Internet, or to a specific number for each peer based on the advertised number of routes plus some headroom. From the author’s experience, setting the number to below the number of routes on the Internet is too risky and should be avoided. There have been situations where public and private peers would make an error and leak the entire BGP table to their peering partners, causing major network instability. Author prefers setting session reset limit to 2x the number of routes normally advertised by the peer and session warning limit to 1.5x number of routes. Your NOC should monitor logs for warning threshold violations and adjust limits accordingly.
  • From upstream, the number of routes should be set higher than the number of routes on the Internet, but not higher that the capabilities of your routers. For example, if FIB tables of your devices can support up to 1 Million IPv4 routes, you can set the limit to be 950,000 routes. While resetting BGP sessions with your upstream providers is never a good thing, damage caused by reset is much lower than that caused by FIB exhaustion. For more information, please refer to our article on BGP Table Size analysis (http://www.bgphelp.com/2017/01/01/bgpsize/).

MD5, TCP-AO and GTSM have to be configured on both sides of the BGP session. Max-Prefix can be configured on one side only.

Prefix Filtering

Prefix-filtering policies are responsible for discarding bogus route-advertisements to and from BGP peers. Examples of these bogus advertisements are prefixes from RFC1918 address space, to specific routes (>24), unallocated prefixes.

RFC7454 Prefix Filtering
RFC7454 Prefix Filtering

Route-filtering should be implemented on each BGP session maintained by the service provider:

  • A. Private/Public/Transit Inbound Prefix Filtering
  • B. Private/Public/Transit Outbound Prefix Filtering
  • C. Downstream Inbound Prefix Filtering
  • D. Downstream Outbound Prefix Filtering

A. Inbound Prefix Filtering from Private/Public/Transit Peers

RFC 7475 provides similar recommendations for route filtering from Upstream Providers (section 6.2.3) and route-filtering from private and public peers (section 6.2.1). Because of this, there is very little difference in filtering policies, allowing us to combine them in one recommendation.

As per Section 6.2.1.1.1 of RFC 7475, the following prefixes should not be accepted from peers

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Unallocated Prefixes (RFC 7475 Section 6.1.2)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • Prefixes belonging to the local AS (RFC 7475 Section 6.1.4)
  • IXP LAN Prefixes (RFC 7475 Section 6.1.5), other than authorized ASes (RFC 7475 Section 6.1.5)
  • The Default Route (RFC 7475 Section 6.1.6)

Section 6.2.1.1.2 of RFC 7475 also provides recommendations for “Strict” inbound filtering option, which we consider to be too risky and will not cover in this document.

B. Outbound Prefix Filtering towards Private/Public/Transit Peers

As per Section 6.2.1.2 of RFC 7475, the following prefixes should not be accepted from peers

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • IXP LAN Prefixes (RFC 7475 Section 6.1.5)
  • The Default Route (RFC 7475 Section 6.1.6)

You also need to make sure that only authorized prefixes (those advertised by your AS and downstream customers) are being sent.

C. Inbound Prefix Filtering from Customers

General recommendations provided in Section 6.2.2.1 of RFC 7475 state that “only customer prefixes SHOULD be accepted, all others SHOULD be discarded.” The list of allowed prefixes should be manually built by the network provisioner after validating that customer prefixes are indeed allocated to the client by IP address management authorities.

In some cases, if customer advertises too many prefixes or has BGP clients of their own, customer-specific filters can be replaced with generic filters previously described in “Inbound Filtering from Private/Public/Transit Peers” section of the paper.

D. Outbound Prefix Filtering towards Customers

Depending on the customer preferences, they might want to receive

  • The default route only
  • Full Internet routing table
  • Subset of the Full Internet table (e.g. only the routes received via public and private peers, but not the transit routes)
  • The default route in addition to the Full or Partial Internet view

Generic recommendation described in Section 6.2.2.2 of RFC 7454 states that the following prefixes should not be sent to the customer:

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • The Default Route (RFC 7475 Section 6.1.6), for those customers not willing to receive it

AS-Path Filtering

Section 9 of RFC 7454 provides a number of AS-Path Filtering recommendations that should be implemented on upstream/private/public peering sessions and customer sessions.

RFC7454 AS Path Filtering
RFC7454 AS Path Filtering

Similar to how we analyzed Prefix Filtering recommendations in the previous chapter, we will review AS-Path Filtering recommendations below.

a. Inbound AS-Path Filtering from Private/Public/Transit Peers

Section 9 of RFC 7454 recommends the following:

  • Private AS numbers should not be accepted, unless used for special purposes such as black-hole origination
  • AS Paths with the first AS number not the one of the peer should not be accepted, unless originated by IXP’s router server
  • Do not accept your own AS number in the AS path

b. Outbound AS-Path Filtering from Private/Public/Transit Peers

Section 9 of RFC 7454 recommends the following:

  • Do not originate prefixes with nonempty AS Paths, unless you intend to provide transit for these prefixes
  • Do not originate prefixes with upstream AS numbers in the AS Path, unless you intend to provide transit to these prefixes
  • Do not advertise Private AS Paths, unless there is a special “private” arrangement with your peers

c. Inbound AS-Path Filtering from Downstream Customers

Section 9 of RFC 7454 recommends the following:

  • Only accept 2-byte and 4-byte AS paths containing ASNs belonging to the customer.
  • If this is not possible, accept only path lengths relevant to the type of the customer, while discourage excessive prepending
  • Do not accept your own AS number in the AS path

d. Outbound AS-Path Filtering from Downstream Customers

  • Do not advertise Private AS Paths, unless there is a special “private” arrangement with your customers

Next-Hop Filtering

BGP can advertise prefixes with a third-party next hop, thus directing packets not to the peer announcing the prefix but somewhere else. This mechanism is commonly used at Internet Exchange Points, where prefixes will be announced by IXP’s route-server.

RFC7454 Next Hop Filtering
RFC7454 Next Hop Filtering

Section 10 of RFC 7545 recommends the following policies at IXP locations:

  • For direct peering (without router-server), apply inbound BGP policy that would set next-hop for the accepted prefix to BGP peer IP address
  • For indirect peering (with IXP’s route-server), accept next-hop attribute advertised by the route-server

BGP Community Scrubbing

Section 11 of RFC 7454 provides the following optional community scrubbing recommendations.

RFC7454 BGP Community Scrubbing
RFC7454 BGP Community Scrubbing
  • Ingress BGP peering policy applied to transit/public/private and downstream peers should remove all inbound communities with SP’s number in the high-order bits, except for the ones used for signaling (e.g. setting BGP Local Preference).
  • Ingress BGP Policy should not remove other communities, as those communities can be used to communicate with upstream providers.

Traffic Filtering

Section 4 of RFC 7454 provides basic recommendations when it comes to traffic filtering and BGP.

RFC7454 Traffic Filtering
RFC7454 Traffic Filtering

 

All packets destined to TCP Port 179 and not originated from addresses of configured BGP peers should be discarded. If supported, Control Plane ACL (point 3 on the diagram) should be used. If not supported, ACL applied to each peer-facing port (point 1) should be used.

If supported, BGP Rate-Limiting (point 4) should also be implemented, to make sure that the number of BGP packets per second does not exceed platform’s capability.

Generic Control Plane protection recommendations are out of RFC 7454 scope and are covered in RFC 6192.