2008 December

Dec 30 2008

Prefix Lists

IP Prefix lists can be used with BGP to permit or deny specific prefixes from being advertised or learnt to or from a neighbor.

Consider the topology below.

We will carry out three exercises.

configure a prefix list to match 192.168.1.0/24
configure a prefix list to match 192.168.1.0/24, 192.168.1.0/25, 192.168.1.0/26.
configure a prefix list to match 192.168.1.0/25 and 192.168.1.0/26

Exercise 1

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

router bgp 1 ! neighbor 10.0.0.2 prefix-list slash-24-only in

Exercise 2

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

router bgp 1 ! neighbor 10.0.0.2 prefix-list UP-TO-SLASH-26 in

Exercise 3

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

router bgp 1 ! neighbor 10.0.0.2 prefix-list GE-LE in

Now let me try and explain what these 3 prefix lists are actually doing.

Prefix list 1 – slash-24-only

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

This is pretty straight forward. This prefix list will match on the exact prefix as configured in the prefix list ie 192.168.1.0/24.

Prefix list 2 – UP-TO-SLASH-26

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

For a prefix to be permitted by this prefix-list the first 24 bits must match the first 24 bits of 192.168.1.0.

The le 26 then adds a subnet clause which states that the subnet mask being advertised must be less than or equal to 26 bits in length.

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

192.168.1.0/24
192.168.1.4/30
192.168.1.128/25
192.168.1.0/23
192.168.1.0/27

Prefix 1 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 2 matches the first criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list, however the subnet mask is greater than 26 bits.

Prefix 3 also matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 4 is an invalid prefix, I’ll let you work out why.

Prefix 5 matches the first criteria but fails on the subnet mask length criteria and as such the prefix is denied.

Prefix list 3 – GE-Le

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

Now this is an interesting beast. This prefix-list had 2 match clauses.

The prefix must match the first 24 bits on the prefix in the prefix list
The subnet mask must be between 25 and 26 bits in length

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

192.168.1.0/24
192.168.1.4/30
192.168.1.128/25

Prefix 1 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 2 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 3 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is greather than 25 bits buts still less than 26 bits.

I hope that makes sense. Anyhow, here is a video showing how to put it all together or alternativley click here to download and watch it on your iPod.

By zismail • BGP, CCIE, CCIE SP, CCIP, CCNP, iPod, Security • 0 • Tags: CCIE, CCIE SP, Security

Dec 28 2008

ARF – Automatic Route Filtering

When designing an MPLS network you will have to decide whether to configure a full mesh of MP-iBGP sessions between your PEs as in diagram 1 below or whether to use a hub and spoke topology as in diagram 2 below.

Diagram 1 – BGP full mesh

Diagram 2 – BGP partial mesh

The most obvious benefit of using a hub and spoke topology is that is scales a lot better than a full mesh topology. As you can see there are a lot less BGP sessions when using partial mesh design.

Automatic Route Filtering

iBGP sessions behave slightly differently with VPNv4 prefix than they do with IPv4 prefixes. Using diagram 2 as an example, In IPv4 world, R1 would send IPv4 prefixes to R3. These prefixes would be accepted by R3 and installed into the BGP table.

In VPNv4 world however this is not the case. In VPNv4 world when prefixes are learned from R1, R3 will reject(filter) the prefixes as R3 is not part of the VPN. ie R3 does not contain a vrf for those particular VPNv4 prefixes. This is known as Automatic Route Filtering, and guess what, its turned on by default. There are two ways to overcome this behavior. The first is to turn off ARF, the second is to configure R3 as a route-reflector. When you configure R3 as a route-reflector it turns ARF off by default.

Consider the toplogy below.

We will configure a VPNv4 session between R1 and R3. We will create a VPN on R1 called VPNA, which contains the prefix 192.168.1.0/24. We will redistribute this prefix into MP-BGP which will create a VPNv4 prefix and advertise it to R3. You will see by default that R3 rejects the route by default. To accept the route we will have to turn off ARF using the command below.

no bgp default route-target filter

