BGP Next-hop-Self explained

How and when to use BGP next-hop-self

I have created a small ISP scenario with a Customer and an Upstream router to simulate yet another BGP command that is used often in BGP scenarios. As we all know BGP advertises destinations, but to use those destinations BGP protocol also is using a next-hop value inside a BGP update message.

For starters let us look at the diagram. 

I have preconfigured the BGP proccess with the coressponding Autonomous systems. In this scenario we are using simulated WAN links between the BGP speaking routers as the neighbor addresses. We are not using an eBGP multihop, or no distribution. This is how we will see the problem and the solution. Now let us take look at the configs.

ISP1

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.1 255.255.255.252  << Wan link to iBGP router

 duplex auto

 speed auto

!

interface FastEthernet2/0

 ip address 192.168.1.1 255.255.255.252  << link to Customer

 duplex auto

 speed auto

!

router ospf 1

 router-id 1.1.1.1

 log-adjacency-changes

 passive-interface FastEthernet2/0

 network 172.16.1.0 0.0.0.3 area 0

!

router bgp 500

 no synchronization

 bgp router-id 1.1.1.1

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255

 neighbor 172.16.1.2 remote-as 500

 neighbor 192.168.1.2 remote-as 1

 no auto-summary

ISP2

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 ip address 172.16.1.2 255.255.255.252   << link to iBGP neighbor

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.3.1 255.255.255.252 <<link to UPSTREAM

 duplex auto

 speed auto

!

router ospf 1

 router-id 2.2.2.2

 log-adjacency-changes

 passive-interface FastEthernet1/0

 network 172.16.1.0 0.0.0.3 area 0

!

router bgp 500

 no synchronization

 bgp router-id 2.2.2.2

 bgp log-neighbor-changes

 network 2.2.2.2 mask 255.255.255.255

 neighbor 172.16.1.1 remote-as 500

 neighbor 192.168.3.2 remote-as 100

 no auto-summary

We can now verify the bgp neighborships between the iBGP routers inside the ISP domain. Everything is ok and the prefixes are being received.

ISP1#sh ip bgp summary

BGP router identifier 1.1.1.1, local AS number 500

BGP table version is 14, main routing table version 14

5 network entries using 585 bytes of memory

5 path entries using 260 bytes of memory

5/4 BGP path/bestpath attribute entries using 620 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1513 total bytes of memory

BGP activity 8/3 prefixes, 9/4 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.16.1.2      4   500         56      57           14            0              0 00:24:42        2

The configs on the other two router are very similar. We are only advertising the loopbacks.

CUSTOMER

interface Loopback0

 ip address 10.10.10.10 255.255.255.255

!

interface Loopback1

 ip address 100.100.100.1 255.255.255.0

!

interface Loopback2

 ip address 50.50.50.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.1.2 255.255.255.252

 duplex auto

 speed auto

!

router bgp 1

 no synchronization

 bgp router-id 10.10.10.10

 bgp log-neighbor-changes

 network 50.50.50.0 mask 255.255.255.0

 network 100.100.100.0 mask 255.255.255.0

 neighbor 192.168.1.1 remote-as 500

 no auto-summary

UPSTREAM

interface Loopback0

 ip address 5.5.5.5 255.255.255.255

!

interface Loopback1

 ip address 200.200.200.1 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.3.2 255.255.255.252

 duplex auto

 speed auto

!

router bgp 100

 no synchronization

 bgp router-id 5.5.5.5

 bgp log-neighbor-changes

 network 200.200.200.0

 neighbor 192.168.3.1 remote-as 500

 no auto-summary

We should achieve full BGP meshed routing tables inside the ISP autonomous system. If we see that is not the case. Let us se what networks the Customer is advertising.

CUSTOMER#sh ip bgp neighbors 192.168.1.1 advertised-routes

BGP table version is 13, local router ID is 10.10.10.10

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 50.50.50.0/24    0.0.0.0                  0         32768 i

*> 100.100.100.0/24 0.0.0.0                  0         32768 i

Total number of prefixes 2

