16,118 views
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 :
(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)
(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 /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 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.
Similar/Related posts:
Juniper ScreenOS : defeating iBGP full mesh requirement using route reflectors and confederations
Using Fedora 9 as an OSPF / BGP router (Quagga / Zebra) and set up BGP between Linux and Juniper ScreenOS
Juniper ScreenOS : default route manipulations and redistributions
Juniper Screenos : Redundant multi-exitpoint ISP routing failover using multiple vrouters, multiple OSPF areas and eBGP
Juniper Firewall ScreenOS Basics (CJFV)
Donate
Your donation will help funding server hosting.
