Simple basic Junos BGP configuration
As in the other networking vendor designs, Juniper has similar checklist in configuring basic eBGP:
- You have to identify the AS to which each of the peering routers belongs. Every AS in the world is uniquely identified by an AS number.
- You have to decide on a group for the peering session. BGP groups everything so that you can have logical sets of connections that all behave more or less the same way.
- You must know the specific IP address of the interface to which you’re connecting. This address is the neighbor address, as it’s the neighboring interface with which you are peering.
In this simple scenario we are starting out with two AS numbers in our lab 100 and 200 with directly connected eBGP neighbors. The routers Junos01 and Junos02 have startup configs of the interface IP adresses and routes.
Here is the basic diagram:
First we setup the interface IP addresses for both the routers so we can achieve connectivity.
< JUNOS01 >
interfaces {
em0 {
unit 0 {
family inet {
address 12.12.12.1/24;
}
}
}
em1 {
unit 0 {
family inet {
address 111.111.111.111/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/24;
address 11.11.11.11/24;
}
}
}
}
< JUNOS02 >
interfaces {
em0 {
unit 0 {
family inet {
address 12.12.12.2/24;
}
}
}
em1 {
unit 0 {
family inet {
address 222.222.222.222/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 2.2.2.2/24;
address 22.22.22.22/24;
}
}
}
}
After setting the IP addresses we define the Autonomous system and the Router ID number which will be used to recognize the routers in BGP update negotiation.
< JUNOS01 >
routing-options {
router-id 1.1.1.1;
autonomous-system 100;
}
< JUNOS02 >
routing-options {
router-id 2.2.2.2;
autonomous-system 200;
}
We use the IP addresses of the loopbacks as the router ID , for a natural reason of loopbacks being always active and in case of dropping the links we could achieve BGP reachability.
Next step is setting the BGP external groups with the type option and defining the peer address.
As this sounds very simple we will complicate the basic eBGP setup with another simple policy that is exporting directly attached interfaces to the BGP updates. This is a common thing an eBGP scenarios which is helpful in providing the reachability of the next hop address.
< JUNOS01 >
protocols {
bgp {
export EXP_LOOP;
group eBGP {
type external;
peer-as 200;
neighbor 12.12.12.2;
}
}
}
policy-options {
policy-statement EXP_LOOP {
term T1 {
from protocol direct;
then accept;
}
}
}
< JUNOS02 >
protocols {
bgp {
export EXP_LOOPS;
group eBGP {
type external;
peer-as 100;
neighbor 12.12.12.1;
}
}
}
policy-options {
policy-statement EXP_LOOPS {
term T1 {
from protocol direct;
then accept;
}
}
}
In the eBGP group statement we define the group as external eBGP and the peer Autonomous system. Also we should not forget the neighbor IP address.
One more thing to do is to log on to the Junos01 router and see if the eBGP session is active and if the neighbors are seeing each other.
root@JUNOS1# run show bgp neighbor
Peer: 12.12.12.2+52301 AS 200 Local: 12.12.12.1+179 AS 100
Type: External State: Established Flags: <ImportEval Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Cease
Export: [ EXP_LOOP ]
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Error: 'Cease' Sent: 1 Recv: 0
Peer ID: 2.2.2.2 Local ID: 1.1.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: em0.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)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
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 supports 4 byte AS extension (peer-as 200)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 4
Received prefixes: 5
Accepted prefixes: 5
Suppressed due to damping: 0
Advertised prefixes: 4
Last traffic (seconds): Received 13 Sent 15 Checked 44
Input messages: Total 23 Updates 2 Refreshes 0 Octets 525
Output messages: Total 25 Updates 1 Refreshes 0 Octets 578
Output Queue[0]: 0
The output of the show command tells us that the session is active and that the EXP_LOOPS policy is working fine. We are advertising loopback prefixes to our neighbors as we mentioned before.
Future Junos labs comming up.
No comments:
Post a Comment