Timber by www.emsien3.com EMSIEN-3 Ltd
  • OPT/Net Blog

JUNOS router as BGP Route Server - Part 1

Blog by Taras Matselyukh – CTO and Principal Consultant at Opt/Net Consulting B.V.
Hashtags: #BGPRouteServerJUNOS

Introduction

BGP Route Servers are commonly used in the Internet Exchanges (IX) to simplify peering relations among the IX clients, minimize the memory and hardware requirements for the IX client’s routers and to improve the leverage of the IX operator over the routes stability in their domain.

While the configuration of the Route Server is a fairly common topic for the Cisco IOS, the use of the Juniper routers as Route Servers has been a very controversial topic, despite the obvious advantages of the model. These series of blog articles will devote some time to the topic and will try to answer the question – “How to use Juniper routers as route servers)

Before we go into details, I would like to recap what is the ‘BGP route server’ – this is an EBGP peer, typically within its own AS, with which all other BGP peers in the IX form external BGP peerings. The role of the route server is to distribute all routing information to all IX clients without the need for them to configure direct BGP sessions among themselves. Route server is typically located in the same peering VLAN as all other BGP peers at the IX (we will review only this scenario in this blog).

So, what is expected of the route server?

Here we will suffice by summarising main features expected from the Route Server:

  1. Redistribute all BGP routes among the IX clients in order to provide connectivity;
  2. Keep the next-hop of the routes unchanged in order to provide optimum routing;
  3. Hide it’s own AS number from routing updates to provide clarity and reduce AS path;
  4. Ability to filter incoming and outgoing routing updates for sanity and generate aggregate routes accordingly to the assigned plan in order to improve stability and provide IX operator with the control over its routing domain.

The rest of the blog will depict few scenarios, which would shed some light on the topic of ‘BGP Route Server on Juniper routers (JUNOS based)’.

Disclaimer: The provided configurations are for the reference use only and were used and validated in the lab environment with private and public IP and AS numbers. Please, use with caution and adapt to your environment and local routing policies as deemed necessary.

Part 1 - The simple question but complex answer

Can Juniper router be configured as a route server? The short and simple answer does not exist. If you’d look up on the Internet for the answer for the question if JUNOS supports route server mode the same way as Cisco does – the answer will be straight “no”. JUNOS does not provide any configuration knobs that would turn the JUNOS router into a nice and powerful dream-machine BGP route server. But if you’d ask me if one can use the JUNOS router as the BGP route server, I would answer ‘maybe’, depending on how much of the expected functionality are you ready to sacrifice and how much are you ready to complicate the IX configuration for the clients.

Straight ‘out-of-the-box’ approach

The simplest approach is to configure the JUNOS router as a pseudo route-server. It would actually provide you with 2 required functionalities out of 4 with the basic EBGP configuration. Requirements 1 and 2 will be met and 3 and 4 not met (note: 4 will be discussed in the next blog)

You will need to dedicate one public AS, one JUNOS router with at least one GE interface and several cisco and juniper route server’s clients connected to the same VLAN via a switch.

The network diagram is provided below. On this test network the router J is configured to be our BGP pseudo route server.

AS300 (S) ------- AS200 (RS) ----- AS100 (C1) -------- AS500(C2)
                    |
                 AS400 (E)
BGP-route-server1.png

Figure 1 - Network diagram

The basic configuration of the J router is very straightforward:

taras@J# show protocols

