OSPF Filter-Lists

In this post, I will go through the OSPF filter-lists (in & out) and explain how they are working.  I’ll start of with easy scenario’s, then gradually make them more complex to understand.  The thing to remember is that you can only filter type 3 LSA’s on ABRs. When filtering in or out of an area, you are actually filtering the LSA 3 in or out of the specified area. The topology I will use is shown below.

Read the rest of this entry »

OSPF Transit Capability

This post will discuss the Transit Capability feature that is enabled by default in OSPFv2 and above.  To understand the transit capability, the network needs a virtual-link involved.  So I have pre-configured the network shown in the diagram below ready for the virtual-link to be configured.  OSPF been configured with just with a very basic config to get the areas up and running. I have also configured all interfaces to use an ospf cost of 1, with the only exception that R4’s Gi1.46 interface is set with an interface cost of 10,000.

Note: All router-id’s have been configured relative to their router number. EG: R6’s Router-ID is 6.6.6.6. All interfaces IP addresses also finish the latest octect relative to their router number. EG: R6’s Gi1.46 interface is 10.0.46.6.

Read the rest of this entry »

EIGRP Wide Metric Calculation

This topic very accurately describes how the wide metric calculation works (and boy, is there a lot of bullshit on the web about this calculation with wide metrics).  Below is a simple topology to demonstrate how the EIGRP wide metrics work.

Read the rest of this entry »

Cisco ASA – Anyconnect with AD Group Authentication

This post shows you how to configure Anyconnect with AD group authentication.  i.e. Users must be part of a certain security group inside of AD in order to be authenticated on the Anyconnect client.

Below is the complete configuration.  I will run through how it works underneath.

#### AD SECTION ####
aaa-server AD protocol ldap
aaa-server AD (inside) host 1.1.1.1
 ldap-base-dn dc=google,dc=com
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-password $tr0ngP@$$w0rd
 ldap-login-dn CN=CiscoASA,OU=Service Account,OU=UK,DC=test,DC=com
 server-type microsoft
 ldap-attribute-map MAP-ANYCONNECT-LOGIN

#### TUNNEL-GROUP SECTION ####
tunnel-group ANYCONNECT_TUNNEL type remote-access
tunnel-group ANYCONNECT_TUNNEL general-attributes
 address-pool ANYCONNECT_POOL
 authentication-server-group AD
 default-group-policy NO_ACCESS
tunnel-group ANYCONNECT_TUNNEL webvpn-attributes
 group-alias CORPORATE_USERS enable
 group-url https://google.com/ANYCONNECT enable

#### GROUP-POLICY SECTION ####
group-policy NO_ACCESS internal
group-policy NO_ACCESS attributes
 vpn-simultaneous-logins 0
!
group-policy ANYCONNECT_GROUP internal
group-policy ANYCONNECT_GROUP attributes
 dns-server value 8.8.8.8
 vpn-simultaneous-logins 500
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelall
 default-domain value google.com
 webvpn
  anyconnect keep-installer installed

#### ATTRIBUTE-MAP SECTION ####
ldap attribute-map MAP-ANYCONNECT-LOGIN
map-name memberOf Group-Policy
map-value memberOf CN=ANYCONNECT_USERS,OU=Groups,OU=UK,DC=google,DC=com ANYCONNECT_GROUP

#### WEBVPN SECTION ####
webvpn
 enable outside
 anyconnect image shared:/anyconnect-win-4.4.03034-webdeploy-k9.pkg
 anyconnect enable
 tunnel-group-list enable

How this code works?

When a user goes to the login page https://google.com/ANYCONNECT, and attempts to login & download the Anyconnect client, the tunnel-group “ANYCONNECT_TUNNEL” is called. The tunnel-group states that the firewall should use AD for authenticating users. The AD section basically authenticates the firewall to AD (with the username CiscoASA), so that it can make queries with AD to authenticate users.  So, as part of the user authentication, it specifies an ldap attribute map, which is where we can state that the user must be part of a specific security group.

The attribute map states that users must be in the AD security group “ANYCONNECT_USERS”.  This group is located in the domain at the location of google.com/UK/Groups/ANYCONNECT_USERS.  If they are part of this security group, it calls the group-policy “ANYCONNECT_GROUP”.  This then sets the permissions for the Anyconnect client.

If the user is not part of this AD security group, the process changes. So when the tunnel-group calls AD, the attribute-map section fails, which causes the process to go back to the tunnel-group ANYCONNECT_TUNNEL, and hit the default-group-policy “NO_ACCESS”. This group-policy then states that zero users are permitted to login via this process.

The Gotchas

Things to watch out for when configuring this:

• In the ATTRIBUTE-MAP section, the “memberOf” is a capital O.  The cli allows you to put a lower case o, and nothing will work if you make this mistake.
• The vpn-simultaneous-logins command is required on both the NO_ACCESS group-policy as well as the ANYCONNECT_GROUP group-policy.  Failure to specify a number in the ANYCONNECT_GROUP group-policy can cause the “vpn-simultaneous-logins 0” setting to be inherited, causing login issues.

Juniper SRX NAT Configuration Examples

In this section I will demonstrate various NAT configurations that would typically be used in a production environment.  The topology I’ll be working with is shown below.

Current Configuration

Each of the three routers have a default route that point towards the SRX. And the SRX has been configured with a security policy that essentially performs the following:

