Day One Tips
Day One Tips

Template: Simple dual-node, dual ISP BGP peering example

[ Edited ]
‎10-29-2010 01:12 PM

Junos Solution Template:

  • Simple BGP Peering.  Dual Node. Dual ISP.

 

 Dan Backman <dbackman@juniper.net>

 Solutions Architect, Junos Advocacy

 JNCIE-M #265 / JNCIE-ER #6

 

 

Concept:

Example of Junos in an external peering role with a site AS and address block and two ISPs.

 

Diagram:bgp-peering-topo.jpg


Description:

When configuring dual-homed ISP peering, in many cases your organization requires redundant connectivity to the Internet and is advertising its own autonomous system (AS number) and address block.  

 

To configure a dual-homed Internet connection, there are four steps:

  1. craft a BGP export policy to advertise your network’s address block to upstream providers
  2. configure internal BGP peering between your default-free peering routers
  3. configure external BGP peering to your upstream providers
  4. verify the routes you are receiving from your upstream providers, and verify the routes being advertised to your peers.

 

Discussion:

Step 1: Craft a BGP export policy

 

While nominally a simple example, it’s critical to understand the implications of BGP policy when connecting to more than one ISP.

 

The default behavior of BGP is to pass along all routes advertised to it by other peers.  So, to avoid attracting traffic to destinations other than your network (transit traffic), it’s important to craft a BGP export policy that only allows your own networks addressing to be advertised to upstream providers.  

 

Note: most providers implement filtering with their downstream peers to prevent accidental route advertisements.  However despite these protections, it’s still good practice to assume that your upstream peers will not protect you from incorrect configuration.

 

In Junos, a policy is equivalent to a route-map in Cisco IOS or ScreenOS.  Instead of combining match ACLs with a route-map statement, Junos creates both constructs within an easy to understand policy language, consisting of one or more terms.  

 

Let’s examine a simple export policy applied from R1 to advertise its own routes to AS100:

 

policy-options {
    policy-statement as100-out {
        term 1 {
            from {
                protocol bgp;
                as-path none;
            }
            then accept;
        }
        term 2 {
            from protocol aggregate;
            then accept;
        }
        then reject;
    }
    as-path none "()";
}

 

 

 

The first term matches only BGP routes with an AS of none.  Note that “none” is the name of an as-path object defined under the root of the [ edit policy ] stanza within the Junos configuration.  This as-path of none contains a simple regular expression selecting a null path length.  Any BGP routes obtained from another ISP would have AS path information set, and wouldn’t match this term.  However, any routes originated by the iBGP peer could also be matched in this term.

 

The next term (2) matches a route-type of aggregate. As Junos does not rely on the IOS-like concept of a network statement within the BGP configuration, there is another way of defining a network prefix to be advertised by BGP.   This route type of aggregate matches the aggregate route of 45/8 defined under the [ edit routing-options ] stanza of the configuration -- along with the router-id and local AS number.

 

 

routing-options {
    aggregate {
        route 45.0.0.0/8;
    }
    router-id 10.255.255.1;
    autonomous-system 1000;
}

 

 

 

 

Step 2 and 3: Configure internal and external BGP peers

Junos requires that all BGP peers be configured within a group. This group allows a set of neighbors to share common configuration.  It’s typical to configure BGP export or import policies at the group level within Junos.

 

protocols {
    bgp {
        group ibgp {
            type internal;
            local-address 10.255.255.1;
            neighbor 10.255.255.2;
        }
        group as100 {
            export as100-out;
            peer-as 100;
            neighbor 4.1.1.1;
        }
    }
}

 

 

 

Note that the iBGP peer is defined within a separate group marked “internal”.  As the iBGP peering is done using loopback addresses, the source-address must be specified.  This requires that the loopback addresses are reachable via OSPF within the internal network.

 

The external BGP peer is defined within group “as100” and includes the remote-as as well as the export policy (defined in step 1 above).  As eBGP is in most cases peered via interface addresses, there is no need to specify a source-address here.

 

Since this iBGP configuration will share routes between both peering routers (R1 & R2), each router must be able to resolve the BGP next-hop of the opposite router’s BGP peer.  A typical error in BGP configuration results in routes from an iBGP peer not active in the routing table due to the BGP next-hop resoution failing.  There are two typical solutions to this problem:  set next-hop self on routes advertised to an iBGP neighbor, or add the external peering interfaces to the OSPF process.  In this case, the OSPF configuration contains the peering interface set to a passive mode within the OSPF configuration:


 

protocols {
    ospf {
        area 0.0.0.0 {
            interface em0.0 {
                disable;
            }
            interface em1.0 {
                interface-type p2p;
            }
            interface em3.0 {
                interface-type p2p;
            }
            interface em4.0 {
                passive;
            }
            interface lo0.0 {           
                passive;
            }
        }
    }
}

 

 

 

Selecting the passive OSPF interface configuration allows OSPF to advertise the subnet as an internal route, but will not allow an accidental adjacency to form with the peering router.

 


Step 4:  Verify Correct Configuration

 

Check that your BGP sessions are up (in Established state):

 

dbackman@R1> show bgp summary 
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
4.1.1.1                 100       2180       2179       0       0    16:21:28 1/1/1/0              0/0/0/0
10.255.255.2           1000       2193       2186       0       0    16:26:28 1/1/1/0              0/0/0/0

 

 

 