We see two prefixes from the customer. We shall now see the output from the BGP RIB table inside the second router of the ISP Autonomous system.

ISP2#sh ip bgp

BGP table version is 8, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       172.16.1.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

* i50.50.50.0/24    192.168.1.2              0    100      0 1 i

* i100.100.100.0/24 192.168.1.2              0    100      0 1 i

*> 200.200.200.0    192.168.3.2              0             0 100 i

Two prefixes learned from customers (50.50.50.0/24 and 100.100.100.0/24) are inside the BGP table, but there is no > sign. This means that they will not be inside the routing table and shall not be advertised to the eBGP neighbor Upstream. The mein problem is that the ISP2 router cannot reach the NEXT HOP address.

ISP2#sh ip route 192.168.1.2

% Network not in table

To remedy this problem we will use the next-hop-self command under the BGP proccess of the ISP1 routers. This command will tell the iBGP speaking router to change the BGP next-hop attribute to the known IP address to the router ISP2. This attribute is preserved in eBGP connections, thus the next-hop is not seen by the ISP2 router.

ISP1(config-router)#neighbor 172.16.1.2 next-hop-self

Now we can take look at the RIB table of the ISP2 router.

ISP2#sh ip bgp

BGP table version is 10, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       172.16.1.1               0    100      0 i

*> 2.2.2.2/32       0.0.0.0                  0         32768 i

*>i50.50.50.0/24    172.16.1.1               0    100      0 1 i

*>i100.100.100.0/24 172.16.1.1               0    100      0 1 i

*> 200.200.200.0    192.168.3.2              0             0 100 i

As the routing plane is in fuction the data plane is working fine. We can use a simple ping to verify that.

ISP2#ping 100.100.100.1 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:

Packet sent with a source address of 2.2.2.2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/48/64 ms

Thanks !!!

Site-to-Site IPSEC VPN

Implement basic VPN 

Using this small LAB I will try to demonstrate and elaborate an site to site VPN that focuses on Cisco IOS routers. The emulated hardware is of Cisco 7200 series that allows us every IPSEC mechanism that we need for this demonstration. For network engineers this could be useful on a multi site level, depending on the type of encryption they need. So let us start with a diagram.

For the initial LAB setup we need to configure IP addresses for the WAN links and the Loopback interfaces on each router. After that we should add static routes to communicate between the loopbacks.

R1

interface GigabitEthernet1/0

 ip address 10.1.12.1 255.255.255.0

 negotiation auto

end

!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

end

!

ip route 2.2.2.2 255.255.255.255 10.1.12.2

R2

interface GigabitEthernet1/0

 ip address 10.1.12.2 255.255.255.0

 negotiation auto

end

!

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

end

!

ip route 1.1.1.1 255.255.255.255 10.1.12.1

Simple enough ! Now we have a connection between the loopbacks of the routers. First off all, as we get on the actual IPSEC configs we must clarify which technologies we are using.

ISAKMP (Internet Security Association and Key Management Protocol) is a protocol defined by RFC 2408 for establishing Security Associations (SA) and cryptographic keys in an Internet environment. ISAKMP only provides a framework for authentication and key exchange and is designed to be key exchange independent; protocols such as Internet Key Exchange and Kerberized Internet Negotiation of Keys provide authenticated keying material for use with ISAKMP. This framework does not specify any details on key managament or key exchange. 

Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication which are either pre-shared or distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

IKE has two phases that we will be involved later. IKE Phase 1 happens when two peers establish a secure security policy and authentification keys if needed. In IKE Phase 2 Security Associations are negotiated on behalf of services such as IPSEC that needs keying material.

First, we have to configure an ISAKMP policy on R1:

R1

crypto isakmp policy 10

 encr 3des

 hash md5

 authentication pre-share

 group 2

crypto isakmp key cisco address 10.1.12.2

After this we go on to the second phase IKE phase 2 and configure the transform set, similar to ISAKMP policies are the seeting suites to choose from. Also wee need to mark the interesting traffic and we should do this with an ACL. To bind everything together we should create a MAP and apply that map to an egress interface.

R1

crypto ipsec transform-set FIRST esp-3des esp-md5-hmac

