Posts Tagged ‘labs’
BGP Route Reflectors
Written by jlgaddis on March 8, 2010 – 8:00 am -Hopefully you recall that when running iBGP, a full mesh is required between all iBGP speaking peers within an autonomous system (AS). This can quickly lead to a huge number of peerings — and the associated management overhead — as we add more iBGP speakers. The total number of peerings needed to satisfy the full mesh requirement is illustrated by the following formula, where “n” is the number of iBGP speakers:
n(n-1)/2
Thus:
- 5 routers = 10 peerings
- 10 routers = 45 peerings
- 25 routers = 600 peerings
Would you want to manage all that? Me either. Enter route reflectors.
Route reflectors are one solution for keeping all of this under control. Route reflectors ease the full-mesh limitation and allows one router to advertise, or reflect, iBGP learned routes to other iBGP speakers. This has the end result of reducing the number of iBGP peers within our AS.
Here’s the topology we’ll be working with:
In this scenario, we’ll be running OSPF as our IGP and all routers will run iBGP and are members of AS 65000. R3 will serve as our route reflector, and all other routers only need to establish a BGP peering with R3. On R1 and R2 we’ll advertised the networks represented by the loopback0 interfaces as well.
Let’s get basic connectivity established.
R1# configure terminal R1(config)# interface serial 0/1 R1(config-if)# ip address 198.18.13.1 255.255.255.0 R1(config-if)# no shutdown
R2# configure terminal R2(config)# interface serial 0/1 R2(config-if)# ip address 198.18.23.2 255.255.255.0 R2(config-if)# no shutdown
R3# configure terminal R3(config)# interface serial 1/2 R3(config-if)# clock rate 128000 R3(config-if)# ip address 198.18.13.3 255.255.255.0 R3(config-if)# no shutdown R3(config-if)# interface serial 1/3 R3(config-if)# clock rate 128000 R3(config-if)# ip address 198.18.23.3 255.255.255.0 R3(config-if)# no shutdown R3(config-if)# interface serial 1/0 R3(config-if)# encapsulation frame-relay R3(config-if)# no shutdown R3(config-if)# interface serial 1/0.34 point-to-point R3(config-subif)# frame-relay interface-dlci 304 R3(config-fr-dlci)# ip address 198.18.34.3 255.255.255.0 R3(config-subif)# interface serial 1/0.35 point-to-point R3(config-subif)# frame-relay interface-dlci 305 R3(config-fr-dlci)# ip address 198.18.35.3 255.255.255.0
R4# configure terminal R4(config)# interface serial 0/0 R4(config-if)# encapsulation frame-relay R4(config-if)# no shutdown R4(config-if)# interface serial 0/0.34 point-to-point R4(config-subif)# frame-relay interface-dlci 403 R4(config-fr-dlci)# ip address 198.18.34.4 255.255.255.0
R5# configure terminal R5(config)# interface serial 0/0 R5(config-if)# encapsulation frame-relay R5(config-if)# no shutdown R5(config-if)# interface serial 0/0.35 point-to-point R5(config-subif)# frame-relay interface-dlci 503 R5(config-fr-dlci)# ip address 198.18.35.5 255.255.255.0
At this point, make sure you can ping all routers from R3 and vice versa.
Go ahead and configure the loopback interfaces on R1 and R2.
R1(config-if)# interface loopback 0 R1(config-if)# ip address 198.18.111.1 255.255.255.255
R2(config-if)# interface loopback 0 R2(config-if)# ip address 198.18.222.2 255.255.255.255
Let’s configure our IGP, OSPF. We’ll keep it simple since our focus is on BGP. On R3, R4, and R5 configure OSPF process ID 1 and advertise all networks, e.g.:
! on R3, R4, and R5 router ospf 1 network 0.0.0.0 255.255.255.255 area 0
On R1 and R2, we’ll just run OSPF on the links to R3 (we’re “saving” our loopbacks for BGP).
R1(config-if)# router ospf 1 R1(config-router)# network 198.18.13.1 0.0.0.0 area 0
R2(config-if)# router ospf 1 R2(config-router)# network 198.18.23.2 0.0.0.0 area 0
Make sure you’re seeing all advertised routes on all routers.
When it comes to configuring BGP, the only place we have to do anything different is on the route reflector itself. Let’s go ahead and configure R1, R2, R4, and R5 for a BGP peering to R3. On R1 and R2, we’ll advertise the IP addresses of the loopback 0 interfaces into BGP as well.
R1(config-router)# router bgp 65000 R1(config-router)# neighbor 198.18.13.3 remote-as 65000 R1(config-router)# network 198.18.111.1 mask 255.255.255.255
R2(config-router)# router bgp 65000 R2(config-router)# neighbor 198.18.23.3 remote-as 65000 R2(config-router)# network 198.18.222.2 mask 255.255.255.255
R4(config-router)# router bgp 65000 R4(config-router)# neighbor 198.18.34.3 remote-as 65000
R5(config-router)# router bgp 65000 R5(config-router)# neighbor 198.18.35.3 remote-as 65000
Next, we simply have to configure BGP on R3. We’ll use the “route-reflector-client” option to the “neighbor” command to let R3 know that the other routers should be considered as route reflector clients (intuitive, huh!?). In this case, R3 will “reflect” advertisements from one client to the others. Hence, the advertisements from R1 and R2 (for their loopback 0 interfaces) will be reflected to the other routers. We’ll be able to verify this by looking at the BGP tables on R4 and R5.
R3(config-router)# router bgp 65000 R3(config-router)# neighbor 198.18.13.1 remote-as 65000 R3(config-router)# neighbor 198.18.13.1 route-reflector-client R3(config-router)# neighbor 198.18.23.2 remote-as 65000 R3(config-router)# neighbor 198.18.23.2 route-reflector-client R3(config-router)# neighbor 198.18.34.4 remote-as 65000 R3(config-router)# neighbor 198.18.34.4 route-reflector-client R3(config-router)# neighbor 198.18.35.5 remote-as 65000 R3(config-router)# neighbor 198.18.35.5 route-reflector-client
Wait a moment for all the BGP sessions to come up (remember, BGP is sloooooow) then take a look at the BGP tables on R4 and R5.
R4(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *>i198.18.111.1/32 198.18.13.1 0 100 0 i *>i198.18.222.2/32 198.18.23.2 0 100 0 i
R5(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *>i198.18.111.1/32 198.18.13.1 0 100 0 i *>i198.18.222.2/32 198.18.23.2 0 100 0 i
That’s all there is to it! We’ve taken what normally would take a total of 10 BGP sessions and accomplished the same thing with just four. Later, we’ll talk about BGP confederations, another technique for reducing the iBGP mesh (mess).
Tags: bgp, ccnp, cisco, labs, networking | 1 Comment »
BGP Conditional Advertisements
Written by jlgaddis on March 5, 2010 – 5:39 pm -When dealing with BGP, routes are normally advertised “unconditionally”. In other words, if a peering session with a neighbor is up, we’ll send them our routes. There may be times, however, when we want to refrain from advertising a prefix (or prefixes) to a neighbor. The conditional advertisement feature, says cisco.com, “is useful for multihomed networks, in which some prefixes are advertised to one of the providers only if information from the other provider is not present (this indicates a failure in the peering session or partial reachability)”.
To explain this a little better, take a look at the following topology and let’s go through a hypothetical scenario:
In this scenario, R4 (in AS 65100) represent us. We are multi-homed to R2 (AS 65002) and R5 (AS 65005), our service providers. Our connection to R5 is at 1544 Kbps (“T-1″), our connection to R2 is 128 Kbps over a frame-relay circuit, and both SPs will be sending us a default route via BGP. Normally, we would simply advertise all of our prefixes (we’ll have two) to both providers. With a little bit of AS prepending, it may even be possible to get most of our inbound traffic to flow over the R4-R5 link.
For our hypothetical situation, we’ll advertise 203.0.113.0/24, which represents the subnet our client PCs are on, to both providers and not attempt to do any manipulation of inbound traffic. Inbound traffic may come over either link. We want to ensure that traffic inbound to our server subnet (198.51.100.0/24), however, always take the faster (R4-R5) link. Even with a bit of manipulation (e.g. AS prepending), it may not be possible to ensure that 100% of inbound traffic comes over the faster link. Enter conditional advertisements.
How we’re going to handle this is to only advertise 198.51.100.0/24 to R5. R2 won’t be receiving an advertisement for that network directly from us, so it will send inbound traffic through its other connections, eventually transiting R5 and entering our network there. But, you might ask, what happens if our R4-R5 link goes down for whatever reason? At that point, there will be no routes for 198.51.100.0/24 advertised and inbound traffic won’t have any way to reach us. Within about 60 seconds, however, the BGP process on our router will notice that we have no longer have reachability to R5 and will begin advertising the 198.51.100.0/24 network to R2. At that point, inbound traffic will begin flowing again.
As mentioned, we’ll advertise 203.0.113.0/24 (our “clients” network) to both providers, all the time. We’ll advertise 198.51.100.0/24 to R5 (and only R5), as long as that link is up. If, for some reason, it goes down, then we’ll begin advertising 198.51.100.0/24 to R2, providing inbound traffic with an alternate, albeit slower, way of reaching us.
Let’s go ahead and get basic connectivity established:
R2# configure terminal R2(config)# interface serial 0/0 R2(config-if)# encapsulation frame-relay R2(config-if)# no shutdown R2(config-if)# interface serial 0/0.24 point-to-point R2(config-subif)# frame-relay interface-dlci 204 R2(config-fr-dlci)# ip address 172.16.24.1 255.255.255.252
R4# configure terminal R4(config)# interface serial 0/0 R4(config-if)# encapsulation frame-relay R4(config-if)# no shutdown R4(config-if)# interface serial 0/0.24 point-to-point R4(config-subif)# frame-relay interface-dlci 402 R4(config-fr-dlci)# ip address 172.16.24.2 255.255.255.252 R4(config-subif)# interface serial 0/1 R4(config-if)# no shutdown R4(config-if)# ip address 172.16.14.2 255.255.255.252
R5# configure terminal R5(config)# interface serial 0/1 R5(config-if)# clock rate 2000000 R5(config-if)# no shutdown R5(config-if)# ip address 172.16.14.1 255.255.255.252
Make sure you can ping both R2 and R5 from R4. Now, let’s configure two loopback interfaces on R4 to represent our “servers” and “clients” subnets:
R4(config-if)# interface loopback 198 R4(config-if)# ip address 198.51.100.1 255.255.255.0 R4(config-if)# interface loopback 203 R4(config-if)# ip address 203.0.113.1 255.255.255.0
Configure the basic BGP session on our peers, R2 and R5. On both of these peers, we’ll send R4 a default route over BGP:
R2(config-subif)# router bgp 65002 R2(config-router)# neighbor 172.16.24.2 remote-as 65100 R2(config-router)# neighbor 172.16.24.2 default-originate
R5(config-if)# router bgp 65005 R5(config-router)# neighbor 172.16.14.2 remote-as 65100 R5(config-router)# neighbor 172.16.14.2 default-originate
On R4, we’ll do the same, with some other stuff added in. First, we need to ensure that we don’t act as a transit AS between our two providers. We’ll prevent this by creating an access list restricting what prefixes we advertise to our neighbors, and apply an outbound distribute-list to those peers. Let’s go ahead and begin advertising our two networks (to both peers, for now) as well:
R4(config-if)# access-list 25 permit 198.51.100.0 R4(config)# access-list 25 permit 203.0.113.0 R4(config)# router bgp 65100 R4(config-router)# neighbor 172.16.24.1 remote-as 65002 R4(config-router)# neighbor 172.16.24.1 distribute-list 25 out R4(config-router)# neighbor 172.16.14.1 remote-as 65005 R4(config-router)# neighbor 172.16.14.1 distribute-list 25 out R4(config-router)# network 198.51.100.0 mask 255.255.255.0 R4(config-router)# network 203.0.113.0 mask 255.255.255.0
On R4, we should now see routes for 172.16.24.1/30 and 172.16.14.1/30 (as well as our locally originated routes) in our BGP table:
R4(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path Network Next Hop Metric LocPrf Weight Path * 0.0.0.0 172.16.14.1 0 0 65005 i *> 172.16.24.1 0 0 65002 i *> 198.51.100.0 0.0.0.0 0 32768 i *> 203.0.113.0 0.0.0.0 0 32768 i
So far, so good.
Let’s make an AS path access list that defines an AS path that came directly from AS 65005
R4(config-router)# ip as-path access-list 1 permit ^65005$
Now, we need to create two more access lists. One will match the default route we receive from R5, the other will match the route we want to conditionally advertise to R2 (198.51.100.0/24).
R4(config)# access-list 5 permit 0.0.0.0 255.255.255.255 R4(config)# access-list 2 permit 198.51.100.0 0.0.0.255
Next up, we need to create two route maps (an “advertise-map” and a “non-exist-map”) and apply that config to our neighbor R2.
R4(config)# route-map ADVERTISE permit 10 R4(config-route-map)# match ip address 2 R4(config-route-map)# route-map NON-EXIST permit 10 R4(config-route-map)# match ip address 5 R4(config-route-map)# match as-path 1
Let’s go ahead and apply this to our neighbor R2 and clear the BGP process, then I’ll explain how it works.
R4(config-route-map)# router bgp 65100 R4(config-router)# neighbor 172.16.24.1 advertise-map ADVERTISE non-exist-map NON-EXIST R4(config-router)# do clear ip bgp *
What we’ve done is told our BGP process that for our neighbor 172.16.24.1 (R2), advertise the routes described by the ADVERTISE route-map (thus, routes matching ACL 2) when the routes described by the NON-EXIST route-map (thus, routes matching ACL 5 with an AS Path as described by ACL 1). It seems like a lot to digest all at once, but if you break it down into its various parts, it becomes quite clear.
Let’s take a look at our BGP tables. On R4, we should see exactly what we saw earlier: the default routes from R2 and R5 and our two locally originated routes:
R4(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path * 0.0.0.0 172.16.14.1 0 0 65005 i *> 172.16.24.1 0 0 65002 i *> 198.51.100.0 0.0.0.0 0 32768 i *> 203.0.113.0 0.0.0.0 0 32768 i
On R5, we should see routes to both of our networks 198.51.100.0/24 and 203.0.113.0/24:
R5(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *> 198.51.100.0 172.16.14.2 0 0 65100 i *> 203.0.113.0 172.16.14.2 0 0 65100 i
Last, on R2, we should only see a route to 203.0.113.0/24, since the R4-R5 link is up:
R2(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *> 203.0.113.0 172.16.24.2 0 0 65100 i
Still, so far so good. Now, we test!
Let’s go to R5 and shut down the serial 0/1 interface that’s connected to R4. This will cause the BGP session to drop, which R4 will notice and, after a moment, begin advertising the 198.51.100.0/24 network to R2.
R5(config-router)# interface serial 0/1 R5(config-if)# shutdown
Wait a moment, then look at R2’s BGP table again:
R2(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path Network Next Hop Metric LocPrf Weight Path *> 198.51.100.0 172.16.24.2 0 0 65100 i *> 203.0.113.0 172.16.24.2 0 0 65100 i
There’s the route to 198.51.100.0/24 from AS 65100, exactly what we wanted! Now, what happens when the connection between R4 and R5 comes back up?
R5(config-if)# no shutdown
The BGP session between R4 and R5 will come back up, R4 will receive the default route from R5, the BGP process will notice, and the route for 198.51.100.0/24 that is being advertised to R2 will be withdrawn:
R2(config-router)# do show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path *> 203.0.113.0 172.16.24.2 0 0 65100 i
Success!
Tags: bgp, ccnp, cisco, labs, networking | No Comments »
Configuring SNMPv3 on Catalyst switches
Written by jlgaddis on March 3, 2010 – 8:49 pm -Configuring SNMPv3 on Cisco Catalyst switches is pretty simple and is MUCH preferred over v1 or v2. SNMPv3 has three big benefits:
- authentication — we can be assured that the message originated from a valid source
- integrity — we can be assured that a packet has not been modified in transit
- encryption — no more plain-text SNMP data flying around our network
First off, we need to decide what hosts should be allowed to query our switch using SNMP. In my case, this is a single host with the IP address 192.0.2.13. We’ll create a new access control list (ACL) on the switch to restrict access to SNMP.
c3550# conf t Enter configuration commands, one per line. End with CNTL/Z. c3550(config)# ip access-list standard SNMP c3550(config-std-nacl)# permit host 192.0.2.13 c3550(config-std-nacl)# deny any log c3550(config-std-nacl)# exit c3550(config)#
Next, we’ll set the system contact and system location for the device. These values are just free-text, so you can enter whatever you want. In production, you’ll like want to use something meaningful, especially when it comes to the device location.
c3550(config)# snmp-server location Bloomington, IN, USA c3550(config)# snmp-server contact jeremy@evilrouters.net
Now, we want to create a “view” that restricts what data our SNMP user will be able to access. I’ll create a view named “MIB-2″ and allow access to the “mib-2″ MIB.
c3550(config)# snmp-server view MIB-2 mib-2 included
With our view created, we’ll create a group (“READONLY”) and assign it the read view that we just created
c3550(config)# snmp-server group READONLY v3 priv read MIB-2
Our last step is to actually create an SNMPv3 user. Here, I’ll create a user named “cacti” with randomly generated authentication and privacy passwords (used for authentication and encryption). We’ll use the HMAC SHA algorithm for authentication and 128-bit AES encryption. In addition, we’ll associate the “SNMP” ACL that we created earlier with this user.
Note #1: The passwords used here were randomly generated using “pwgen 16 2″ on FreeBSD.
Note #2: I’ve broken this command up over two lines, but the whole thing should be entered on one line.
c3550(config)# snmp-server user cacti READONLY v3 auth sha 5mJwYWFmjcgHVEP8
priv aes 128 16Y8HHbd81nHJgYq access SNMP
Exit global configuration mode and save the config.
c3550(config)# end c3550# wr Building configuration... [OK] c3550#
We should be all set. To verify, I’ll test with “snmpget” on my FreeBSD box (192.0.2.13), which is permitted by the “SNMP” ACL I created.
[jlgaddis@homer ~]$ snmpget -v 3 -u cacti -l authPriv -a sha -A 5mJwYWFmjcgHVEP8 \ -x aes -X 16Y8HHbd81nHJgYq 198.18.0.2 sysContact.0 SNMPv2-MIB::sysContact.0 = STRING: jeremy@evilrouters.net
That’s all there is to setting up SNMPv3. Now stop using the insecure v1 and v2 on your production networks!
Tags: cisco, labs, networking, privacy, security | No Comments »
Configuring Basic HSRP (Video)
Written by jlgaddis on September 19, 2009 – 9:33 am -Quick video demonstration of a basic HSRP configuration on a pair of routers:
Tags: ccnp, cisco, labs, networking, video | No Comments »
Configuring HDLC over MPLS (Video)
Written by jlgaddis on September 15, 2009 – 7:38 pm -Lately I’ve become interested in MPLS and, unfortunately, have stopped studying what I should be studying and started playing around with MPLS instead. One thing that just fascinates me is AToM, or Any Transport over MPLS. From Cisco:
“Any Transport over MPLS (AToM) is Cisco’s solution for transporting Layer 2 packets over an IP/MPLS backbone.”
In a nutshell, AToM allows us to transport a wide variety of layer 2 traffic (HDLC, PPP, Frame Relay, ATM, Ethernet, …) over an existing IP/MPLS backbone.
To demonstrate, consider the following topology:
In the topology, the P, PE1, and PE2 routers make up the service provider’s IP/MPLS backbone. P, PE1, and PE2 belong to us, the service provider, and CE1 and CE2 belong to a customer of ours. The video will show how we can provide the customer with a 256k serial (HDLC) connection over our IP/MPLS backbone. The raw HDLC frames received on the serial 1/0 interfaces of PE1 and PE2 are encapsulated in MPLS and sent over the backbone to the remote PE router, where they are decapsulated and sent back out the customer-facing serial connection.
Here’s a video demonstration so you can see just how cool this is:
Tags: cisco, labs, networking, ospf | 2 Comments »
