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

JUNOS router as BGP Route Server - Part 4

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

In this section of blog I will show you how to achieve all of the requirements set forth in the beginning of this series of the blog and make a real BGP Route-Server out of your older JUNOS router.

But such metamorphose will require some sacrifice – we have to use the private AS numbers for the route server and we will need more complex (helping) configuration on the client routers.

For this setup to work you will need:
a) Route-server configured with private AS number;
b) Aggregate or generated routes sourced from the route server (important!);
c) <Remove-private AS> configuration knob towards downstream peers on client routers;

Warning: this configuration will not work for normal transit BGP routes, and may result in your and your client’s routes being discarded on the Internet, if used without care. Make sure that no routes other than aggregates and generated are being advertised by the Route-server to its neighbours.

We will be using the same test-bed as before, with one change – in order to illustrate the working of the <remove-private-as> knob, I configured our BGP peering as follows:

(AS400)---(AS300)-----(RS AS64512)------(AS100)-----(AS500)

Only routers S and C1 have peering with route server J. Routers E and C2 are downstream teers and only peer with their respective upstream provider in this example.

On the RS I have configured both aggregate route (10.0.0.0/8) and generated route (192.168.0.0/22). I will illustrate the differences in behaviour for each later.

taras@J# show routing-options 

martians {
    0.0.0.0/0 exact;
}

aggregate {
    defaults {
        preference 164;
        community 200:666;
    }
    route 10.0.0.0/8 {
        policy contribute-filter-10;
        discard;
    }
}

generate {
    defaults {
        preference 130;
    }
    route 192.168.0.0/22 policy contribute-filter;
}

autonomous-system 64512;

Unlike in the previous part of the blog, I am using policies to influence the exact selection of the contributing routes for the aggregate route as well. This is done on purpose and may need to be monitored, because if the unexpected contributing route is chosen, such route update may be discarded by the BGP peers along the way, in the case if they see their own AS in the path. In the illustrated case I’ve used the contributing route 10.2.2.2/32 sourced from the router C2 for our aggregate route and 192.168.3.0/24 route sourced by the router S for the generated route 192.168.0.0/22.

taras@J# show policy-options 

policy-statement contribute-filter {
    from {
        protocol bgp;
        route-filter 192.168.3.0/24 exact;
    }
    then accept;
}

policy-statement contribute-filter-10 {
    term match {
        from {
            route-filter 10.2.2.2/32 exact;
        }
        then accept;
    }
    then reject;
}

policy-statement send-generated-only {
    term only-aggregate {
        from protocol aggregate;
        then accept;
    }

    term reject-all-other-routes {
        then reject;
    }
}

taras@J> show route 10/8 exact detail 

inet.0: 14 destinations, 16 routes (13 active, 0 holddown, 1 hidden)
10.0.0.0/8 (1 entry, 1 announced)
        *Aggregate Preference: 164
                Next hop type: Discard
                Next-hop reference count: 2
                State: <Active Int Ext>
                Local AS: 64512 
                Age: 1:16:26 
                Task: Aggregate
                Announcement bits (2): 0-KRT 2-BGP RT Background 
                AS path: 100 500 ? (LocalAgg)
                Communities: 200:666
                                Flags: DiscardDepth: 0Active
                AS path list:
                AS path: 100 500 ? Refcount: 1
                Contributing Routes (1):
                10.2.2.2/32 proto BGP

taras@J> show route 192.168.0.0/22 exact detail  

inet.0: 14 destinations, 16 routes (13 active, 0 holddown, 1 hidden
192.168.0.0/22 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Router, Next hop index: 522
                Next-hop reference count: 12
                Next hop: 192.168.3.1 via fe-0/0/0.0, selected
                State: <Active Int Ext>
                Local AS: 64512 
                Age: 1:16:39 
                Task: Aggregate
                Announcement bits (2): 0-KRT 2-BGP RT Background 
                AS path: I
                                Flags: GenerateDepth: 0Active
                Contributing Routes (3):
                192.168.0.0/24 proto BGP
                192.168.1.0/24 proto BGP
                192.168.2.0/24 proto BGP

The configuration of the BGP on our route server router is given below. Please, note that ONLY generated and aggregate routes should be sent to the clients of the router server. Otherwise, the private AS numbers will NOT be removed from the transit routes by the downstream peers, which might become a source of a great shame if advertised into the Internet.

taras@J# show protocols bgp 

group ebgp {
    type external;
    export send-generated-only;
    neighbor 192.168.3.1 {
        peer-as 300;
    }
    neighbor 192.168.3.202 {
        peer-as 100;
    }
}
NOTE: <remove-private> or <remove-private-AS> command only removes private AS number if it is found in the beginning of the AS path. Hence, only aggregate and generated routes are eligible for this operation in the case if the route server is configured with private AS number. Of course, locally sourced routes from the route server will be eligible too, but practicality of the use of redistributed IGP routes remains questionable. On contrary, static routes may be used as traps for the dDoS attacks, and the attacking traffic may be sampled and redirected to the capture host for subsequent analysis (this might be a topic for our next blog series).

On the client routers the <remove-private> or <remove-private-AS> command should be applied towards ALL downstream peers from the perspective of the route server location. Private AS is only stripped in the outgoing updates, not incoming updates. This is why the clients of the route server will still see the private AS number in their routing tables.

Juniper router
==============

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

        neighbor 192.168.3.201 {
            remove-private;
            peer-as 400;
        }
    }
}

Cisco Router
============

C1#sh run | beg bgp

router bgp 100
 no synchronization
 bgp always-compare-med
 bgp log-neighbor-changes
 redistribute connected
 neighbor 20.0.1.2 remote-as 500
 neighbor 20.0.1.2 version 4
 neighbor 20.0.1.2 remove-private-AS
 neighbor 192.168.3.200 remote-as 64512
 neighbor 192.168.3.200 version 4
 no auto-summary