!

crypto map MAP 10 ipsec-isakmp

 set peer 10.1.12.2

 set transform-set FIRST

 match address 120

!

access-list 120 permit ip host 1.1.1.1 host 2.2.2.2

Finally to be done with the R1 we will apply this map to an interface.

R1

interface GigabitEthernet1/0

 crypto map MAP

*Aug 27 10:36:52.151: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

We should repeat the same config on the second router, chaning only the peer IP of the key in the ISAKMP policy and the ACL.

R2

crypto isakmp policy 10

 encr 3des

 hash md5

 authentication pre-share

 group 2

crypto isakmp key cisco address 10.1.12.1

!

crypto ipsec transform-set FIRST esp-3des esp-md5-hmac

!

crypto map MAP 10 ipsec-isakmp

 set peer 10.1.12.1

 set transform-set FIRST

 match address 120

!

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface GigabitEthernet1/0

 ip address 10.1.12.2 255.255.255.0

 negotiation auto

 crypto map MAP

!

ip route 1.1.1.1 255.255.255.255 10.1.12.1

!

access-list 120 permit ip host 2.2.2.2 host 1.1.1.1

We can now test the traffic data plane with a simple ping.

R1#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/28/56 ms

We have a succesfull ping traffic from boot loopack addresses. To finally verify the IPSEC SA and policies we can use the following show output.

R1#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst                 src               state              connid       status

10.1.12.2      10.1.12.1     QM_IDLE     1005        ACTIVE

This is a normal state of IKE. QM_IDLE means that the Quick Mode Phase 2 has been finished.

This is all for now. More to come. 

Feel free to comment.

BGP Filtering AS-PATH traffic

Traffic engineering with BGP AS-PATH ACL

A short time ago I have sumbled upon this small lab with 4 BGP AS routers that I will use today to simulate traffic engineering via the BGP control plane. Diagram is showing 4 routers, presenting themself as four independent Autonomous Systems, that can be servicing many clients in their AS. I have preconfigured the simulated WAN links and router BGP processes for all of the routers. 

A couple of tasks I have found on that lab that are important to be completed. 

1. We must ensure that the AS 1 does not become transit AS
2. Prevent router R3 to send prefixes from AS2 to AS4
3. Configure AS4 not to receive any prefixes from AS1.

Now let us look at the diagram and see the config scripts.

At the initial configurations we can see that we have eBGP sessions with all of four eBGP speakers. We are using simulated wan links between routers as update sources for BGP information. And I have advertised a couple of loopbacks to have some prefixes to play with.

R1

interface Loopback0

 ip address 2.2.2.2 255.255.255.0

!

interface Loopback1

 ip address 22.22.22.22 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.12.2 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.23.2 255.255.255.0

 duplex auto

 speed auto

!

router bgp 2

 no synchronization

 bgp log-neighbor-changes

 network 2.2.2.0 mask 255.255.255.0

 network 22.22.22.0 mask 255.255.255.0

 neighbor 192.168.12.1 remote-as 1

 neighbor 192.168.23.3 remote-as 3

 no auto-summary

R2

interface Loopback0

 ip address 4.4.4.4 255.255.255.0

!

interface Loopback1

 ip address 44.44.44.44 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.12.1 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.14.1 255.255.255.0

 duplex auto

 speed auto

!

router bgp 1

 no synchronization

 bgp router-id 4.4.4.4

 bgp log-neighbor-changes

 network 4.4.4.0 mask 255.255.255.0

 network 44.44.44.0 mask 255.255.255.0

 neighbor 192.168.12.2 remote-as 2

 neighbor 192.168.14.4 remote-as 4

 neighbor 192.168.14.4 update-source FastEthernet1/0

 no auto-summary

R3

interface Loopback0

 ip address 3.3.3.3 255.255.255.0

!

interface Loopback1

 ip address 33.33.33.33 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.34.3 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.23.3 255.255.255.0

 duplex auto

 speed auto

!