• Trust zone is permitted to any zone
• DMZ is only permitted to the untrust zone
• Untrust is not permitted anywhere

Read the rest of this entry »

Basic Juniper SRX Setup

This guide goes over the basics for setting up a Juniper SRX firewall. The bullet points below identify what is covered in this article.

• Root password setup
• Basic IP address configration
• Remote access managment: HTTP & HTTPS setup (for J-Web browser application), and SSH
• Ping to the SRX
• Basic security zone & policy configuration.  I will permit R2 (untrust zone) to ping R1 (trust zone)

Note:  The SRX I’m using is a virtual platform on GNS3, and has been loaded with factory default configuration.

Diagarm

Read the rest of this entry »

MTU Values And Ping Sizing On Cisco Products

This is an deep dive into understanding the layer 2 and layer 3 MTU settings, as well as understanding what MTU value is actually being used when you are sending pings with different sizes.  There’s more to it than actually meets the eye on the CLI.

I’ve strung a couple of switches together to setup test environment.  The 10 gig interfaces will be set to use an MTU of 9216, then I’ll discuss what this means at layer 2 and 3.

Configuration

6500
interface TenGigabitEthernet1/1
no switchport
mtu 9216
ip address 1.1.1.1 255.255.255.0

6880
interface TenGigabitEthernet1/1/1
no switchport
mtu 9216
ip address 1.1.1.2 255.255.255.0

As you can see, both sides have their layer 2 MTU value set to 9216.  This value is actually the maximum allowed size of the Ethernet frame before the layer 2 headers and FCS value (i.e. the CRC check) are are added.

A traditional 802.3 datagram is 1518 bytes large, which would break down into:

• Destination address = 6 bytes
• Source address = 6 bytes
• Type/Length = 2 bytes
• FCS = 4 bytes
• Data/Payload = 1500 Bytes

Read the rest of this entry »

BGP Recursive Routing Failure

I came across an really awesome problem about a BGP next hop recursion failure that you can run into. I bet you I get asked this when I do my CCIE lab exam. Let me show you a basic BGP network setup and introduce a very annoying problem to solve. Below is the network, along with the current configurations underneath.

R1#
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 150.1.2.2 remote-as 2
 neighbor 150.1.2.2 ebgp-multihop 2
 neighbor 150.1.2.2 update-source Loopback0
 no auto-summary
!
interface Loopback0
 ip address 150.1.1.1 255.255.255.255
!
 ip route 150.1.2.0 255.255.255.0 10.0.12.2

R2#
router bgp 2
 no synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 150.1.1.1 remote-as 1
 neighbor 150.1.1.1 ebgp-multihop 2
 neighbor 150.1.1.1 update-source Loopback0
 no auto-summary
!
interface Loopback0
 ip address 150.1.2.2 255.255.255.255
!
ip route 150.1.1.0 255.255.255.0 10.0.12.1

Read the rest of this entry »

Understanding The OSPF Forwarding Address

There seems to be a lot of confusion on the web about what the OSPF forwarding address is. So I’ve decided to create a lab to show its purpose and how it works.

In this lab I used the topology below to create the scenario in which it was designed for. The actual use case was for BGP instead of EIGRP, but my IOS image was crap & didn’t support BGP, so I could only use EIGRP for this lab (however, the principle is exactly the same).

R1, R2 and R3 have interfaces in OSPF area 0. R2 & R3 also have an OSPF relationship in Area1 over the LAN segment connecting to the switch. But only R2 is running EIGRP with R4.

In this scenario (before ospf was actually modified by the people who created the protocol to allow a non-zero value for the forwarding address) only R2 does the redistribution between EIGRP and OSPF. What this means is that all routers (including R3) have to go via R2 in order to reach 200.1.1.1. The reason why is because R2 advertises that in order to reach 200.1.1.1/32 everyone must solve the shortest path to me (the ASBR), and then R2 knows the shortest path to the destination.

So when this issue was pointed out to John Moy (one of the OSPF engineers), he sat down and figured that providing all links are of equal bandwidth in this network, wouldn’t it be better if R3 just went directly towards R4 to reach 200.1.1.1/32 instead? Since all R2 is going to do is send the traffic to the next hop IP (10.0.100.4) that is on the same Ethernet segment as R3 anyways, it doesn’t seem logical that R3 should have to take a path via R2 first. The engineers then decided to then change OSPF so that R2 could just say that to reach 200.1.1.1, just solve the shortest path to 10.0.100.4 instead. We will take a look at how this is achieved in the lab in just a moment. But I want you to know is that this was original reason for allowing the forwarding to be changed.

Read the rest of this entry »

OSPF NSSA Translator Election & Forwarding Address

In this section I will look at who does the NSSA type 7 to 5 translation & how we can use the forwarding address to control routing towards external routes that have been brought into the OSPF domain via an NSSA. The topology we will use is below. Currently R4 is redistributing the 99.0.0.0/24 prefix into OSPF and all routers have reachability to it.

In a network like above, only one ABR router connected to the NSSA is elected to do the LSA type 7 to 5 translation for the EIGRP route 99.0.0.0/24. The decision is based on who has the highest router-id. So if we look at the OSPF database for this external prefix on R1, we should see that the advertising router is R3 (3.3.3.3) because his router-id is higher than R2 (2.2.2.2) and therefore did the translation. Read the rest of this entry »