If BGP sessions are not established, look for the state field to determine the cause.  In this case, the peering interface is down, and the BGP session is idle:

 

dbackman@R1> show interfaces em4 terse 
Interface               Admin Link Proto    Local                 Remote
em4                     down  down
em4.0                   down  down inet     4.1.1.2/30      
 
dbackman@R1> show bgp summary 
Groups: 2 Peers: 2 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
4.1.1.1                 100       2182       2182       0       1           3 Idle  
10.255.255.2           1000       2195       2190       0       0    16:27:33 1/1/1/0              0/0/0/0
 

 

 

 

If the connection is up, you can verify the routes received from the ISP.  (Note: if they are sending full BGP tables, this may be a long list):

 

 

dbackman@R1> show route receive-protocol bgp 4.1.1.1 
 
inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 4.0.0.0/16              4.1.1.1                                 100 I
 
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 

 

 

 

Junos can similarly display the routes being transmitted to the ISP router:

 

dbackman@R1> show route advertising-protocol bgp 4.1.1.1 

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
45.0.0.0/8              Self                                    I

Check that external routes are advertised to your iBGP peer:
dbackman@R1> show route advertising-protocol bgp 10.255.255.2 

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
4.0.0.0/16              4.1.1.1                      100        100 I

 

 

 

Check that external routes are advertised to your iBGP peer:

 

dbackman@R1> show route advertising-protocol bgp 10.255.255.2 
 
inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
4.0.0.0/16              4.1.1.1                      100        100 I

 

 

 

Finally, check that routes received from both peers are available in the routing table of both routers:

 

R1:

 

dbackman@R1> show route protocol bgp 
 
inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
4.0.0.0/16         *[BGP/170] 00:09:56, localpref 100
                      AS path: 100 I
                    > to 4.1.1.1 via em4.0
5.0.0.0/16         *[BGP/170] 16:43:19, localpref 100, from 10.255.255.2
                      AS path: 200 I
                    > to 45.0.0.2 via em1.0

 

 

 

R2:

 

dbackman@R2> show route protocol bgp 
 
inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
4.0.0.0/16         *[BGP/170] 00:11:19, localpref 100, from 10.255.255.1
                      AS path: 100 I
                    > to 45.0.0.1 via em1.0
5.0.0.0/16         *[BGP/170] 17:01:09, localpref 100
                      AS path: 200 I
                    > to 5.1.1.1 via em4.0
 
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 
 

 

 

 

 

Configuration Examples:

 

R1:
interfaces {                            
    # Interface R1-R2
    em1 {
        unit 0 {
            family inet {
                address 45.0.0.1/30;
            }
        }
    }
    # Interface R1-R3
    em3 {
        unit 0 {
            family inet {
                address 45.0.0.5/30;
            }
        }
    }
    # Interface R100-R1
    em4 {
        unit 0 {
            family inet {
                address 4.1.1.2/30;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.255.255.1/32;
            }
        }                               
    }
}
routing-options {
    aggregate {
        route 45.0.0.0/8;
    }
    router-id 10.255.255.1;
    autonomous-system 1000;
}
protocols {
    bgp {
        group ibgp {
            type internal;
            local-address 10.255.255.1;
            neighbor 10.255.255.2;
        }
        group as100 {
            export as100-out;
            peer-as 100;
            neighbor 4.1.1.1;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface em0.0 {
                disable;
            }
            interface em1.0 {
                interface-type p2p;
            }
            interface em3.0 {
                interface-type p2p;
            }
            interface em4.0 {
                passive;
            }
            interface lo0.0 {           
                passive;
            }
        }
    }
}
policy-options {
    policy-statement as100-out {
        term 1 {
            from {
                protocol bgp;
                as-path none;
            }
            then accept;
        }
        term 2 {
            from protocol aggregate;
            then accept;
        }
        then reject;
    }
    as-path none "()";
}

 

 

 

 

R2:
 interfaces {                            
    # Interface R1-R2
    em1 {
        unit 0 {
            family inet {
                address 45.0.0.2/30;
            }
        }
    }
    # Interface R2-R3
    em3 {
        unit 0 {
            family inet {
                address 45.0.0.9/30;
            }
        }
    }
    # Interface R200-R2
    em4 {
        unit 0 {
            family inet {
                address 5.1.1.2/30;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.255.255.2/32;
            }
        }                               
    }
}
routing-options {
    aggregate {
        route 45.0.0.0/16;
        route 45.0.0.0/8;
    }
    router-id 10.255.255.2;
    autonomous-system 1000;
}
protocols {
    bgp {
        group ibgp {
            type internal;
            local-address 10.255.255.2;
            neighbor 10.255.255.1;
        }
        group as200 {
            export as200-out;
            peer-as 200;
            neighbor 5.1.1.1;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface em0.0 {
                disable;
            }
            interface em1.0 {
                interface-type p2p;
            }
            interface em3.0 {
                interface-type p2p;
            }
            interface em4.0 {
                passive;
            }                           
            interface lo0.0 {
                passive;
            }
        }
    }
}
policy-options {
    policy-statement as200-out {
        term 1 {
            from {
                protocol bgp;
                as-path none;
            }
            then accept;
        }
        term 2 {
            from protocol aggregate;
            then accept;
        }
        then reject;
    }
    as-path none "()";
}

 

 

 

Dan Backman
JNCIE-ER #6 / JNCIE-M #265 / JNCI

Attachments