Please take a moment to read http://bit.ly/demandglobalchange, to help share the message and support the initiative to tell our leaders to focus on addressing the global world problems, instead of complaining about the effects of their lack of leadership. Be a leader yourself, and share this with as many people as possible. #demandglobalchange // https://www.facebook.com/demandglobalchange



Please consider donating: https://www.corelan.be/index.php/donate/


14,855 viewsThis page as PDF (Login first !)

Juniper ScreenOS BGP Basics : a simple iBGP test case

As explained in one of my earlier posts, ScreenOS supports a couple of ways to provide for dynamic routing. Today, I’m going to explain some basic implementations of BGP on ScreenOS. Unlike my post on OSPF, I won’t be going too much into all the details of what BGP is and how it works, but we need to understand some important basic facts about BGP before looking at the configuration.

Introduction

First of all, while OSPF is a broadcast-based mechanism, BGP is connection-oriented uses TCP sessions between BGP peers in order to exchange information. This means that BGP peers don’t need to be in the same broadcast domain in order to communicate, form neighbors and exchange information. This means that you can have BGP peers that are connected over one or more routers, even non-BGP enabled routers/hosts, and that you can easily run BGP through firewalls as well. BGP uses tcp 179 to communicate.

It is important to know that BGP does not really have reliability mechanisms (OSPF has LSAck messages), so the TCP sessions between the peers must be up at all time, even if the peers are not exchange information.

Next, BGP is a path-vector routing protocol. Unlike interior routing protocols (such as OSPF), BGP (which is an exterior routing protocol) does not contain metric information, but merely consists of the AS path that can be used to reach a particular network. By default, the best path is the one with the fewest number of AS in the path between source and destination.

BGP does not deal with hops or links, but with AS (Autonomous Systems). BGP refers to networks as prefixes. When a prefix is advertised from an AS, BGP will send out the information about the prefix to the connected AS, until all AS are aware of the prefix. BGP adds the AS number to the AS path (which is the equivalent of a route in a IGP such as OSPF). So when an AS learns about a new prefix (network), it really learns about the path associated with this network. This is what happens on the internet, and within other EBGP networks.

IBGP is somewhat easier to understand, because there is only one AS – the current AS. That’s the main difference between IBGP and EBGP.

Since there is only one AS within IBGP, why would we choose BGP over OSPF ? 2 easy reasons :

  • BGP uses tcp connections instead of broadcasts (ability to connect to BGP peers across routers)
  • the abililty to use access lists and route maps to filter both incoming and outgoing advertisements (OSPF can only filter outgoing routes, not incoming routes). Furthermore, you can even filter traffic from other AS (in, out or passing through)

Some terminology before looking at a basic setup :

Peers (neighbors): these are BGP device pairs that are configured to exchange information. On Juniper, when a device has been configured to connect to a peer, the device can be in one of the following BGP states :

  • Idle (initial state, all BGP connections are refused until a start event is triggered)
  • Connect : the BGP host waits for a TCP connection to be completed
  • Active : BGP is configured on the host, but a TCP timeout has occurred and the sessions is not established yet. (Note : When state is Active, this only means that BGP has been configured.)
  • OpenSent : TCP connection is established and open message was sent to the remote peer. BGP waits to receive an open message from the remote peer
  • OpenConfirm : Open message was received from remote peer, and BGP now waits for keepalive message or notification message. If it receives a keepalive, the state will change to Established. If no keepalive is received, the state will change to idle
  • Establish : BGP peers are fully connected/adjacent and can exchange information (keepalives, updates and notification messages)

BGP only sends updates when a change occurs. There is no periodic refresh. Peers will, however, use keepalives to maintain the TCP connection, even if nothing needs to be exchange. If a neighbor goes down, BGP will remove all routes to the peer and will update its other peers accordingly.

BGP modes :

There are 2 main BGP modes : EBGP and IBGP

If peers are members of 2 different ASs, the connection between the two peers is an EBGP connection. When running EBGP, the devices must be directly connected