Anyway, take a look at the video below and see ARF filtering the VPNv4 prefix or alternatively download it here and watch it on your iPod.

By zismail • BGP, CCIE SP, MPLS VPN • 3 • Tags: BGP, CCIE SP, MPLS VPN

Dec 28 2008

New Cisco Certifications Logo

I came across this link recently. It suggests that Cisco Certification Logos are changing.

Follow the link to see the new logos.

By zismail • CCIE, CCIE SP, CCIP, CCNA, CCNP • 0

Dec 27 2008

AFIs and SAFIs

BGP uses Open messages to negotiate BGP sessions. These Open messages have optional parameters which allow additional capabilities to be negotiated during setup.

If you want to run anything other than IPv4 unicast then you will have to configure BGP to advertise its additional capabilities i.e. Multi-Protocol extensions (AFI/SAFI) during initial setup.

As an example you may want to run IPv4 multicast, VPNv4 or even IPv6. The table below shows the different AFI and SAFI values. The AFI and SAFI values combine to form pairs which are used during the BGP negotiation phase. Ie if the BGP speaker wants to negotiate IPv4 multicast, then it advertises capability 1/2.

AFI	SAFI	TYPE
IPv4(1)	Unicast(1)	IPv4 Address
IPv4(1)	Multicast(2)	IPv4 Address
IPv4(1)	VPN(128)	VPNv4 Address
IPv6(2)	Unicast(1)	IPv6 Address

Lets suppose you wanted to run an MP-iBGP session between two PE routers to advertise IPv4 Unicast and IPv4 VPN(VPNv4) routes. You would need to negotiate AFI/SAFI pairs 1/1 and 1/128 during the initial BGP setup phase. If after the BGP session is established you would like to add an additional AFI/SAFI pair then BGP will have to renegotiate its capabilities which unfortunately means tearing down the original session. Some folks refer to this as BGP fate sharing.

Anyhow, lets see this in action. Consider the topology below.

Watch the video below or alternatively click here to download it and watch it on your iPod.

The commands used to configure the above can be found below.

R1
! ipv6 unicast-routing ! interface FastEthernet1/0 description "Interface connected to R2" ip address 10.0.0.1 255.255.255.252 ! router ospf 1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 10.0.0.0 0.0.0.3 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 2.2.2.2 remote-as 1 neighbor 2.2.2.2 update-source Loopback0 ! address-family ipv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community exit-address-family ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended exit-address-family ! address-family ipv6 neighbor 2.2.2.2 activate exit-address-family

R2
! ipv6 unicast-routing ! interface FastEthernet1/0 description "Interface connected to R1" ip address 10.0.0.2 255.255.255.252 ! router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.0.0.3 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 ! address-family ipv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community exit-address-family ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended exit-address-family ! address-family ipv6 neighbor 1.1.1.1 activate exit-address-family

By zismail • BGP, CCIE SP, iPod • 0 • Tags: BGP, CCIE SP

Dec 26 2008

BGP Route Aggregation

There are times when it is required to aggregate a set of prefixes. There are a number of reasons why you would want to do this such as, your peering transit edge may not accept certain size prefixes, you may want to reduce the size of the routing table in some part of your network etc etc.

Consider the topology below:-

Watch how to use the aggregate command below, or alternatively download the video and watch it on your iPod.

The commands used in the above setup are as below.

interface FastEthernet1/0 description "Interface connected to R2" ip address 10.0.0.1 255.255.255.252 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 2 no auto-summary

interface FastEthernet1/0 description "Interface connected to R1" ip address 10.0.0.2 255.255.255.252 ! interface Loopback0 ip address 192.168.0.1 255.255.255.0 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.0 ! router bgp 2 no synchronization bgp log-neighbor-changes network 192.168.0.0 network 192.168.1.0 network 192.168.2.0 network 192.168.3.0 aggregate-address 192.168.0.0 255.255.252.0 suppress-map SUPPRESS-2-ONLY neighbor 10.0.0.1 remote-as 1 no auto-summary ! access-list 1 permit 192.168.2.0 0.0.0.255 ! route-map SUPPRESS-2-ONLY permit 10 match ip address 1