router bgp 3

 no synchronization

 bgp log-neighbor-changes

 network 3.3.3.0 mask 255.255.255.0

 network 33.33.33.0 mask 255.255.255.0

 neighbor 192.168.23.2 remote-as 2

 neighbor 192.168.23.2 update-source FastEthernet1/0

 neighbor 192.168.34.4 remote-as 4

 no auto-summary

R4

interface Loopback0

 ip address 5.5.5.5 255.255.255.0

!

interface Loopback1

 ip address 55.55.55.55 255.255.255.0

!

interface FastEthernet0/0

 ip address 192.168.14.4 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet1/0

 ip address 192.168.34.4 255.255.255.0

 duplex auto

 speed auto

!

router bgp 4

 no synchronization

 bgp log-neighbor-changes

 network 5.5.5.0 mask 255.255.255.0

 network 55.55.55.0 mask 255.255.255.0

 neighbor 192.168.14.1 remote-as 1

 neighbor 192.168.14.1 update-source FastEthernet0/0

 neighbor 192.168.34.3 remote-as 3

 no auto-summary

For the first task we should prevent R2 to become a Transit provider. We can do this using a AS-PATH access list that will allow only prefixes originated inside the AS, the string should be empty in the AS-PATH.

So I will create an AS-PATH acl:

ip as-path access-list 23 permit ^$

This I would apply to the both neighbors to the outside direction.

neighbor 192.168.12.2 filter-list 23 out

neighbor 192.168.14.4 filter-list 23 out

Now we can verify that only R2 prefixes are being advertised to the neighbors.

R2#sh ip bgp neighbors 192.168.12.2 advertised-routes

BGP table version is 27, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 4.4.4.0/24       0.0.0.0                  0         32768 i

*> 44.44.44.0/24    0.0.0.0                  0         32768 i

Total number of prefixes 2

R2#sh ip bgp neighbors 192.168.14.4 advertised-routes

BGP table version is 27, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 4.4.4.0/24       0.0.0.0                  0         32768 i

*> 44.44.44.0/24    0.0.0.0                  0         32768 i

Total number of prefixes 2

Next step is to configure R3 not to advertise prefixes from AS2 to AS4. This can be also done via an filter-list and the AS-PATH acl. This ACL is denying everything that has an AS2 in the PATH, and permiting everything else.

ip as-path access-list 111 deny ^2_

ip as-path access-list 111 permit .*

And apply it to the neighbor.

neighbor 192.168.34.4 filter-list 111 out

We can verify this action on the router in the AS4. We should not see any prefix originated from AS2.

R4#sh ip bgp

BGP table version is 17, local router ID is 55.55.55.55

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 3.3.3.0/24       192.168.34.3             0             0 3 i

*> 5.5.5.0/24       0.0.0.0                  0         32768 i

*> 33.33.33.0/24    192.168.34.3             0             0 3 i

*> 55.55.55.0/24    0.0.0.0                  0         32768 i

In the RIB table of the R4 we cannot see any AS2 paths. So the task is done.

The final task is to deny R4 on accepting any prefixes that are originating in AS1. This also can be done via a simple IP-AS Path access list. This list will filter inside information from the AS1 neighbor and deny any AS1 originated prefixes. And of course the last line should allow all other prefixes.

ip as-path access-list 1 deny _1$

ip as-path access-list 1 permit .*

Then we should apply this ACL as a inside filter list on the neighbor in the AS1 domain.

 neighbor 192.168.14.1 filter-list 1 in

Once more to verify this we will look at the RIB of the BGP speaking router R4.

R4#sh ip bgp

BGP table version is 17, local router ID is 55.55.55.55

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 3.3.3.0/24       192.168.34.3             0             0 3 i

*> 5.5.5.0/24       0.0.0.0                  0         32768 i

*> 33.33.33.0/24    192.168.34.3             0             0 3 i

*> 55.55.55.0/24    0.0.0.0                  0         32768 i

We can see for certain that there are no prefixes with the AS1 in the path. So we have achieved every goal. This small scenario is great to play with, but it gets complicated in larger networks. For those who want to explore and understand more of the BGP regular expression can visit the Cisco page.

Feel free to comment.

Thanks.

