Archive for the ‘bgp’ tag
Junos Basics – Configuring BGP
I’m stuck deep in Junos these days. I mean deep. I have an F5 load balancer and an ASA 5520; the rest of my stuff is Juniper. That means I have some learning to do.
Here’s one of the basics in Junos – configuring BGP. I guess I’ve always said that BGP is BGP. How much different can it be from IOS? Well, the end result is the same, but it’s different enough to have to look up how to do it. :) The first difference is the fact that all BGP configuration is done with groups just like peer groups in IOS. You can act like you’re configuring neighbors, but there’s no way around using groups. After going back and forth, I just settled with an group for eBGP neighbors and another for iBGP neighbors. If settings are different, I just set them in the neighbor. Here’s an example of that.
routing-options {
autonomous-system 65001;
}
protocols {
bgp {
group EBGP {
type external;
peer-as 65021;
neighbor 192.0.2.1;
}
group IBGP {
type internal;
neighbor 192.0.2.100;
}
}
}
You noticed that your own ASN isn’t configured in the BGP section, didn’t you? It’s actually configured in the routing-options configuration. Also notice the type directive there. For some reason (can someone speak to why?), you declare a group as either internal or external neighbors. If the type is external, you obviously have to declare the peer’s ASN.
This configuration won’t do very much. Actually, it pretty darn pointless. All it does is peer up with the two neighbors and accept their routes. We’re not sending them anything or doing anything funky with their routes as they come in. To do something cool, you’ll need to look at seemingly endless configuration items. Those are beyond scope here, though.
Did we configure BGP correctly? Let’s find out.
root@ROUTER> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 494478 431927 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.0.2.1 65021 3819628 58226 0 3 1w2d21h 401542/415727/415727/0 0/0/0/0 192.0.2.100 65001 3554056 3457157 0 1 2w4d6h 30385/78751/78751/0 0/0/0/0
That’s horrible output, but you can see that we have two neighbors. You can also see their ASNs, how many routes we’re getting from them, how many we’re dampening, etc. One cool thing to notice is the routing table that is being used. We’re not running routing instances on this router, so we only see “inet.0″ in the list. That’s the base routing table. If we did indeed have BGP neighbors on a configured routing instance, you’d see it listed here as well. One more thing to notice – the 431k active paths. That’s a lot of routes!
How do I know what I’m sending to my BGP neighbors? Like I said, you’re sending nothing here. The default behavior of BGP in Junos is to not send anything; you’ll have to configure a policy-statement if you want to actually advertise something. If you put in a little more config (again, beyond scope here), you can see something like this. A single route for 199.199.199.0/24 coming from our external peer. Success!
root@ROUTER> show route advertising-protocol bgp 192.0.2.1 inet.0: 431634 destinations, 494173 routes (431634 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 199.199.199.0/24 Self I
That’s good enough for now. We’ll have to fill in the gaps over time.
Send any canoe rental vouchers questions to me.
VRF-Aware IPSec Tunnels
Man, time is hard to come by of late. I’ve had so little time to rest that’s it’s hard to get my thoughts together. It’s a good thing in this case, though, since it’s my fantastic job that’s taking all my time. It’s great to see new network and learn their internals…especially when they were designed by some long-time CCIEs who actually knew what they were doing.
One of the big things that I’m dealing with lately is VRFs. I’ve implemented some VRF-lite stuff, but I’ve never had any practical experience with the full force of them. I’m definitely learning here. Since the blog here is really about my sharing what I’ve learned, let’s go through something that came up recently – terminating VPNs on one VRF while passing traffic to another.
What I’m talking about is the old-school, static IPSec VPNs that we’ve all configured a million (or so) times. You know the ones with crypto maps applied to interfaces? Well, we’re going to configured one of those for the VRF called “CUSTOMER1″ terminated on an interface in the “INTERNET” VRF.
There’s some terminology for these VRFs, actually. The INTERNET VRF, which has the tunnel endpoint is called the front VRF (FVRF); CUSTOMER1 is called the internal VRF (IVRF). I’ll try to remember to use those terms, but I make no promises.
First, we need to create the VRFs themselves. Since the endpoints are in two different VRFs, we’ll need to have some routes leaked from the IVRF to the FVRF. I could write 847829843828 words on route leaking and not cover everything in my limited experience, so you’ll have to look that up on your own if you don’t know what I’m talking about. Route-target 65000:1 is exported from INTERNET and imported into CUSTOMER1
ip vrf INTERNET rd 65000:1 route-target export 65000:1 ! ip vrf CUSTOMER1 rd 65000:101 route-target import 65000:1
At this point, we just put the interfaces in the right VRF along with their addresses. We’ll also configure an ISAKMP policy just like we’ve done a million times.
crypto isakmp policy 100 encr aes authentication pre-share group 2 ! interface Ethernet0/0 ip vrf forwarding INTERNET ip address 192.0.2.1 255.255.255.0 ! interface Ethernet0/1.1 encapsulation dot1Q 1 ip vrf forwarding CUSTOMER1 ip address 192.168.201.1 255.255.255.0
Next we’ll create a keyring that’s referenced by the IVRF. This will make the key for the remote end available for use by that VRF.
crypto keyring KEY1 vrf INTERNET pre-shared-key address 192.0.2.101 key TEST.KEY
Now we create and ISAKMP profile, which is really the blood and guts that make all this work. An ISAKMP profile references some of the important pieces of the tunnel – the IVRF in which to place the traffic, the keyring to use, and tunnel endpoint, and the FVRF where the tunnel terminates.
crypto isakmp profile CUSTOMER1-PROFILE vrf CUSTOMER1 keyring KEY1 match identity address 192.0.2.101 255.255.255.255 INTERNET
We’ll then create the ACL for interesting traffic. I’ll save some trees and not go through that since this should be pretty easy by now.
Now we can create the crypto map. This will be just like any other crypto map you’ve ever made with one exception; this is where you include that nifty ISAKMP profile we just made.
crypto map CM 100 ipsec-isakmp set peer 192.0.2.101 set transform-set TS set isakmp-profile CUSTOMER1-PROFILE match address CUSTOMER1-TRAFFIC
Just like in other cases, we need to add a static route to make sure the router sends the packets destined for the remote end of the tunnel out the right interface. Since the FVPN is INTERNET, we’ll add static routes for that VRF. We’ll do the same for the tunnel endpoint just in case the default routes doesn’t go the right way.
ip route vrf INTERNET 192.0.2.101 255.255.255.0 192.0.2.2 ip route vrf INTERNET 10.0.0.0 255.255.255.0 192.0.2.2
Now the tunnel should be up, right? Probably not. If you take a close look, you’ll see that the FVRF has the route to the remote network, but the IVRF – the one that will use the tunnel – doesn’t. We’ll need to use MPBGP to leak those routes from one VRF to another. Did I mention that route leaking can get long-winded and that I’m not going to get into it? Yeah…it can get that bad. Just trust me that this works.
What we’re going to do is to start up BGP for both VRFs. At the same time, we’ll redistribute the static routes that we added above from the FVRF into the IVRF. Since we set up our imported and exported route-targets in the VRF definition, the static routes will magically appear in both VRFs.
router bgp 65000 bgp router-id 192.0.2.1 ! address-family ipv4 vrf INTERNET redistribute static exit-address-family ! address-family ipv4 vrf CUSTOMER1 exit-address-family
If we do a show ip route vrf CUSTOMER1, we’ll see the static routes from the INTERNET VRF. They’re real easy to spot. :)
... B 10.0.0.0 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ... B 192.0.2.1 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ...
That should do it. Now you should be able to talk from your local network in the CUSTOMER1 VRF and talk through a tunnel that’s established on the INTERNET VRF.
Send any Juniper configs questions my way.
BGP Notes – Synchronization
- With synchronization on, route must be synchronized to an IGP in order for that routes to be able to be voted ‘best” by BGP.
- That means the exact route must already be in the routing table via an IGP.
- Static routes don’t count.
- This is traditionally accomplished by redistributing BGP routes into an IGP.
- With today’s Internet prefix count over 350k, this may not be such a good idea in some situations.
- Synchronization is off by default.
- Synchronization prevents black hole routes from being advertised via iBGP.
- Unless every router is participating in iBGP, there’s no guarantee that any one router will have a route to NEXT_HOP.
- Synchronization also prevents a router from advertising the black hole to an eBGP neighbor.
- You don’t want to tell the world you have a path to a prefix when you really have a !N.
- Synchronization can be safely disabled with the use of route reflectors or confederations.
—–
These are just some notes I’ve been taking. Comment with corrections, please.
BGP Notes – Backdoor Routes
- The fact that eBGP has an AD of 20 can be a problem.
- You may have a very short path via EIGRP (or OSPF or RIP or whatever other IGP), but the longer eBGP path will be preferred.
- For God’s sake, do not lower the AD of EIGRP! Havoc will ensue.
- Using backdoor routes causes eBGP routes to have an AD of 200.
- Allows the shorter-path IGP routes to be added to the routing table.
router bgp 123 network 1.1.1.0 backdoor
—–
Comment with corrections, please
BGP Notes – Route Reflectors
- Route reflectors remove the requirement of having a full mesh iBGP network.
- Any iBGP route a router reflector learns is sent to all route reflector clients.
- Non-client iBGP neighbors do not get the new route per iBGP rules.
- RR clients are configured like normal iBGP routers.
- All RR client config is done on the route reflector.
- RRs and clients are part of a cluster.
- RRs in each cluster must be neighbors with each other.
- Each cluster RR appends the cluster ID to the CLUSTER_ID PA; this is used similarly to AS_CONFED_SEQ.
- The ORIGINATOR_ID PA is set by and preserved by the RR.
- If a route contains the ORIGINATOR_ID of the receiving router, the update is ignored.
- Only best routes are passed to RR clients and non-client neighbors.
router bgp 123 no synchronization bgp cluster-id 1 neighbor 6.6.6.6 remote-as 123 neighbor 6.6.6.6 route-reflector-client
—–
Comment with corrections, please.
BGP Notes – Confederations
- RFC 3065
- BGP confederations reduce the size of full mesh iBGP ASes by dividing it up into different areas.
- Confederations also remove the need for BGP synchronization since all iBGP routers will have all routes.
- In effect, your iBGP AS gets chopped up into different sub-ASes.
- Each router is a member of a sub-AS and is a neighbor with every other router in that sub-AS (full mesh).
- Neighbors within a sub-AS are called confederation iBGP neighbors.
- Confederation iBGP neighbors act just like any other iBGP neighbor.
- At least one member of each sub-AS is neighbored with members of different sub-ASes.
- Neighbors in different sub-ASes are called confederation eBGP neighbors.
- Confederation eBGP neighbors have a default TTL of 1 just like true eBGP neighbors.
- The NEXT_HOP PA is not changed when passing routes between sub-ASes.
- LOCAL_PREF is also preserved.
- Confederations use the AS_CONFED_SEQ and AS_CONFED_SET fields in the AS_PATH PA.
- These fields act like AS_PATHs to prevent loops.
- These fields are cleared out when the route is passed to an eBGP neighbor.
- If components of a summary route (an aggregate-address) have different AS_CONFED_SEQ values, the AS_CONFED_SET is used.
- Confederations ASes are not included when the router decides which route is best.
- BGP confederation routers are configured to be in a private ASN.
- The confederations should be private to avoid AS conflicts.
- The confederation identifier defines the AS at it appears to the world.
router bgp 65001 no synchronization bgp confederation identifier 123 bgp confederation peers 65002 65003 neighbor 2.2.2.2 remote-as 65002 neighbor 3.3.3.3 remote-as 65003
—–
Comment with corrections, please.
BGP Notes – Authentication
Corrections welcome.
It’s simple as pie to enable MD5 auth to a BGP peer.
R102(config-router)#neigh 192.0.2.101 pass MYKEY
BGP Notes – Path Decision
This is required blogging…and reading for that matter. A good chunk of this is taken from my CCNP posts from last year. Corrections, please.
—–
How does a BGP router decide which BGP route is the best?
Next-hop : Does the router have a route to the next-hop?
Weight : This is a numeric value where bigger is better. Weight is not passed onto other peers and is a Cisco proprietary feature.
LOCAL_PREF : This is a numeric value where bigger is better. All iBGP peers pass this value around amongst themselves.
Local : Is the next hop me (0.0.0.0)?
AS_PATH length : This is the number of AS hops to the destination. If you don’t know this one by now, then you missed something big.
ORIGIN : Did this route come from a netowork statement in an IGP (I), from EGP (E, which shouldn’t exist any more), or somewhere else (?) like a redistributed route? I is better than E is better than ?.
MED : The Multi Exit Discriminator can be used by one AS to influence routes to that AS. The smaller the better.
Neighbor type : eBGP are better than iBGP routes.
IGP metric : Prefer the next-hop address that’s closest via an IGP like OSPF or EIGRP (or RIP, Ivan).
Route age : Prefer the oldest (and, thusly, the most stable) route.
Lowest BGP neighbor router ID : Do I have to explain that one?
Lowest BGP neighbor IP : You know what this is, right?
BGP Notes – Path Attribute Categories
Make my corrections! Please!
Well-known mandatory : These PAs must be recognized by all BGP routers and passed along to other peers.
Well-known discretionary : These PAs do not need to be in every update, but they must be recognized by all BGP routers.
Optional transitive : These PAs don’t have to be recognized but they must be passed along to other BGP peers if they are present in an update.
Optional notransitive : These PAs neither have to be recognized nor passed along.
BGP Notes – Neighbor States
Corrections appreciated.
Idle : There is no relationship, but the router sends out a TCP SYN to the neighbor to get the ball rolling.
Idle (admin) : The neighbor is admined down.
Connect : The router is waiting for the TCP connection to finish. If the TCP connection finishes, the router sends an open and transitions to OpenSent. If it times out, it transitions to Active.
Active : The router tries to initiate a TCP connection. If the TCP connection finishes, the router sends an open and transitions to OpenSent.
OpenSent : The router is waiting for an open to be returned. If one is received, the router transitions to OpenConfirm.
OpenConfirm : The router is waiting for a keepalive. If one arrives, the router transitions to Established.
Established : The neighbor relationship is complete and updates are exchanged.