If peers are member sof the same AS, the connection between the two peers is an IBGP connection. Devices only need to be able to connect to each other. They need to be connected over IP, reachable over tcp 179, but they don’t have to be directly connected. They only need to be able to route to each other. Take this into account. Make sure the route that interconnects the BGP peers in IBGP will continue to work, even if BGP does not work. In order for iBGP to fully work, all iBGP hosts in the AS must be fully meshed. In other words, all iBGP peers must be connected to each other. This is required because iBGP peers only exchange information about themselves, and not about other neighbors. This could make the number of neighbors quite large, and thus the setup quite complex. You can set up one or more iBGP hosts to become a BGP reflector. In this mode, the iBGP host will exchange information from all reflector clients (from all iBGP hosts that have a relationship with the reflector), which could help simplifying the setup. You can also use confederations (sub-AS glued together as an new AS) as an alternative to a full mesh topology.

Transit domain :

This configuration allows traffic from other ASs to pass through its network.

It is important to understand that BGP enabled devices will not add new routes to the routing table if the next hop to the BGP route is reachable. The BGP next_hop for a specific route that is learned via EBGP is typically the EBGP peer’s IP address, which may not be reachable for a host that talks IGP (behind the EBGP router). In that case, BGP can be configured to change the next_hop address and put it’s own IP address as next_hop, so the IGP routers can still reach the next_hop. This feature can be enabled using the nhself-enable configuration attribute (configure this on a per peer basis)

Basic configuration

Initial setup :

bgp_initial
(click to enlarge)

the SSG5, router 1 and router 2 are part of OSPF area 0. They all have connected subnets. These subnets are redistributed into OSPF and are available on all hosts.

The routing table on SSG5-1 looks like this :

IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (34 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*      1029          0.0.0.0/0         eth0/0    84.197.144.1   C    0      1     Root
*        15        10.2.0.8/32         eth0/3         0.0.0.0   H    0      0     Root
*      1014   192.168.132.0/24         eth0/1     192.168.0.1  E2  200      1     Root
*         7     192.168.0.8/32         eth0/1         0.0.0.0   H    0      0     Root
*        13     192.168.1.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root
*       996   192.168.100.0/24         eth0/1     192.168.0.7  E2  200     10     Root
*        14        10.2.0.0/24         eth0/3         0.0.0.0   C    0      0     Root

Goal : Add SSG5-2 to the network, ip 192.168.0.30. This device has connected network 192.168.2.0/24. Form a iBGP connection between SSG5-1 and SSG5-2 (AS65000) and exchange routing information between the two SSG5 devices. In addition, we will configure SSG5 so it injects the routes that are learned over BGP into OSPF (so they will become available on the OSPF routers)

bgp_goal

(click to enlarge)

Configuration : SSG5-1

On SSG5-1, we need to enable BGP on the vrouter, set the AS, create neigbor peer, set up authentication, and enable bgp on the interface (eth0/1)

SSG5-1 has already been configured for OSPF, so the device already has a router-id

#define local AS
ssg5-1-> set vrouter trust-vr proto bgp 65000
#enable BGP in vrouter trust-vr
ssg5-1-> set vrouter trust-vr proto bgp enable
#create neighbor
ssg5-1-> set vrouter trust-vr proto bgp neighbor 192.168.0.30 remote-as 65000
ssg5-1-> set vrouter trust-vr proto bgp neighbor 192.168.0.30 md5-authentication ThisIsMyMD5Password
ssg5-1-> set vrouter trust-vr proto bgp neighbor 192.168.0.30 enable
#enable BGP on interface eth0/1
ssg5-1-> set int eth0/1 proto bgp

When looking up the bgp neighbor list on ssg5-1, this is what we see :

ssg5-1-> get vrouter trust-vr proto bgp neighbor 
Peer AS Remote IP       Local IP          Wt Status   State     ConnID Up/Down
--------------------------------------------------------------------------------
  65000 192.168.0.30    0.0.0.0          100 Enabled  ACTIVE         0 8d;20:49:30

State is ACTIVE, which only means that BGP is configured, but not connection has been established with the peer. This is normal, because we did not configure the peer yet

Configuration : SSG5-2

Initial config : interfaces

ss5-2-> get int

A - Active, I - Inactive, U - Up, D - Down, R - Ready 

Interfaces in vsys Root: 
Name           IP Address                        Zone        MAC            VLAN State VSD      
serial0/0      0.0.0.0/0                         Null        0021.5934.2c15    -   D   -  
eth0/0         0.0.0.0/0                         Untrust     0021.5934.2c00    -   D   -  
eth0/1         192.168.0.30/24                   LAN         0021.5934.2c05    -   U   -  
eth0/2         192.168.2.8/24                    LAN2        0021.5934.2c06    -   U   -  
eth0/3         0.0.0.0/0                         Null        0021.5934.2c07    -   D   -  
eth0/4         0.0.0.0/0                         Null        0021.5934.2c08    -   D   -  
eth0/5         0.0.0.0/0                         Null        0021.5934.2c09    -   D   -  
eth0/6         0.0.0.0/0                         Null        0021.5934.2c0a    -   D   -  
bgroup0        0.0.0.0/0                         Trust       0021.5934.2c0b    -   D   -  
bgroup1        0.0.0.0/0                         Null        0021.5934.2c0c    -   D   -  
bgroup2        0.0.0.0/0                         Null        0021.5934.2c0d    -   D   -  
bgroup3        0.0.0.0/0                         Null        0021.5934.2c0e    -   D   -  
vlan1          0.0.0.0/0                         VLAN        0021.5934.2c0f    1   D   -  
null           0.0.0.0/0                         Null        N/A               -   U   0 

Initial config : routes

ss5-2-> get route


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (4 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*         8     192.168.2.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6    192.168.0.30/32         eth0/1         0.0.0.0   H    0      0     Root
*         7     192.168.2.0/24         eth0/2         0.0.0.0   C    0      0     Root
*         5     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root

Set up BGP

#define local AS
ssg5-2-> set vrouter trust-vr proto bgp 65000
#enable BGP in vrouter trust-vr
ssg5-2-> set vrouter trust-vr proto bgp enable
#create neighbor
ssg5-2-> set vrouter trust-vr proto bgp neighbor 192.168.0.8 remote-as 65000
ssg5-2-> set vrouter trust-vr proto bgp neighbor 192.168.0.8 md5-authentication ThisIsMyMD5Password
ssg5-2-> set vrouter trust-vr proto bgp neighbor 192.168.0.8 enable
#enable BGP on interface eth0/1
ssg5-2-> set int eth0/1 proto bgp

If we look at the bgp neighbor information on ssg5-2, this is what we get :

ss5-2-> get vrouter trust-vr proto bgp neighbor 
Peer AS Remote IP       Local IP          Wt Status   State     ConnID Up/Down
--------------------------------------------------------------------------------
  65000 192.168.0.8     192.168.0.30     100 Enabled  ESTABLISH      5 00:00:13

total 1 BGP peers shown

On ssg5-1, we see

ssg5-1-> get vrouter trust-vr proto bgp neighbor
Peer AS Remote IP       Local IP          Wt Status   State     ConnID Up/Down
--------------------------------------------------------------------------------
  65000 192.168.0.30    192.168.0.8      100 Enabled  ESTABLISH     52 00:01:38

total 1 BGP peers shown

So as soon as we have enabled bgp, the two ssg5 devices have formed neighbors and are in state establish.

What does the routing table look like at this point ?

ss5-2-> get route


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (4 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*         8     192.168.2.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6    192.168.0.30/32         eth0/1         0.0.0.0   H    0      0     Root
*         7     192.168.2.0/24         eth0/2         0.0.0.0   C    0      0     Root
*         5     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root


ssg5-1-> get route

IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (xx entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*      1029          0.0.0.0/0         eth0/0    84.197.144.1   C    0      1     Root
*        15        10.2.0.8/32         eth0/3         0.0.0.0   H    0      0     Root
*      1014   192.168.132.0/24         eth0/1     192.168.0.1  E2  200      1     Root
*         7     192.168.0.8/32         eth0/1         0.0.0.0   H    0      0     Root
*        13     192.168.1.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root
*       996   192.168.100.0/24         eth0/1     192.168.0.7  E2  200     10     Root
*        14        10.2.0.0/24         eth0/3         0.0.0.0   C    0      0     Root

=> no change. This is normal. We formed peers, but we did not specify what kind of information needs to be exchanged yet.

Let’s start by injecting the connected subnets on ssg5-2 into BGP :

There are 2 ways to do this : you can inject the network manually, or you can use a route-map. We’ll do it manually this time, you can find more info about creating route maps later in this blog post.

Before setting up the redistribution, enable debugging on ssg5-1 : debug bgp all (so we can see what is going on under the hood)

On ssg5-2, in order to distribute the connected network 192.168.2.0/24, you need one command :

ss5-2-> set vrouter trust-vr proto bgp network 192.168.2.0/24
ss5-2-> get vrouter trust-vr proto bgp network

network            weight check reachable-prefix   rib-in route-map
--------------------------------------------------------------------------------
192.168.2.0/24      32768 yes   192.168.2.0/24     yes    null

(The second command shows that the route is being distributed into bgp)

Now wait. The change will not be visible on ssg5-1 yet. Stop debugging on ssg5-1 (undebug all) and have a look at the log

ssg5-1-> get db str
## 2008-11-15 15:28:45 : [bgp/update]:    start: send eBGP updates
## 2008-11-15 15:28:45 : [bgp/update]:    done : send eBGP updates OK
## 2008-11-15 15:28:54 : [bgp/update]:    start: update FDB CHUNKABLE run
## 2008-11-15 15:28:54 : [bgp/update]:    update FDB for 192.168.2.0/24 flags 0x9
## 2008-11-15 15:28:54 : [bgp/route]:     best route does not exist: 192.168.2.0/24
## 2008-11-15 15:28:54 : [bgp/network]:   check if route exists for (192.168.2.0/24)->0.0.0.0
## 2008-11-15 15:28:54 : [bgp/network]:   route doesn't exist for (192.168.2.0/24)
## 2008-11-15 15:28:54 : [bgp/route]:     Synchronization check failed
## 2008-11-15 15:28:54 : [bgp/update]:    done : update FDB COMPLETED run, sync fail 5 times
## 2008-11-15 15:28:55 : [bgp/update]:    start: send eBGP updates
## 2008-11-15 15:28:55 : [bgp/update]:    done : send eBGP updates OK
## 2008-11-15 15:29:04 : [bgp/update]:    start: update FDB CHUNKABLE run
## 2008-11-15 15:29:04 : [bgp/update]:    update FDB for 192.168.2.0/24 flags 0x9
## 2008-11-15 15:29:04 : [bgp/route]:     best route does not exist: 192.168.2.0/24
## 2008-11-15 15:29:04 : [bgp/network]:   check if route exists for (192.168.2.0/24)->0.0.0.0
## 2008-11-15 15:29:04 : [bgp/network]:   route doesn't exist for (192.168.2.0/24)
## 2008-11-15 15:29:04 : [bgp/route]:     Synchronization check failed
## 2008-11-15 15:29:04 : [bgp/update]:    done : update FDB COMPLETED run, sync fail 6 times
## 2008-11-15 15:29:05 : [bgp/update]:    start: send eBGP updates
## 2008-11-15 15:29:05 : [bgp/update]:    done : send eBGP updates OK
## 2008-11-15 15:29:14 : [bgp/update]:    start: update FDB CHUNKABLE run
## 2008-11-15 15:29:14 : [bgp/update]:    update FDB for 192.168.2.0/24 flags 0x9

As you can see, ssg5-1 did get the BGP update, but it did not accept it (“route doesn’t exist for… “ and “synchronization check failed”)

Run the following command on ssg5-1 :

unset vrouter trust-vr proto bgp synchronization

Now look again :

ssg5-1->get route proto bgp


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (35 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*      1031     192.168.2.0/24         eth0/1    192.168.0.30  iB  250      0     Root

Total number of bgp routes: 1

The log file now indicates

## 2008-11-15 15:37:22 : [bgp/stack]:     Rx 192.168.0.30: UPDATE msg, conn-id 56
## 2008-11-15 15:37:22 : [bgp/update]:    created new PA, peer 192.168.0.30
## 2008-11-15 15:37:22 : [bgp/update]:    validate/canonical UPDATE pass
## 2008-11-15 15:37:22 : [bgp/update]:    start: proc updt msg, peer:192.168.0.30
## 2008-11-15 15:37:22 : [bgp/rtmap]:     start: apply policy route 0.0.0.0/0, peer 192.168.0.30, rtmap NULL
## 2008-11-15 15:37:22 : [bgp/rtmap]:     done : apply policy route 0.0.0.0/0, peer 192.168.0.30, rtmap NULL
## 2008-11-15 15:37:22 : [bgp/update]:    start: proc nlri 192.168.2.16/24
## 2008-11-15 15:37:22 : [bgp/update]:    local rib add prefix 192.168.2.0 / pref 100, metric 0, next-hop 192.168.0.30
## 2008-11-15 15:37:22 : [bgp/nexthop]: added nexthop for BGP nexthop: 192.168.0.30 with fdb nexthop: 192.168.0.30, cost: 0, reach_addr: 192.168.0.8, reach_mask: 24, bgprt: 0
## 2008-11-15 15:37:22 : [bgp/update]:    add 192.168.2.0/24 to intchg
## 2008-11-15 15:37:22 : [bgp/update]:    done : proc nlri 192.168.2.16/24 OK
## 2008-11-15 15:37:22 : [bgp/update]:    done : proc updt msg, peer:192.168.0.30
## 2008-11-15 15:37:22 : [bgp/update]:    start: send iBGP updates
## 2008-11-15 15:37:22 : [bgp/update]:    proc iBGP update prefix: 192.168.2.0/24
## 2008-11-15 15:37:22 : [bgp/update]:     Add Withd_rt 192.168.2.0/24 to peer 192.168.0.30 Tx_q
## 2008-11-15 15:37:22 : [bgp/update]:    add withdrawn prefix 192.168.2.0/24 to peer 192.168.0.30 Tx-q
## 2008-11-15 15:37:22 : [bgp/stack]:     enqueue UPDATE msg to peer 192.168.0.30 via connID 56
## 2008-11-15 15:37:22 : [bgp/update]:    done : send iBGP updates

Now the route is available on ssg5-1. We can now inject the routes learned via BGP into OSPF :

ssg5-1-> set vrouter trust-vr
ssg5-1(trust-vr)-> set access-list 5 permit ip 192.168.2.0/24 10
ssg5-1(trust-vr)-> set route-map name RedistBGPintoOSPF permit 10
ssg5-1(trust-vr/RedistBGPintoOSPF-10)-> set match ip 5
ssg5-1(trust-vr/RedistBGPintoOSPF-10)-> exit
ssg5-1(trust-vr)-> exit         
ssg5-1-> set vrouter trust-vr proto ospf redistribute route-map RedistBGPintoOSPF proto bgp

If you now look on the OSP routers (router-1 and router-2), you should see the route that was injected into OSPF

On router 2 :

C:\>route print

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10002 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
0x10003 ...00 1b 21 04 25 6d ...... Intel(R) PRO/1000 GT Desktop Adapter
0x20004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.8      192.168.0.1     10
      192.168.0.0    255.255.255.0      192.168.0.1      192.168.0.1     10
      192.168.0.1  255.255.255.255        127.0.0.1        127.0.0.1     10
    192.168.0.255  255.255.255.255      192.168.0.1      192.168.0.1     10
      192.168.2.0    255.255.255.0     192.168.0.30      192.168.0.1     20
    192.168.100.0    255.255.255.0      192.168.0.7      192.168.0.1     10
    192.168.132.0    255.255.255.0      192.168.0.1      192.168.0.1     10
        224.0.0.0        240.0.0.0      192.168.0.1      192.168.0.1     10
  255.255.255.255  255.255.255.255      192.168.0.1      192.168.0.1      1
Default Gateway:       192.168.0.8
===========================================================================

Step 1 accomplished. Now we would like to inject the routes that are known on ssg5-1 (connected nets + nets that are learned via OSPF) into BGP, so they would become visible on ssg5-2.

Let’s start with the connected nets.

ssg5-1-> set vrouter trust-vr proto bgp network 10.2.0.0/24
ssg5-1-> set vrouter trust-vr proto bgp network 192.168.1.0/24
ssg5-1-> get vrouter trust-vr proto bgp network

network            weight check reachable-prefix   rib-in route-map
--------------------------------------------------------------------------------
10.2.0.0/24         32768 yes   10.2.0.0/24        yes    null
192.168.1.0/24      32768 yes   192.168.1.0/24     yes    null

Note the “yes” in the check column. By default, the route will only be advertised to the other BGP peers when the network is reachable (either via a static route or via IGP). You can turn this behaviour off by specifying the no-check attribute when defining the network that needs to be advertised :

ssg5-1-> set vrouter trust-vr proto bgp network 10.2.0.0/24 no-check

Keep in mind that, with this setting of, you could be advertising prefixes to other bgp peers without being able to route packets to those networks. So I would recommend keeping these checks enabled.

On ssg5-2, the nets are not visible yet. The bgp synchronisation is still active on this host, so this is blocking the prefixes from being added to the ssg5-2 routing table (as you would be able to see in the output of a debug bgp all). Turn off bgp sync and then check the route table again

ss5-2-> unset vrouter trust-vr proto bgp synchronization 
ss5-2-> get route


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (6 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*         8     192.168.2.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6    192.168.0.30/32         eth0/1         0.0.0.0   H    0      0     Root
*         7     192.168.2.0/24         eth0/2         0.0.0.0   C    0      0     Root
*        10     192.168.1.0/24         eth0/1     192.168.0.8  iB  250      0     Root
*         5     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root
*         9        10.2.0.0/24         eth0/1     192.168.0.8  iB  250      0     Root

The “unset vrouter trust-vr proto bgp sync” command is needed because otherwise BGP will not advertise an update received from and iBGP peer unless the nexthop address in the update can be reached via an update from IGP or a static route.

Excellent. The connected subnets from ssg5-1 are now available on ssg5-2

You can also see the rib-in (Routing Information Base containing prefixes learned from BGP neighbors) (which should provide the same output as get route proto bgp) using the following command :

get vrouter trust-vr protocol bgp rib-in

With this command, you will see the AS numbers in the table as well. Since we are doing purely iBGP here, there will only be one AS, but if you start connecting to other ASes, doing eBGP, you will be able to use this command to find out the AS path to the destination

Example output (not related to this exercise) :

i: IBGP route, e: EBGP route, >: best route, *: valid route
               Prefix         Nexthop    Wt  Pref   Med Orig    AS-Path
--------------------------------------------------------------------------------
Total routes in rib-in: 32 (0 in flap-damping history)
--------------------------------------------------------------------------------
>e*    192.168.3.0/24    192.168.0.31   100   100     0  IGP   65002
>i     192.168.1.0/24         0.0.0.0 32768   100     0  IGP
etc...

=> in this example output, in order to reach the 192.168.3.0/24 network, you need to get to AS 65002 (because this prefix originates from this AS). Host 192.168.0.31 provides a path to this AS. (next-hop), with Weight of 100 and Preference of 100. The MED is 0, and the origin is IGP (so there is a full path known to this AS). If the path to the AS would be incomplete, the “Orig” colum would state ”INC”

Now, on ssg5-1, redistribute the routes that were learned via OSPF into BGP. We will need to create an access list and route map to do this, and then we can tell BGP to permit or deny in/out flow of these routes.

We will allow all nets, so we’ll use 0.0.0.0/0 in our access list :

ssg5-1-> set vrouter trust-vr
ssg5-1(trust-vr)-> set access-list 1 permit ip 0.0.0.0/0 10
ssg5-1(trust-vr)-> set route-map name RedistAllOSPFNets permit 10
ssg5-1(trust-vr/RedistAllOSPFNets-10)-> set match ip 1
ssg5-1(trust-vr/RedistAllOSPFNets-10)-> exit
ssg5-1(trust-vr)-> set proto bgp
ssg5-1(trust-vr/bgp)-> set neighbor 192.168.0.30 route-map RedistAllOSPFNets out
ssg5-1(trust-vr/bgp)-> exit
ssg5-1(trust-vr)-> exit

Now we need to tell BGP to redistribute routes from OSPF as well

ssg5-1-> set vrouter trust-vr proto bgp redistribute route-map RedistAllOSPFNets proto ospf

From the CLI on ssg5-1, disable and re-enable BGP and see if it starts working

ssg5-1-> unset vrouter trust-vr proto bgp enable
ssg5-1-> set vrouter trust-vr proto bgp enable

(Note : if you don’t want to reset/break the bgp relationship, you can also use the following command to reset routing updates) :

ssg5-1-> clear vrouter trust-vr protocol bgp neighbor 192.168.0.30 soft-in # for Adj-rib-in messages

ssg5-1-> clear vrouter trust-vr protocol bgp neighbor 192.168.0.30 soft-out # for Adj-rib-out messages

You can confirm that the refresh has been completed by looking at the neighbor status :

ssg5-1-> get vrouter trust-vr protocol bgp neighbor 192.168.0.30 | incl refresh
Route refresh: advertised and received
    route-refresh messages to peer: 1, from peer: 0

ss5-2-> get route


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> 
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*        52   192.168.132.0/24         eth0/1     192.168.0.1  iB  250      0     Root
*         8     192.168.2.8/32         eth0/2         0.0.0.0   H    0      0     Root
*         6    192.168.0.30/32         eth0/1         0.0.0.0   H    0      0     Root
*         7     192.168.2.0/24         eth0/2         0.0.0.0   C    0      0     Root
*        39     192.168.1.0/24         eth0/1     192.168.0.8  iB  250      0     Root
*         5     192.168.0.0/24         eth0/1         0.0.0.0   C    0      0     Root
*        34   192.168.100.0/24         eth0/1     192.168.0.7  iB  250      0     Root
*        33        10.2.0.0/24         eth0/1     192.168.0.8  iB  250      0     Root

Perfect !

The debug bgp all shows

## 2001-05-12 02:48:20 : [bgp/update]:    start: send iBGP updates
## 2001-05-12 02:48:20 : [bgp/update]:    proc iBGP update prefix: 192.168.100.0/24
## 2001-05-12 02:48:20 : [bgp/update]:     Add Withd_rt 192.168.100.0/24 to peer 192.168.0.8 Tx_q
## 2001-05-12 02:48:20 : [bgp/update]:    add withdrawn prefix 192.168.100.0/24 to peer 192.168.0.8 Tx-q
## 2001-05-12 02:48:20 : [bgp/stack]:     enqueue UPDATE msg to peer 192.168.0.8 via connID 23
## 2001-05-12 02:48:20 : [bgp/update]:    done : send iBGP updates
## 2001-05-12 02:48:20 : [bgp/update]:    proc iBGP update prefix: 192.168.132.0/24
## 2001-05-12 02:48:20 : [bgp/update]:     Add Withd_rt 192.168.132.0/24 to peer 192.168.0.8 Tx_q
## 2001-05-12 02:48:20 : [bgp/update]:    add withdrawn prefix 192.168.132.0/24 to peer 192.168.0.8 Tx-q
## 2001-05-12 02:48:20 : [bgp/stack]:     enqueue UPDATE msg to peer 192.168.0.8 via connID 23
## 2001-05-12 02:48:20 : [bgp/update]:    done : send iBGP updates

Let’s see if BGP updates work. Disconnect eth0/2 on ssg5-2, so the route to 192.168.2.0/24 network should disappear on ssg5-1 (Just wait before the updates take place and then have a look at the routing table)

ssg5-1-> get route protocol bgp


IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (34 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------

Total number of bgp routes: 0

You can see the BGP peer configuration on ssh5-1 using the following command :

ssg5-1-> get vrouter trust-vr proto bgp neighbor 192.168.0.30

peer: 192.168.0.30,  remote AS: 65000, admin status: enable
type: IBGP
connection state: ESTABLISH, connection id: 63 retry interval: 120s, cur retry time 15s
configured hold time: node default(180s), configured keepalive: node default(60s)
designated local IP: n/a
local IP address/port: 192.168.0.8/179, remote IP address/port: 192.168.0.30/1086
router ID of peer: 192.168.2.8, remote AS: 65000
negotiated hold time: 180s, negotiated keepalive interval: 60s
MD5 authentication: enable
route map in name: , route map out name: RedistAllOSPFNets
weight: 100 (default)
self as next hop: disable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities: 
  Route refresh: advertised and received
  Address family IPv4 Unicast:  advertised and received
force reconnect is disable
total messages to peer: 293, from peer: 291 
update messages to peer: 13, from peer: 14 
route-refresh messages to peer: 0, from peer: 0 
last reset 9d;01:42:16 ago, due to BGP recv Notification(Cease: Admin stopped)(code 6 : subcode 0)
number of total successful connections: 4
connected: 4 hours 0 minutes 51 seconds
Elapsed time since last update: 3 hours 48 minutes 22 seconds

If you have additional questions on using OSPF and BGP on ScreenOS, please visit my forum at http://www.corelan.be:8800/index.php/forum/screenos-routing-staticripospfbgp/page-1

Notes :

1. You can manually disconnect and connect two peers using the following command :

ssg5-1-> exec vrouter trust-vr proto bgp neighbor 192.168.0.30 disconnect
ssg5-1-> exec vrouter trust-vr proto bgp neighbor 192.168.0.30 connect

2. By default, the default route will be advertised over BGP. If you have created route maps that allow updates from 0.0.0.0/0, you are taking the risk that a new default route is injected, and depending on the preferences of your routes, the routing process can be different from what you expect. You can disable this behaviour using the following command :

ssg5-1-> set vrouter trust-vr proto bgp reject-default-route 
ssg5-1-> get vrouter trust-vr proto bgp reject-default-route 
Ignore default route:  enable

Advanced Features

Route dampening

If you want to be sure that routes only get advertised when they have become stable (after being in a flapping state), you can enable flap-damping. This is a bgp global config setting (and will apply to bgp operations on the device). Flap dampening is based on a suppress-limit and reuse-limit, and uses penalties for each flap. When the total penalty rises above the suppress-limit, the route will go away. When the line becomes stable again (penalty drops below reuse-limit, the route will be added again)

To enable flap-damping, use the “set vrouter trust-vr proto bgp flap-damping” command

Aggregate route announcements

This feature is mostly used in EBGP configurations, and allows you to reduce the number of avertised prefixes by reducing the number of route announcements.

So instead of advertising all individual nets, you announce aggregated nets (supernets) to the EBGP peer.

You can enable aggregation using the following commands :

set vrouter trust-vr proto bgp aggregate 192.168.0.0/16 summary only
set vrouter trust-vr proto bgp aggregate enable

Now when this host is announcing routes to BGP, that are a subnet of this 192.168.0.0/16 network, these individual routes will be ignored. The 192.168.0.0/16 supernet will be used instead.

Peer Groups

If you need to configure multiple peers that share the same AS/MD5 password/… on a single system, then you can either specify all bgp settings and neighbors/peer settings manually, or you can create a peer group, define the settings on the group, and just add the peers into the peer group

# Create the peer group
ssg5-1-> set vrouter trust-vr proto bgp neighbor peer-group ibgpPeers
ssg5-1-> set vrouter trust-vr proto bgp neighbor peer-group ibgpPeers remote-as 65000
ssg5-1-> set vrouter trust-vr proto bgp neighbor peer-group ibgpPeers md5-authentication ThisIsMyMD5Password
# Put a new peer in the peer group
ssg5-1-> set vrouter trust-vr proto bgp neighbor 192.168.0.30 peer-group ibgpPeers
ssg5-1-> set vrouter trust-vr proto bgp neighbor 192.168.0.30 enable

What’s next ?

In one of my next posts, I will explain how to set up a Linux host to run BGP/OSPF and to work in conjunction with the Juniper devices.

2008 – 2009, Corelan Team (corelanc0d3r). All rights reserved.

Related Posts:

Comments are closed.

Corelan Live training

Since 2011, Corelan GCV has been teaching live win32 exploit dev classes at various security cons and private companies & organizations.

You can read more about the training and schedules here

Demand Global Change

The world needs your help !

Please take a few moments to read the "Demand Global Change Call For Action" document at
http://bit.ly/demandglobalchange
Read the full document at
http://bit.ly/demandglobalchange_full and share the message with as many people as possible.

Like the Facebook page, and SHARE it with everyone you know.



Donate

Want to support the Corelan Team community ? Click here to go to our donations page.

Want to donate BTC to Corelan Team?



Your donation will help funding server hosting.

Protected by Copyscape Web Plagiarism Tool

Corelan Team Merchandise

You can support Corelan Team by donating or purchasing items from the official Corelan Team merchandising store.

Corelan on IRC

You can chat with us and our friends on #corelan (freenode IRC)

Categories