Create and recover a snapshot under ESXi hypervisor

Restore virtual Ubuntu server using snapshots

For this short blog I am using an ESXi 4.1 hypervisor on an actual hardware and a virtualized Ubuntu server. I will try do demonstrate a quick and easy restore procedure of the VMs that the free version of the vSphere 4.1 package let's us use. The steps are followed with in an screen shot terms.

Firs let us see the inital setup of the vClient for the ESXi 4.1 free version.

From this screen we can see a couple of VMs that are running on one ESXi host. In the root of the file structure I have created a folder called TEST. After this I will create a snapshot of the virtual machine. 

After a while the process of snapshot creation is finished.

On the next step I will SSH to the Ubuntu server and delete the created TEST under the root of the file structure. This folder is important to us , so I will delete it.

Now, with the folder lost I have to revert to the previous state of the VM. This can be done via the Snapshot manager consoled under the current VM options.

And after a couple of second we can verify in the console log that the machine has been successfully restored.

Now what is left , is to check if the folder and a single file are back where they belong.

The folder TEST is reverted to its former location without any errors. This is a very cool feature vSphere technologies let's us use but it cannot be a true backup system. Snapshots are not meant to be a robust method of backup and recovery. If the files containing a virtual machine are lost, its snapshot files are also lost. 

We can look at this technology similar to the Microsoft VSS, that is used for ESXi VMs. One should always store the .VHD files on another location for a true backup system.

Feel free to comment.

Thanks.

VTP domain Enterprise Client/Server

Vlan domain design (STP, VTP, GUARD) security

Here we have a typical (single point of failure) Enterprise Campus network design spread across two sites. We have a distribution layer missing, I think because of the budget cuts, so this design implements a Core and Access layers to the users. The hierarchy deploys Core/Access topology with following elements:

• Two buildings, two sites 
• Two Core swtiches, Layer 3 capable
• Two PBX servers (not configured , only IP address assigned for simulation)
• Several access Layer 2 swithches and
• User workstations and VOIP terminals

This case scenario setup has been designed to comply with a cross site VTP domain. All the switches L3 and L2 are joined in a single domain. The two layer 3 core swithces play the role of a VTP server, as the other C2960 are configured as a VTP clients. I am using Packet tracer to simulate this.

Now lets look at some configuration scripts to elaborate on them further.

Core switch allocated in SITE 2:

hostname L3SW1
ip dhcp excluded-address 172.16.1.1
ip dhcp excluded-address 192.168.100.1
!
ip dhcp pool VOICE_1
 network 172.16.1.0 255.255.255.0
 default-router 172.16.1.1
 option 150 ip 172.16.1.1
ip dhcp pool DATA_VLAN_1
 network 192.168.100.0 255.255.255.0
 default-router 192.168.100.1
ip routing
!
spanning-tree mode rapid-pvst
spanning-tree vlan 100,200-201,300-301,500,999 priority 24576
spanning-tree vlan 1,101,202,350 priority 28672
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/1
 switchport trunk native vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/2
 switchport trunk native vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree guard root
!
interface FastEthernet0/3
 switchport trunk native vlan 200
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree guard root
!
interface Vlan1
 no ip address
 shutdown
!
interface Vlan100
 description VOICE_VLAN_1
 ip address 172.16.1.1 255.255.255.0
!
interface Vlan200
 no ip address
!
interface Vlan201
 description DATA_VLAN_1
 ip address 192.168.100.1 255.255.255.0
!
interface Vlan300
 ip address 100.100.100.1 255.255.255.0
!
interface Vlan301
 ip address 200.200.200.1 255.255.255.0
!
interface Vlan500
 description MGMT_VLAN
 ip address 10.10.10.1 255.255.255.0
!
router eigrp 10
 network 10.10.10.0 0.0.0.255
 network 172.16.1.0 0.0.0.255
 network 192.168.100.0

 no auto-summary

Core switch allocated in SITE 1:

hostname L3SW2

!

ip dhcp pool VOICE_2

 network 17.19.1.0 255.255.255.0

 default-router 17.19.1.1

 option 150 ip 17.19.1.1