bgp {
    group ebgp {
        type external;
        neighbor 192.168.3.201 {
            peer-as 400;
        }

        neighbor 192.168.3.1 {
            peer-as 300;
        }

        neighbor 192.168.3.202 {
            peer-as 100;
        }
    }

[edit]

taras@J# show routing-options
autonomous-system 200;

There is no need for a special configuration on the route server’s clients, other than normal EBGP and prefix redistribution policies.

--------------- Juniper client -------------
taras@S> show configuration protocols

bgp {
    group e-bgp-test {
        type external;
        export [ send-loopback send-internal-routes ];
        neighbor 192.168.3.200 {
            peer-as 200;
        }
    }
}

taras@S> show configuration routing-options     

autonomous-system 300;

taras@S> show configuration policy-options
policy-statement send-internal-routes {
    from {
        protocol direct;
        route-filter 192.168.0.0/22 prefix-length-range /22-/24;
    }
    then accept;
}

policy-statement send-loopback {
    from {
        protocol direct;
        route-filter 192.168.255.1/32 exact;
    }

    then {
        origin igp;
        accept;
    }
}

--------------- Cisco client -------------
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 redistribute connected
 neighbor 20.0.1.2 remote-as 500
 neighbor 20.0.1.2 version 4
 neighbor 192.168.3.200 remote-as 200
 neighbor 192.168.3.200 version 4
 no auto-summary
 !      

The most important fact that allows this pseudo-route server to function like we want is that JUNOS EBGP peer does not change the next-hop of the advertised routes if all EBGP peers are located in the same VLAN (IP subnet) when it re-advertises the routes to other EBGP peers in the same VLAN (same IP subnet).

Warning: this behaviour will change though, if multiple VLANs and different IP subnets are used.

To verify our work, we injected several routes (directly connected to our peers) into BGP and verified the next-hop attributes and proper routing.

--------------- Cisco client -------------
C1#sh ip bgp

BGP table version is 20, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.1/32      192.168.3.201       0                  200 400 i
*> 10.1.1.1/32      0.0.0.0              0                  32768 ?
*> 10.2.2.2/32      20.0.1.2             0                0  500 ?
*  20.0.1.0/30      20.0.1.2             0                0  500 ?
*>                  0.0.0.0              0                   32768 ?
*> 192.168.0.0      192.168.3.1                           0  200 300 i
*> 192.168.1.0      192.168.3.1                           0  200 300 i
*> 192.168.2.0      192.168.3.1                           0  200 300 i
*> 192.168.3.0      0.0.0.0              0                  32768 ?
*> 192.168.255.1/32 192.168.3.1                        0 200 300 i

C1#traceroute 192.168.255.1

Type escape sequence to abort.

Tracing the route to 192.168.255.1

  1 192.168.255.1 [AS 300] 4 msec 4 msec 8 msec

--------------- Juniper client -------------
taras@S> show route protocol bgp 10/8 detail

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)

10.0.0.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-10
                Next hop type: Router, Next hop index: 597
                Address: 0x165164c
                Next-hop reference count: 3
                Source: 192.168.3.200
                Next hop: 192.168.3.201 via vlan.1, selected
                State: <Active Ext>
                Local AS:   300 Peer AS:   200
                Age: 58:59
                Task: BGP_200.192.168.3.200+179
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: 200 400 I
                Accepted
                Localpref: 100
                Router ID: 192.168.3.200

10.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 599
                Address: 0x16516e4
                Next-hop reference count: 9
                Source: 192.168.3.200
                Next hop: 192.168.3.202 via vlan.1, selected
                State: <Active Ext>
                Local AS:   300 Peer AS:   20
                Age: 58:59
                Task: BGP_200.192.168.3.200+179
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: 200 100 ?
                Accepted
                Localpref: 100
                Router ID: 192.168.3.200

10.2.2.2/32 (1 entry, 1 announced
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 599
                Address: 0x16516e
                Next-hop reference count: 9
                Source: 192.168.3.200
                Next hop: 192.168.3.202 via vlan.1, selected
                State: <Active Ext>
                Local AS:   300 Peer AS:   200
                Age: 58:59
                Task: BGP_200.192.168.3.200+179
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: 200 100 500 ?
                Accepted
                Localpref: 100
                Router ID: 192.168.3.200

taras@S> traceroute 10.2.2.2 interface lo0   
traceroute to 10.2.2.2 (10.2.2.2), 30 hops max, 40 byte packets
 1  192.168.3.202 (192.168.3.202)  5.016 ms  5.103 ms  5.882 ms
 2  20.0.1.2 (20.0.1.2)  20.156 ms *  6.637 m

As you can see, the routes advertised by our pseudo- BGP route server are retaining respective next-hops and the packets are sent directly to the correct gateway bypassing the route server.

Summary: The basic configuration of BGP on our pseudo route server delivers on half of our goals (1) (2) described in the beginning of the article. The configuration is very simple and transparent.

The only disadvantage is that our goal of hiding the route server’s own AS is not achieved (3). But is it such a big issue after all? It is for you to decide.

The ability to exercise control over the routing updates on the route server will be discussed in the next part of this blog.
Stay tuned!

P.S. If you have feedback, questions or suggestions, please, discuss it on the LinkedIn with us or e-mail us This email address is being protected from spambots. You need JavaScript enabled to view it.