By zismail • BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP, iPod • 0 • Tags: BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP

Dec 25 2008

Source Based RTBH

Consider the topology below.

PC1 sends a syn flood attack using source IP 192.168.1.1 to PC2 destination address 172.16.1.1.

The network engineer at ZeeNet spots the attack and quickly logs onto the trigger router. He adds a static route to the trigger router which states that the next hop for 192.168.1.1/32 is Null0. This static route is then redistributed into BGP and advertised using iBGP to R1. When the static route is redistributed into iBGP, the route-map attached to the redist static command changes the next hop to 192.0.2.1.

R1 has a static route which states to get to 192.0.2.1 go via the null0 interface.

R1 has Unicast Reverse Path Forwarding (URPF) configured on fa1/1. URPF is a cool technology. When a packet enter fa1/1 URPF checks the source address of the packet to see whether it has an entry in the local routing table. If there is no entry in the local routing table or the entry points to a different interface or if the entry points to null0 then the packet is dropped.

In our case, there is an entry in the local routing table for 192.168.1.1/32 which points to null0. Therefore URPF will drop the packet.

Once again, you have to understand the implications of using this approach, if for example an attacker is sending a syn flood attack to PC2 and he is spoofing address 10.10.10.1/32 for example and you black hole 10.10.10.1/32 using source based RTBH, then the actual user 10.10.10.1/32 will be black holed.

Now lets look at how to configure Source based RTBH below, or alternatively click here to download it and watch it on your iPod.

The commands used to configure Source based RTBH are as follows.

! To configure URPF on interface facing attacker.

interface FastEthernet1/1 ip verify unicast reverse-path

! Black hole static route.

ip route 192.0.2.1 255.255.255.255 Null0

Trigger router

! route-map which matches tagged static routes and sets the ip next hop as well as add a no-export community.

route-map BLACK-HOLE permit 10 match tag 100 set ip next-hop 192.0.2.1 set community no-export

! Attach the route map to redist static command under BGP.

router bgp 1 redistribute static route-map BLACK-HOLE

! Also you add a static route which you would like to black hole.

ip route 192.168.1.1 255.255.255.255 Null0 tag 100

! Black hole static route.

ip route 192.0.2.1 255.255.255.255 Null0

By zismail • CCIE SP, iPod, Security • 0 • Tags: CCIE SP, Security

Dec 24 2008

Destination Based RTBH

Chirag, this ones for you dude.

Consider the topology below.

PC1 sends a syn flood attack using source IP 192.168.1.1 to PC2 destination address 172.16.1.1.

The network engineer at ZeeNet spots the attack and quickly logs onto the trigger router. He adds a static route to the trigger router which states that the next hop for 172.16.1.1/32 is Null0. This static route is then redistributed into BGP and advertised using iBGP to R1. When the static route is redistributed into iBGP, the route-map attached to the redist static command changes the next hop to 192.0.2.1.

R1 has a static route which states to get to 192.0.2.1 go via the null0 interface.

All traffic destined to 172.16.1.1 is then black holed. You might be thinking, Whats the point of that ie ZeeNet has actually black holed the end user. This is true, but at the same time we have removed a lot of unwanted traffic from the ZeeNet network.

The above is a simple example, imagine a scenario where an attacker uses thousands of machines to generate an attack. This could amount to gigabits worth of attack traffic. ZeeNet need to protect their own infrastructure otherwise a lot more of their users will feel the attack.

Now lets look at how to configure destination based RTBH

By zismail • CCIE SP, Security • 0 • Tags: CCIE SP, Security

Dec 24 2008

Remotely Triggered Black Hole (RTBH) destination and source based introduction

RTBH is a method of creating black holes in your network, preferably at your network edge to drop any unwanted incoming traffic usually some kind of attack traffic.

There are two types of black holes you can configure in RTBH, one is source based and the other is destination based.