ip dhcp pool DATA_VL_2

 network 192.168.200.0 255.255.255.0

 default-router 192.168.200.1

ip routing

!

spanning-tree mode rapid-pvst

spanning-tree vlan 1,101,202,350 priority 24576

spanning-tree vlan 201 priority 28672

!

interface Loopback0

 ip address 10.0.0.2 255.255.255.255

!

interface FastEthernet0/1

 switchport trunk native vlan 200

 switchport trunk encapsulation dot1q

 switchport mode trunk

!

interface FastEthernet0/2

 switchport trunk native vlan 200

 switchport trunk encapsulation dot1q

 switchport mode trunk

 spanning-tree guard root

!

interface FastEthernet0/3

 switchport trunk native vlan 200

 switchport trunk encapsulation dot1q

 switchport mode trunk

 spanning-tree guard root

!

interface FastEthernet0/4

 switchport trunk native vlan 200

 switchport trunk encapsulation dot1q

 switchport mode trunk

!

interface Vlan1

 no ip address

 shutdown

!

interface Vlan101

 description VOICE_VLAN_2

 ip address 17.19.1.1 255.255.255.0

!

interface Vlan202

 description DATA_VLAN_2

 ip address 192.168.200.1 255.255.255.0

!

interface Vlan350

 description MARK_VL1_###

 ip address 201.200.201.1 255.255.255.0

!

interface Vlan500

 description MGMT_VLAN

 ip address 10.10.10.2 255.255.255.0

!

router eigrp 10

 network 10.10.10.0 0.0.0.255

 network 192.168.200.0

 network 17.19.1.0 0.0.0.255

 network 201.200.201.0

 no auto-summary

On the current working config scripts we can see that I have chosen the Cisco propriearity EIGRP routing protocol to advertise subnets between the SITES. The links between the core and access switches are configured as trunks with Native VLAN capability. Vlan 200 is chosen for this option.

On both sides configured on the VTP server switches we have voice and data VLANs. VLANs that are numbered 100 and 201 are used on the site 2 access switches and on the Site 1 we have VLANs 101 and 202 for voice and telephony network traffic. VLAN 500 is configured for managament purposes of the equipment. I have implemented the Rapid Per Vlan spanning tree protocol for a faster recovery and better convergence time. A show output will elaborate on how many VLANs are configured.

L3SW1#sh spanning-tree summary 

Switch is in rapid-pvst mode

Root bridge for: VOICE_1 DATA_1 DATA_VLAN_1 SRV_VL_1 MARK_VL_1 MGMT VLAN0999

Extended system ID           is enabled

Portfast Default             is disabled

PortFast BPDU Guard Default  is disabled

Portfast BPDU Filter Default is disabled

Loopguard Default            is disabled

EtherChannel misconfig guard is disabled

UplinkFast                   is disabled

BackboneFast                 is disabled

Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active

---------------------- -------- --------- -------- ---------- ----------

VLAN0001                     0         0        0          3          3

VLAN0100                     0         0        0          3          3

VLAN0101                     0         0        0          3          3

VLAN0200                     0         0        0          3          3

VLAN0201                     0         0        0          3          3

VLAN0202                     0         0        0          3          3

VLAN0300                     0         0        0          3          3

VLAN0301                     0         0        0          3          3

VLAN0350                     0         0        0          3          3

VLAN0500                     0         0        0          3          3

VLAN0999                     0         0        0          3          3

---------------------- -------- --------- -------- ---------- ----------

11 vlans                     0         0        0         33         33

On the current output we can see the L3 switch on the site 1 is the root bridge for the VLANs that I have chosen to be. This is done using the following command: L3SW1(config)#spanning-tree vlan 999 root primary. The idea is to keep the VLANs on the site 1 to have a root server as corresponding Layer 3 switch in the current site. This way we can stop from flooding the STP packets and unnecessary BPDUs over the trunk link between the core switches. 

The DHCP pools are configured for data and voice vlan. So we can see the bindings of the end stations and the DCHP database that is residing on the L3 switch in SITE 2.

L3SW1#sh ip dhcp binding 

