In this post, we will look at some basic BGP configurations on Junos.
Lab Environment
The lab is set up as per the below diagram.
- vMX-1 and vMX-2 belong to AS 65002.
- vMX-3 belongs to AS 65001.
- vMX-1 and vMX-3 are already configured.
- vMX-2 already has its interfaces configured and as we go through the examples we will:
- Configure eBGP to vMX-3
- Configure iBGP to vMX-1
Junos Default BGP Policy
First, here is a quick refresh on the default Junos BGP policy.
The default import policy will accept BGP routes from configured peers and import them into the appropriate routing table – inet.0 for IPv4 routes and inet6.0 for IPv6 routes.
The default export policy is to re-advertise all active routes to all BGP peers while respecting the rule of not re-advertising a route learned from one iBGP peer to other iBGP peers.
Configuring eBGP
The basic configuration of eBGP is straightforward.
- Under router options, configure the autonomous system and optionally the router-id
- Under protocols bgp, configure a new group and specify the details for the peer device.
With Junos, BGP groups are used to group similar peers together. All peers must belong to a group, even if it is just a group of one. The peers in one group need to be the same type, either internal or external, but a group of external peers does not all need to be from the same peer AS.
Some configuration items can be applied at many levels – under the protocols bgp stanza, the bgp group, or a specific peer. Only the most specific entry applies.
If you set a BGP export policy at the group level, it will apply to all peers within that group unless they have a more specific export policy applied directly under the peer.
Configure Autonomous System And Router-ID
Since we have not previously configured these items, we will need to configure them now. The router-id is optional. If we do not specify it, Junos will choose the address from the loopback interface. If no loopback is configured, it will use the address from the first hardware interface.
Specifying the router-id is preferred as it means the router-id will not be affected by interface or loopback address changes.
Both the autonomous system and router-id are configured under the routing-options stanza.
[edit]
lab@vMX-2# set routing-options autonomous-system 65002
[edit]
lab@vMX-2# set routing-options router-id 172.16.1.2
[edit]
lab@vMX-2#Configure eBGP Peer
To configure our eBGP we need to specify the following:
- A group name
- Peer AS
- Neighbor address
- Type – internal or external. If we do not state which it defaults to external.
- Optional, but recommended, you can also specify an authentication method.
In this example, we’re going to use MD5 authentication. That used to be the only choice, but modern versions of Junos also support AES128, SHA1, and TCP AO.
[edit]
lab@vMX-2# set protocols bgp group my-external-group type external
[edit]
lab@vMX-2# set protocols bgp group my-external-group peer-as 65001
[edit]
lab@vMX-2# set protocols bgp group my-external-group neighbor 192.168.2.1
[edit]
lab@vMX-2# set protocols bgp group my-external-group authentication-key Juniper
[edit]
lab@vMX-2#Before we commit, we do a show | compare to confirm what we are about to apply to the router.
[edit]
lab@vMX-2# show | compare
[edit]
+ routing-options {
+ router-id 172.16.1.2;
+ autonomous-system 65002;
+ }
[edit protocols]
+ bgp {
+ group my-external-group {
+ type external;
+ authentication-key "$9$7mdw2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
+ peer-as 65001;
+ neighbor 192.168.2.1;
+ }
+ }
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#BGP Verification
To quickly verify the neighbor status we can use the show bgp summary command.
lab@vMX-2> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
3 3 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.2.1 65001 14 13 0 0 5:25 Establ
inet.0: 3/3/3/0
lab@vMX-2>I’ve highlighted three important parts of the output.
- The peer address – 192.168.2.1
- The state – Establ for established, which means the BGP peering session is up.
- Inet.0: 3/3/3/0 – which indicates how many routes we have received for the inet address family.
A quick note on address families. The default is to use inet-unicast which is what we want most of the time. If we had more address families configured, we would see additional lines of output showing how many routes we learned for those address families as well.
After looking at the summary information, we can look at the specific neighbor to see additional details of the peering session.
lab@vMX-2> show bgp neighbor 192.168.2.1
Peer: 192.168.2.1+179 AS 65001 Local: 192.168.2.2+55529 AS 65002
Group: my-external-group Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference AuthKey PeerAS Refresh>
Options: <GracefulShutdownRcv>
Authentication key is configured
Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 0
Peer ID: 172.16.2.3 Local ID: 172.16.1.2 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ge-0/0/1.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 65001)
Peer does not support Addpath
Table inet.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 3
Received prefixes: 3
Accepted prefixes: 3
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 14 Sent 14 Checked 1011
Input messages: Total 40 Updates 2 Refreshes 0 Octets 800
Output messages: Total 39 Updates 0 Refreshes 0 Octets 745
Output Queue[1]: 0 (inet.0, inet-unicast)
lab@vMX-2>Finally, we can look at the BGP routes in our routing table.
lab@vMX-2> show route protocol bgp
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/24 *[BGP/170] 00:20:10, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
10.0.2.0/24 *[BGP/170] 00:20:10, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
10.0.3.0/24 *[BGP/170] 00:20:10, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>Configure iBGP Peer
Next, we can configure the iBGP peer for vMX-1. We will peer using the loopback addresses.
OSPF is already configured between vMX-1 and vMX-2 to advertise loopback addresses between them.
The configuration is very similar to the eBGP step, we need to set the following:
- A group name
- Neighbor address
- Type – internal, which must be specified
- Local-Address – which we will set to the address of the loopback interface. This will source the BGP traffic using the loopback address instead of the outgoing interface address.
- Optional, but recommended, you can also specify an authentication method.
Note that because we set the autonomous system and router-id in a previous step, we do not need to do that now. You still need those details for iBGP sessions.
[edit]
lab@vMX-2# set protocols bgp group my-internal-group type internal
[edit]
lab@vMX-2# set protocols bgp group my-internal-group neighbor 172.16.1.1
[edit]
lab@vMX-2# set protocols bgp group my-internal-group local-address 172.16.1.2
[edit]
lab@vMX-2# set protocols bgp group my-internal-group authentication-key Juniper
[edit]
lab@vMX-2# Next, we check the configuration before committing the change.
[edit]
lab@vMX-2# show | compare
[edit protocols bgp]
group my-external-group { ... }
+ group my-internal-group {
+ type internal;
+ local-address 172.16.1.2;
+ authentication-key "$9$GSjkmz39O1hfT1hSr8LGDi"; ## SECRET-DATA
+ neighbor 172.16.1.1;
+ }
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#iBGP Verification
The steps for verifying the session are the same as eBGP. We can check the BGP summary and the BGP neighbor.
lab@vMX-2> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
3 3 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 65002 3 3 0 0 39 Establ
inet.0: 0/0/0/0
192.168.2.1 65001 67 66 0 0 28:50 Establ
inet.0: 3/3/3/0
lab@vMX-2>The session to vMX-1 (172.16.1.1) is established. We are not receiving any routes from vMX-1 as it is not advertising any yet.
lab@vMX-2> show bgp neighbor 172.16.1.1
Peer: 172.16.1.1+179 AS 65002 Local: 172.16.1.2+52811 AS 65002
Group: my-internal-group Routing-Instance: master
Forwarding routing-instance: master
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AuthKey Refresh>
Options: <GracefulShutdownRcv>
Authentication key is configured
Local Address: 172.16.1.2 Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 0
Peer ID: 172.16.1.1 Local ID: 172.16.1.2 Active Holdtime: 90
Keepalive Interval: 30 Group index: 1 Peer index: 0 SNMP index: 1
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 65002)
Peer does not support Addpath
NLRI(s) enabled for color nexthop resolution: inet-unicast
Table inet.0 Bit: 20001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 3
Last traffic (seconds): Received 20 Sent 18 Checked 157
Input messages: Total 7 Updates 1 Refreshes 0 Octets 137
Output messages: Total 7 Updates 1 Refreshes 0 Octets 180
Output Queue[1]: 0 (inet.0, inet-unicast)
lab@vMX-2> The neighbor output is very similar to what we saw with the eBGP neighbor.
Current State Of The Network
With what we have configured on vMX-2, the network is in the following state:
- vMX-2 has an eBGP session to vMX-3 and is receiving three routes.
- vMX-2 has an iBGP session to vMX-1 and is sending it the three routes learned from vMX-3
- vMX-1 receives three routes from vMX-2, but these routes are hidden as the next-hop is unusable.
- Neither vMX-1 nor vMX-2 are advertising any locally connected routes.
In the next steps, we will fix the hidden routes on vMX-1, and then advertise a locally connected route into BGP.
Fixing Unusable BGP Next-Hop Using Next-Hop-Self
This is a common issue. BGP only changes the next-hop on a route when it passes over an eBGP peering session, not an iBGP session.
When vMX-2 advertises routes onto vMX-1 the next-hop is still set to the interface address of vMX-3. Since vMX-1 doesn’t have a route for this address, the BGP route is unusable.
Although this issue appears on vMX-1, we need to fix this on vMX-2.
Let’s start by looking at the issue on vMX-1. What BGP routes can we see currently?
lab@vMX-1> show route protocol bgp
inet.0: 10 destinations, 10 routes (7 active, 0 holddown, 3 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>We can’t see any bgp routes, but there are three hidden routes. We can add the hidden keyword to our command to look at these.
lab@vMX-1> show route protocol bgp hidden
inet.0: 10 destinations, 10 routes (7 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/24 [BGP/170] 00:20:39, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
Unusable
10.0.2.0/24 [BGP/170] 00:20:39, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
Unusable
10.0.3.0/24 [BGP/170] 00:20:39, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
Unusable
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>All of these routes are listed as unusable. Let’s look at the detail of 10.0.1.0/24.
lab@vMX-1> show route protocol bgp hidden 10.0.1.0/24 detail
inet.0: 10 destinations, 10 routes (7 active, 0 holddown, 3 hidden)
10.0.1.0/24 (1 entry, 0 announced)
BGP Preference: 170/-101
Next hop type: Unusable, Next hop index: 0
Address: 0xc3a426c
Next-hop reference count: 3
State: <Hidden Int Ext Changed>
Local AS: 65002 Peer AS: 65002
Age: 21:45
Validation State: unverified
Task: BGP_65002.172.16.1.2
AS path: 65001 I
Accepted
Localpref: 100
Router ID: 172.16.1.2
Thread: junos-main
lab@vMX-1> This output clearly tells us the next hop is unusable.
To fix this issue, we will use a very basic policy on vMX-2 to change the next hop and apply that as an export policy. We could apply the export policy at either the group or peer level, in this case, we’ll do it at the group level.
[edit]
lab@vMX-2# set policy-options policy-statement fix-nhs term fix-nhs then next-hop self
[edit]
lab@vMX-2# set protocols bgp group my-internal-group export fix-nhs
[edit]
lab@vMX-2# show | compare
[edit]
+ policy-options {
+ policy-statement fix-nhs {
+ term fix-nhs {
+ then {
+ next-hop self;
+ }
+ }
+ }
+ }
[edit protocols bgp group my-internal-group]
+ export fix-nhs;
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2# It is worth explaining the policy here in a bit more detail.
The fix-nhs term does not have a from statement. This means it will match all routes processed by this policy. Because this is applied to BGP, it effectively matches all the BGP routes vMX-2 knows.
The fix-nhs term doesn’t have a terminating action of accept or reject either. This allows the route(s) to be further evaluated if we have other terms or policies. In this case, the route is being accepted by the default BGP policy.
Finally, I have not specified a second term to reject other routes. This is again because I want routes to be evaluated against other policies I might apply in the future. If I put in a second term that matches all routes and rejects them, those routes will never be processed by later policies in the policy chain.
While this works well in this lab scenario, be careful when working with routing policy to ensure it does what you want it to.
Checking on vMX-1, we now see the three BGP routes we expected to see. These routes are no longer hidden.
lab@vMX-1> show route protocol bgp
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.0/24 *[BGP/170] 00:00:42, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.2.0/24 *[BGP/170] 00:00:42, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.3.0/24 *[BGP/170] 00:00:42, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>Advertising Directly Connected Routes
So far, we have not advertised any direct, or connected, routes into BGP. In this step, we will advertise a local network from vMX-1 into BGP.
On a Cisco IOS-based device, you might use a network statement or redistribute connected under the bgp configuration.
On Junos, we need to use policy instead. In this example, on vMX-1 we will use policy to match a locally connected network, 172.16.100.0/24, and advertise it into the iBGP session facing vMX-2.
Looking at the inet.0 routing table, we can see the network we want to advertise.
lab@vMX-1> show route table inet.0
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 08:49:10
> via fxp0.0
10.0.0.101/32 *[Local/0] 08:49:10
Local via fxp0.0
10.0.1.0/24 *[BGP/170] 06:25:12, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.2.0/24 *[BGP/170] 06:25:12, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.3.0/24 *[BGP/170] 06:25:12, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.16.1.1/32 *[Direct/0] 08:49:10
> via lo0.0
172.16.1.2/32 *[OSPF/10] 08:43:21, metric 1
> to 192.168.1.1 via ge-0/0/0.0
172.16.100.0/24 *[Direct/0] 07:06:01
> via lt-0/0/0.0
172.16.100.1/32 *[Local/0] 07:06:01
Local via lt-0/0/0.0
192.168.1.0/30 *[Direct/0] 08:47:53
> via ge-0/0/0.0
192.168.1.2/32 *[Local/0] 08:47:53
Local via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 08:49:10, metric 1
MultiRecv
lab@vMX-1>
We can advertise the 172.16.100.0/24 network as follows.
[edit]
lab@vMX-1# set policy-options policy-statement exp-direct from protocol direct
[edit]
lab@vMX-1# set policy-options policy-statement exp-direct from route-filter 172.16.100.0/24 exact
[edit]
lab@vMX-1# set policy-options policy-statement exp-direct then accept
[edit]
lab@vMX-1# set protocols bgp group my-internal-group neighbor 172.16.1.2 export exp-direct
[edit]
lab@vMX-1# show | compare
[edit]
+ policy-options {
+ policy-statement exp-direct {
+ from {
+ protocol direct;
+ route-filter 172.16.100.0/24 exact;
+ }
+ then accept;
+ }
+ }
[edit protocols bgp group my-internal-group neighbor 172.16.1.2]
+ export exp-direct;
[edit]
lab@vMX-1# commit
commit complete
[edit]
lab@vMX-1#Again, a few words on the policy. This time I’ve applied the policy directly under the neighbor, rather than at the group level. The policy itself has a from statement to match on protocol direct and a route-filter to limit what routes to advertise.
There is no second term matching all other routes and denying them, as we want other routes to be further processed by the rest of the policy chain, even if it is only the default BGP policy that will accept all BGP routes.
To verify this route is being advertised, we’ll skip vMX-2 and look at vMX-3 instead. This validates the route is being advertised from vMX-1 to vMX-2, and then on to vMX-3.
lab@vMX-3> show route protocol bgp
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.100.0/24 *[BGP/170] 00:04:49, localpref 100
AS path: 65002 I, validation-state: unverified
> to 192.168.2.2 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> Additional Basic BGP Configuration
Shutting Down A BGP Session Or Peer
It used to be that Junos did not have a method to shut down a BGP neighbor. Instead, you would deactivate the relevant portion of the configuration.
This has changed and since Junos 19.1 there has been a shutdown command.
On vMX-2 we can shut down the session to vMX-3.
[edit]
lab@vMX-2# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
4 4 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 65002 194 195 0 0 1:26:05 Establ
inet.0: 1/1/1/0
192.168.2.1 65001 256 256 0 0 1:54:16 Establ
inet.0: 3/3/3/0
[edit]
lab@vMX-2# set protocols bgp group my-external-group neighbor 192.168.2.1 shutdown
[edit]
lab@vMX-2# show | compare
[edit protocols bgp group my-external-group neighbor 192.168.2.1]
+ shutdown;
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2# run show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 2 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.1.1 65002 195 197 0 0 1:26:47 Establ
inet.0: 1/1/1/0
192.168.2.1 65001 258 258 0 1 12 Idle
[edit]
lab@vMX-2#Although it is accurate, the BGP state of Idle could be misleading. Let’s look at the neighbor.
[edit]
lab@vMX-2# run show bgp neighbor 192.168.2.1
Peer: 192.168.2.1 AS 65001 Local: 192.168.2.2 AS 65002
Group: my-external-group Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Idle Flags: <>
Last State: Established Last Event: Stop
Last Error: Cease
Options: <Preference AuthKey PeerAS Refresh>
Options: <GracefulShutdownRcv Shutdown>
Authentication key is configured
Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 1
Last flap event: Stop
Error: 'Cease' Sent: 1 Recv: 0
[edit]
lab@vMX-2#Again, I think this could be a little bit clearer. You really have to look at the options to see that the peer is shut down. From an operational perspective, there is an expectation that BGP peers should be in an established state. If they are not, that is probably an issue we should be trying to fix.
If it is not clear from the summary information that the BGP peer has been shut down on purpose, it could lead to unnecessary confusion and troubleshooting.
Advertising A Default Route Into BGP
Junos does not have a statement similar to Cisco’s default-originate for BGP peers.
Instead, you need an active default route in the routing table that can be exported into BGP using policy. This is similar to the advertisement of a directly connected route we did earlier.
We can create this route using either a static, aggregate, or generated route.
The following example shows this on vMX-2 and builds upon what we have already configured.
[edit]
lab@vMX-2# set routing-options static route 0.0.0.0/0 reject
[edit]
lab@vMX-2# set policy-options policy-statement exp-default term adv-default from protocol static
[edit]
lab@vMX-2# set policy-options policy-statement exp-default term adv-default from route-filter 0.0.0.0/0 exact
[edit]
lab@vMX-2# set policy-options policy-statement exp-default term adv-default then accept
[edit]
lab@vMX-2# set protocols bgp group my-internal-group export exp-default
[edit]
lab@vMX-2# show | compare
[edit policy-options]
+ policy-statement exp-default {
+ term adv-default {
+ from {
+ protocol static;
+ route-filter 0.0.0.0/0 exact;
+ }
+ then accept;
+ }
+ }
[edit routing-options]
+ static {
+ route 0.0.0.0/0 reject;
+ }
[edit protocols bgp group my-internal-group]
- export fix-nhs;
+ export [ fix-nhs exp-default ];
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#A few quick explanations might be required.
The default route is created using a static route. This isn’t always the best method, but it works well enough for this example.
Similar to advertising a directly connected network, the policy has a from statement matching on protocol and uses a route-filter to limit what routes are advertised. No additional terms are used, so routes will continue to be processed by later policies.
The policy was applied at the group level, meaning we now have a policy chain of fix-nhs and exp-default. Routes will be evaluated against the fix-nhs policy first, then the exp-default policy, and finally the default BGP policy.
If there was a term in fix-nhs that matched all routes and rejected them, those routes would not be evaluated against the exp-default policy.
Had we applied the exp-default at the neighbor level it would have overridden the policy at the group level. We would advertise the default, but no longer make the next hop self changes.
We can verify the default route advertisement by looking at the route table on vMX-1.
lab@vMX-1> show route protocol bgp
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:00:11, localpref 100, from 172.16.1.2
AS path: I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.1.0/24 *[BGP/170] 00:10:19, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.2.0/24 *[BGP/170] 00:10:19, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
10.0.3.0/24 *[BGP/170] 00:10:19, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
test.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1> This example works well enough in the current scenario. Advertising a default route, however, can be a bit more tricky than just setting a static route and exporting it into BGP. This isn’t the best method for all situations.
Additional BGP Verification Steps
In addition to the verification steps we took earlier, showing the BGP summary output and looking at a specific BGP neighbor, we can also look at what routes we are receiving and advertising to a given peer.
On vMX-2 we look at the routes sent to and received from vMX-3.
lab@vMX-2> show route advertising-protocol bgp 192.168.2.1
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.100.0/24 Self I
lab@vMX-2> show route receive-protocol bgp 192.168.2.1
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.1.0/24 192.168.2.1 65001 I
* 10.0.2.0/24 192.168.2.1 65001 I
* 10.0.3.0/24 192.168.2.1 65001 I
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>I’ll go into these two commands in more detail in a future post. For now, the main thing to know is that they look at the RIB-In and RIB-Out BGP tables.
The RIB-In table shows the routes as they were when received from the peer, before the effects of any configured import policy. The RIB-Out table shows routes after any export policy has been applied but before they are advertised to the BGP peer. There are a few caveats to this behavior, but these statements are mostly correct.
Summary
In this post we have done the following on Junos:
- Configure our autonomous system and router-id
- Configure an eBGP peer
- Configure an iBGP peer
- Fix iBGP next hop resolution using policy and next hop self.
- Advertise a directly connected route
- Shutdown a BGP session to a specific peer
- Advertise a default route into BGP
Further Reading
Now that you know the basics of configuring BGP on Junos devices, you may like to read the following:
- General BGP establishment troubleshooting
- Troubleshooting BGP session establishment on Junos
- Junos BGP AS Prepending example
- Junos BGP local preference example
- Junos BGP community strings example
- Junos advertising inactive BGP routes
- Junos setting BGP prefix limits
- Junos removing or replacing private AS numbers