The black holes are created by simply forwarding the unwanted traffic towards a null0 interface. Null0 is a pseudo interface i.e. a logical interface that is always up and can never forward or receive traffic.

RTBH itself is not a feature in IOS which you turn off|on, rather it is a security model which is configured through the use of the other IOS features such as iBGP, uRPF etc.

RTBH can prevent the following types of attacks:-

DOS and DDOS attacks
Blacklist filtering

Destination based RTBH allows you to filter traffic based on the destination. This methods does not prevent a DOS or DDOS on an end user, but it can remove a lot of unwanted traffic from your network by dropping it at the network edge.

Source based RTBH allows you to filter traffic based on the source. This method can prevent a DOS attack on a particular end user by black holing the source of the attack. This methods works well but if a DOS attack is coming from a user who is changing the source addresses of the attack randomly then black holing many sources NOT only doesn’t scale well but may actually black hole the real owners of that address space.

Both methods of RTBH have their merits and can most definitely add value to your network. But like most things you just need to understand where to position it and the associated Do’s and Dont’s.

By zismail • CCIE SP, Security • 1 • Tags: CCIE SP, Security

Dec 22 2008

MPLS AToM – Pseodowires

MPLS AToM is very different to L2TP in that it does not utlize an IP header in anyway to carry data accross an MPLS network.

AToM uses LDP extended discovery ie targeted hellos to establish an LDP session with a non-directly connected neighbor.

Lets examine the topology below.

To setup a AToM circuit using the configuration below.

pseudowire-class ZARAR-AToM encapsulation mpls

interface FastEthernet1/1.1 encapsulation dot1Q 10 xconnect 3.3.3.3 10 pw-class ZARAR-AToM

pseudowire-class ZARAR-AToM encapsulation mpls

interface FastEthernet1/1.1 encapsulation dot1Q 10 xconnect 1.1.1.1 10 pw-class ZARAR-AToM

When you configure the xconnect it triggers an LDP extended discovery. A unicast LDP targetted hello is sent from R1 to R3. When R3 responds an LDP TCP session is then setup between R1 and R3. you can see the details of the session using the command below.

R1#show mpls ldp neighbor Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 2.2.2.2.21278 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 37/38; Downstream Up time: 00:26:31 LDP discovery sources: FastEthernet1/0, Src IP addr: 10.0.0.2 Addresses bound to peer LDP Ident: 10.0.0.2 10.0.0.5 2.2.2.2 Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 1.1.1.1:0 TCP connection: 3.3.3.3.39795 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 32/32; Downstream Up time: 00:20:18 LDP discovery sources: Targeted Hello 1.1.1.1 -> 3.3.3.3, active, passive Addresses bound to peer LDP Ident: 10.0.0.6 3.3.3.3

As you can see R1 has 2 neighbors, R2 and R3. Looking at the detail for neighbor 3.3.3.3 you can see it was established using an LDP targeted hello.

Traffic forwarding

When ethernet frames are received from CE1, they are double tagged as follows.

The inner tag or bottom tag is associated with the pseodowire itself. Looking at the mpls forwarding table this will be 19.

R1#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 Pop Label 2.2.2.2/32 0 Fa1/0 10.0.0.2 17 17 3.3.3.3/32 0 Fa1/0 10.0.0.2 18 Pop Label 10.0.0.4/30 0 Fa1/0 10.0.0.2 19 No Label l2ckt(10) 48090 none point2point

The outer tag or the tag used to switch the mpls frame to its final destination is the tag associated with the loopback addresses of the remote PE so in this case a label of 17 is stacked on top of the AToM label.

The traffic is then label switched using the outer label to the final destination ie R3.

Click here to see a packet capture for traffic forwarded using AToM

By zismail • AToM, CCIE SP • 0 • Tags: AToM, CCIE SP, LDP

Dec 21 2008

L2TPv3

L2TPv3 can be configured on either a physical port or on a subinterface. The first is known as Port tunneling and the second as vlan tunneling.

I have set up the topology below.

To configure port tunneling from R1 fast ethernet 1/1 to R3 fast ethernet 1/1 use the following configuration.