IP address       Client-ID/              Lease expiration        Type

                 Hardware address

172.16.1.2       000A.F393.9CA5           --                     Automatic

192.168.100.2    0050.0F92.BBD2           --                     Automatic

192.168.100.3    0001.C794.E920           --                     Automatic

The users attached to a Layer 2 swtiches are getting proper IP address from the coresponding VLAN that they have been assigned to. Now we can see on the Layer 2 , switch 2 the status of a current VLAN and the config scripts (L2 switch number 2 - site 2).

hostname L2SW1

!

spanning-tree mode rapid-pvst

!

interface FastEthernet0/1

 switchport trunk native vlan 200

 switchport mode trunk

!

interface FastEthernet0/2

 switchport access vlan 201

 switchport mode access

 switchport voice vlan 101

!

interface Vlan1

 no ip address

 shutdown

!

interface Vlan500

 ip address 10.10.10.51 255.255.255.0

A very simple config allows the trunking to happen with L3 switch. The FastEthernet0/2 interface is configured as an access switch. This allows the PBX server to communicate via the data VLAN in our case this is VLAN 201. To see that the root bridge server for a data vlan in this output will tell us that we are using L3 switch MAC address.

L2SW1#sh spanning-tree vlan 201

VLAN0201

  Spanning tree enabled protocol rstp

  Root ID    Priority    24777

             Address     0009.7C51.A730

             Cost        19

             Port        1(FastEthernet0/1)

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32969  (priority 32768 sys-id-ext 201)

             Address     0004.9A34.59C3

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/1            Root FWD 19        128.1    P2p

Fa0/2            Desg FWD 19        128.2    P2p

One more feature that I thaught that is missing, was a s security protection of the Root bridge. Every trunk interface of the Layer 3 switch connected to the access switch is configured with the Root Guard enhancement -  spanning-tree guard root. This feature listens on the interface for superior BPDUs from the access swithces and denies the L2 switches to become the root bridge for a VLAN, as this is a task for a Layer 3 core switch. This seems a bit of harsh, but when you have 5000 clients on a single VLAN, if the root bridge is compromised by an attacker, he can bring the STP mechanism and the network down in seconds.

We can see this feature in action when I create a new VLAN on the Core switch called 555. The debug output on the core swtich tells us the he has gotten superior BPDUs from the Fa0/3 interface, that is connected to the Layer 2 switch.

L3SW1# 

%SPANTREE-2-ROOTGUARDBLOCK: Port 0/3 tried to become non-designated in VLAN 555.

Moved to root-inconsistent state

An we can see the output of the L2 switch that it assumes that he is elected the root bridge for the VLAN 555:

L2SW2# sh spanning-tree vlan 555

VLAN0555

  Spanning tree enabled protocol rstp

  Root ID    Priority    33323

             Address     0001.9759.D62E

             This bridge is the root

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    33323  (priority 32768 sys-id-ext 555)

             Address     0001.9759.D62E

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/1            Desg FWD 19        128.1    P2p

To remedy this we will tell the L3 switch to be the root bridge for the Vlan 555.

L3SW1(config)#spanning-tree vlan 500 root primary 

With this in hand we can see after a couple of moments and, or in some simulation cases reloading the L2 switch , the root bridge is the L3 switch as supposed to.

L2SW2#sh spanning-tree vlan 555

VLAN0555

  Spanning tree enabled protocol rstp

  Root ID    Priority    25131

             Address     0009.7C51.A730

             Cost        19

             Port        1(FastEthernet0/1)

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    33323  (priority 32768 sys-id-ext 555)

             Address     0001.9759.D62E

             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  20

Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/1            Root FWD 19        128.1    P2p

For the final test we will ping the PBX server from the Site 2 from a PC workstation allocated in Site 1.

From the current output we can see that the ping was successful. After doing a traceroute we can see that the PC as the first hop is using the DG of the VLAN202 that it resides on. The second hop is the MGMT vlan IP address of the L3 switch in the Site 2 , that knows how to get to the DG of the Data VLAN in the Site 2. With this seen we can comply that everything is working fine.