In order to verify the results of our operations we will take a look at the downstream peers first:

On router C2 (Cisco path):
==========================

C2#sh ip bgp 
BGP table version is 22, local router ID is 10.2.2.
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.1.1.1/32      20.0.1.1                 0             0 100 ?
*> 10.2.2.2/32      0.0.0.0                  0         32768 ?
*  20.0.1.0/30      20.0.1.1                 0             0 100 ?
*>                  0.0.0.0                  0         32768 ?
*> 192.168.0.0/22   20.0.1.1                               0 100 i
*> 192.168.3.0      20.0.1.1                 0             0 100 ?

C2#ping

Protocol [ip]: 
Target IP address: 192.168.3.
Repeat count [5]: 
Datagram size [100]:
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: Loopback0
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

C2#tracero
C2#traceroute 

Protocol [ip]: 
Target IP address: 192.168.3.1
Source address: 10.2.2.2 
Numeric display [n]: y
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 192.168.3.1

  1 20.0.1.1 4 msec 8 msec 4 msec
  2 192.168.3.1 [AS 100] 12 msec 4 msec 4 msec

We used a generated route for the 192.168.0.0/22 prefix. This means that the next-hop was not altered by the route server J, and our routing was directed in bypass of the route server router. This is a typical use case for the IX, where we do not want all traffic to pass through the route server, of course.

On router E (JUNOS Path):
=========================

taras@E> show route 10.0.0.0/8 detail 

inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
10.0.0.0/8 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 1293
                Next-hop reference count: 2
                Source: 192.168.3.1
                Next hop: 192.168.3.200 via vlan.1, selected
                State: <Active Ext>
                Local AS:   400 Peer AS:   300
                Age: 42:54 
                Task: BGP_300.192.168.3.1+62422
                Announcement bits (1): 0-KRT 
                AS path: 300 100 500 ? Aggregator: 64512 10.3.3.3
                Communities: 200:666
                Accepted
                Localpref: 100
                Router ID: 192.168.255.1

taras@E> ping 10.2.2.2 
PING 10.2.2.2 (10.2.2.2): 56 data byte
36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 6e8a   0 0000  40  01 3baa 192.168.3.201  10.2.2.2 

64 bytes from 10.2.2.2: icmp_seq=0 ttl=254 time=8.399 ms
36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 6e8d   0 0000  40  01 3ba7 192.168.3.201  10.2.2.2 

64 bytes from 10.2.2.2: icmp_seq=1 ttl=254 time=6.709 ms
64 bytes from 10.2.2.2: icmp_seq=2 ttl=254 time=4.485 ms
36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 6e8f   0 0000  40  01 3ba5 192.168.3.201  10.2.2.2 

36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 6e93   0 0000  40  01 3ba1 192.168.3.201  10.2.2.2 
 
64 bytes from 10.2.2.2: icmp_seq=3 ttl=254 time=5.115 ms
64 bytes from 10.2.2.2: icmp_seq=4 ttl=254 time=4.042 ms
36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

 4  5  00 0054 6e95   0 0000  40  01 3b9f 192.168.3.201  10.2.2.2 
36 bytes from 192.168.3.200: Redirect Host(New addr: 192.168.3.202)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 6e9c   0 0000  40  01 3b98 192.168.3.201  10.2.2.2 
64 bytes from 10.2.2.2: icmp_seq=5 ttl=254 time=5.041 ms
^C
--- 10.2.2.2 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.042/5.632/8.399/1.488 ms

taras@E> traceroute 10.2.2.2 
traceroute to 10.2.2.2 (10.2.2.2), 30 hops max, 40 byte packets
 1  192.168.3.200 (192.168.3.200)  3.597 ms  3.341 ms  3.268 ms
 2  192.168.3.202 (192.168.3.202)  2.186 ms  2.137 ms  2.076 ms
 3  20.0.1.2 (20.0.1.2)  6.191 ms *  4.035 ms

In this case the 10.0.0.0/8 was an aggregate route. For the aggregate routes the route server installs its own IP address as a next hop, but it still is capable to redirect the traffic via ICMP redirect message, as illustrated in the capture below.

On the clients of the route server we still see the private AS number and next-hops in the routing tables.

Cisco Router
============

C1#sh ip bgp
BGP table version is 6, 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.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      0.0.0.0                  0         32768 ?
*                   20.0.1.2                 0             0 500 ?
*> 192.168.0.0/22   192.168.3.1                            0 64512 i
*> 192.168.3.0      0.0.0.0                  0         32768 ?

C1#sh ip route 192.168.0.0 
Routing entry for 192.168.0.0/22, supernet
  Known via "bgp 100", distance 20, metric 0
  Tag 64512, type external
  Last update from 192.168.3.1 00:53:54 ago
  Routing Descriptor Blocks:
  * 192.168.3.1, from 192.168.3.200, 00:53:54 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

Juniper router
==============

taras@S# run show route 10/8 exact detail 

inet.0: 20 destinations, 21 routes (19 active, 0 holddown, 1 hidden)
10.0.0.0/8 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 607
                Address: 0x1651568
                Next-hop reference count: 3
                Source: 192.168.3.200
                Next hop: 192.168.3.200 via vlan.1, selected
                State: <Active Ext>
                Local AS:   300 Peer AS: 64512
                Age: 55:09 
                Task: BGP_64512.192.168.3.200+179
                Announcement bits (3): 0-KRT 3-BGP RT Background 4-Resolve tree 1
                AS path: 64512 100 500 ? Aggregator: 64512 10.3.3.3
                Communities: 200:666
                Accepted
                Localpref: 100
                Router ID: 10.3.3.3
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.