Now what is missing???

This scenario has many single point of failures. First thing that comes on my mind is another two core switches with the HSRP technology for redudancy. 

Fell free to comment on any more features you would add.

Thanks.

BGP Regular Expressions

Regular expression table

Regular expressions are strings of special characters that can be used to search and find character patterns. Within the scope of BGP in Cisco IOS regular expressions can be used in show commands and AS-Path access-lists to match BGP prefixes based on the information contained in their AS-Path.

Term	Description
values	A single or series of character sequences within double-quotes ( " ), e.g. "108" for a single character sequence or "108 110 120" for a series of charater sequences.
Ranges	A sequence of characters within square brackets [1-4] or [1234]
.	Matches any single character.
*	Matches 0 or more sequences of the pattern
^	Matches the beginning of an input string
$	Matches the end of an input string
\character	Matches the character.
_	Matches a comma, left brace, right brace, the beginning of an input string, the end of an input string, or a space
+	Matches 1 or more sequences of a character

You can match many criteria Autonomous systems using the show ip bgp regexp. If you would like to practice via the command line and have no router access you can use one of the BGP looking glass servers.

Have fun with online full BGP table http://www.lookinglass.org/

Introduction to IPV6

IPV6 addresses 

IP protocol is the most widely used protocol in the networking world. All equipment manufacturers are implementing this standard in their router operating systems. Because every device on the internet has to be assigned an IP addres and exhaustion of widely used IPV4 standard addresses many providers and enterprises are planning and migrating to IPV6 address space.

The main significant change in the IPV6 framework is that instead of 32 bit space IPV6 uses 128 bit address space architecture. As with this information ipv6 address consists of 16 parts of eight bit sections. The address consists of global routing prefix, subnet identification and the interface identification. For an example IPV6 address looks like this: 2002:0000:4436:e378:8000:63bf:3fff:fdd2.
One of the slight differences from the packet header perspective is the IPV6 simplfied header. Creating this header design the router has faster response as it has less fields to go trough.

Important differences we can see that the new simplified IPV6 header does not use the checksum field. Also the Time to Live is replaced with the Hop Limit field.  IPv6 hosts are required to determine the optimal Path MTU before sending packets; however, it is guaranteed that any IPv6 packet smaller than or equal to 1280 bytes must be deliverable without the need to use IPv6 fragmentation.

The IPV6 address is still using some architecture like the IPV4.

2002:0000:4436:e378:8000:63bf:3fff:fdd2

The blue text presents the network part of the ipv6 and the other one is the interface identifier. Under IPv4 we have the old familiar unicast, broadcast and multicast addresses. In IPv6 we have unicast, multicast and anycast. With IPv6 the broadcast addresses are not used anymore, because they are replaced with multicast addressing.

IPv6 address 

We can group the ipv6 addresses in several scopes and uses.

Global Addresses - Unique, global addresses used on the Internet. They use the following prefix 2000::/3.

Link Local Addresses - Used to communicate with hosts on the same physical or logical network. These addresses start with FE80::/10

Site Local Address - The equivalent of RFC1918 (private addresses) but they are being deprecated. They start with FEC0::/10 prefix.

Multicast Address - Multicast replaces broadcast (along with unicast). The addresses use the following prefix: FF00::/8.


The IPV6 address of 2001:0DB8:C003:0001:0000:0000:0000:F00D can be represented in shorter format by removing leading zeros: 2001:DB8:C003:1:0:0:0:F00D

Further reduction by removing consecutive fields of zeros using the double-colon :: option. Note the double-colon can be used only once 2001:DB8:C003:1::F00D

IPv6 host addresses can be assigned in multiple ways:

• Static configuration
• Stateless autoconfiguration
• DHCPv6

When IPv6 is used over Ethernet networks, the Ethernet MAC address can be used to generate the 64-bit interface ID for the host. This is called the EUI-64 address. Since MAC addresses use 48 bits, additional bits must be inserted to fill the 64 bits required.

A lot of useful information can be found on the Cisco site.
http://www.cisco.com/web/solutions/trends/ipv6/index.html