Thursday, December 31, 2009

The Purpose of the OSI model

One of the very first concept I ever learnt in networking indeed the very first word I learnt to do with networking was the word “protocol”, the second word was “stack”, these two words put together became the foundation of everything else I would ever learn in networking, so what on earth is a “Protocol stack”.

In the beginning, no not the beginning of the universe but in the beginning of the whole networking or computing universe there where many different makers of systems all with their own ways of taking data produced by the users and conveyed from one machine to another across whatever physical or ethereal medium they choose. This all worked fine until users wanted to move data between machines from various makers. This sort of did not work too well, the first hurdle they faced was will these machines talk to one another?, will the signals from one machine e interpreted correctly, the chances were slim as system designers had decided that created proprietary systems was the best way to ensure that they lock users and customers in and increase market share.
The last days of proprietary communications protocols was nigh with the development of the ARPANET (Advanced Research Projects Agency Network) which was the world’s first operational packet switching network, and the predecessor of the global Internet.
The purpose of the ARPANET was to connect geographically disparate systems across either a university campus or across continents and allow them to send and receive data, for them to do so they need to speak the same language they need to operate the same communications protocol stack
One of the first communications protocols was Network Control Protocol (NCP) which provided the network layer functions running on an ARPANET computer, this protocol was replaced in 1983 with the protocol that we are all familiar with which is TCP/IP.
But this still does not explain what the OSI model is, so lets get on with it.
The OSI model was created by the ISO (International Standards Institute) which was sponsored by governments and the industry to create a common set of standards to provide interoperability between every systems vendor.
The OSI model was slow in development and by the time the final draft came into being the TCP/IP model had gained huge prominence on the ARPANET and other fledgling networks, to have replaced all the systems using TCP/IP with the OSI model which is more complex would have cost system users money even though the US government had also promoted it’s use.
The OSI model is now used as a teaching tool to explain the processes which occur as data flows from the wire to the user where the data as it flows from the wire/air as electrical/light/radio activity to the user it passes through 7 different layers or steps.
Why is the OSI model or even the TCP/IP model broken up into layers as opposed to having simple just one process?, the reasons are straight forward.
First and foremost it makes the teaching of networking easier, make fault finding much more efficient, makes the addition or removal of functions straight forward.
The OSI model is built using seven layers, counting from the bottom to the top, the first layer is called the Physical Layer or (L_1), this layer is responsible for connecting the host to the network and determining Functional, Procedural, Electrical and Mechanical aspects of the interface.
The layer above the Physical layer is called the Data Link Layer (L_2), this layer is responsible for how the host accesses the physical medium, error detection, hardware addressing, flow control, and identifying upper layer protocols.
Above the Data link layer we find the Network Layer (L_3), this layer is responsible for logical host addressing, Routed protocols and routing Protocols and identifying upper layer protocols.
The Transport layer (L_4) follows, this layer is one of the most interesting of all, as it provides reliable and unreliable transmission of data, segmentation. Sequencing of data, flow control using windowing, error correction.
The Session layer (L_5) which sits above the transport layer is responsible for establishing, maintaining and terminating session between end-user applications. Sessions between end-user applications are maintained using requests and responses, if a connection is lost between two applications the session layer will attempt to recover the connection by placing regular check points in the data flow and recovering the failed connection to the previous check point.
The Presentation layer (L_6) is responsible for formatting the user data from the layer above, an example of presenting the user data is ASCII or EBCDIC, encryption and compression is also performed here.
The top layer is the Application layer (L_7) is used by network applications. This layer provides services to programs that reside on your P.C such as HTTP provides a service to your browser
The description of each of the layers is a simple over view and we are going to cover all 7 layers in greater detail in other articles. But the point is that each layer has specific roles to perform as data passes up from the physical all the way to the application layer, this makes explaining each layer easier.
Each layer works independently from the layer above or below, let’s take a layer and call it L_N.
L_N receives user data from the layer above L_N+1 and acts upon it and then passes the data down to the layer below L_N-1, each layer adds their own information to the data they receive from L_N+1 and they subtracts their reciprocal layers data that was added by the sending host when they receive the data from below L_N-1.
By making each layer independent of other layers makes it easier for any procedure carried out at any layer to be changed without affecting any of the other layers.
Fault finding is also made easier by having a layered model, if I need to diagnose a problem with the logical addressing I just need to concentrate my efforts on L_3, if I have issues with connectivity I only need to fix L_1 without affecting any of the other layers. Having a layered model makes it easy to change, fix and modify any particular protocol or process without having to understand the inner workings of any of the other layers

Tuesday, December 29, 2009

Router ACL on Cisco DMZ SQL (Cisco Router DMZ)

Cisco Router DMZ
Linksys by Cisco WRT160N-RM Refurbished Wireless-N Router 
I did say before I would most likely come back to DMZ at a later date and I have, but first we will need to clear up some terms so that we don't get confused, first the naming for this blog I'm going to call the interfaces as follows public, private and DMZ this should keep things nice and clear also with the source and destination. The source is the IP and port that the traffic is coming from and the destination is well you guessed it.
Cisco Routers for the Desperate: Router and Switch Management, the Easy Way
Linksys by Cisco WRT54GL Wireless-G Broadband Router (Compatible with Linux)
Part one in bound traffic
in this example I have an private range of 192.168.32.x and a DMZ range of 192.168.30.x

now because the ranges of 192.168.x.x and others like 10.x.x.x and 172.16.x.x are well known to hackers and other spy programmes the first thing we are going to do is stop spoof packets entering the network

access-list 100 deny ip 192.168.30.0 0.0.0.255 any
access-list 100 deny ip 192.168.32.0 0.0.0.255 any
access-list 100 permit ip any any

this access list is applied to my public interface in this case serial0/0

interface serial0/0
access-group 100 in

notice the word in is used if i had use out I would have blocked all traffic with this ip leaving my network but as I've changed to in i am blocking all traffic with these ip entering my network.

now I'm going to create another access-list to allow only the DMZ traffic on the DMZ interface

access-list 101 permit ip 192.168.30.0 0.0.0.255 any

and apply it to my DMZ interface in this case ethernet0/0

interface ethernet0/0
access-group 101 in

now I'm going to the private network and stop all but my internal range from being able to use this interface.

access-list 102 permit ip 192.168.32.0 0.0.0.255 any

and apply this to my private interface that in this case is ethernet0/1

interface ethernet0/1
access-group 102 in

OK now we have the first part done we have setup what traffic can enter our network on each interface but we haven't yet said what can leave it, at the moment any traffic an leave our network as long as it has the right ip range for that interface, so it time to create three more access lists one for each interface with the out command, first up is the public interface.

just before we begin on creating these list we need to look at what we need to allow and where from... we don't want to allow everything as this would make the list useless and at the same time we need to allow some traffic so make a quick list of what services need access to the outside world.

in my case I have an email, DNS, web and Proxy server on the DMZ these are access from both the public and private networks.

Part Two out bound traffic
first lets say we want to be ping the outside world and the DMZ from the private LAN so we will need ICMP, I'm also going to need my DNS server to be able to send a receive DNS zone updates and requests.

now I've put my server on the following IP this will make it easier when you read the access lists to see where the traffic is going.

eMail 192.168.30.4
DNS 192.168.30.3
Web 192.168.30.2
Proxy 192.168.30.1

I'm also going to apply the out going access list on the interfaces like this
list 103 Public interface
list 104 DMZ interface
list 105 Private interface

First we'll build the ACL for the public interface this should allow all you out bound connection to go to the internet from your DMZ


access-list 103 permit tcp any host 192.168.30.0 0.0.0.255 established
access-list 103 permit udp host 192.168.30.3 eq domain any eq domain
access-list 103 permit udp host 192.168.30.3 gt 1023 any eq domain
access-list 103 permit udp host 192.168.30.3 eq domain any gt 1023
access-list 103 permit tcp host 192.168.30.3 any eq domain
access-list 103 permit icmp 192.168.30.0 0.0.0.255 any echo-reply
access-list 103 permit tcp host 192.168.30.1 any
access-list 103 permit tcp host 192.168.30.4 any eq smtp


After that we have the all important DMZ this has to allow traffic back to the internet and to the LAN but only what is needed

access-list 104 permit tcp any host 192.168.30.0 0.0.0.255 established
access-list 104 permit udp any eq domain host 192.168.30.3 eq domain
access-list 104 permit udp any eq domain host 192.168.30.3 gt 1023
access-list 104 permit udp any gt 1023 host 192.168.30.3 eq domain
access-list 104 permit icmp any 192.168.30.0 0.0.0.255 echo
access-list 104 permit tcp any host 192.168.30.2 eq www
access-list 104 permit tcp 192.168.32.0 0.0.0.255 host 192.168.30.1 range ftp-data ftp
access-list 104 permit tcp 192.168.32.0 0.0.0.255 host 192.168.30.1 eq telnet
access-list 104 permit tcp 192.168.32.0 0.0.0.255 host 192.168.30.1 eq 8080
access-list 104 permit tcp any eq ftp-data host 192.168.30.1 gt 1023
access-list 104 permit tcp any host 192.168.30.4 eq smtp
access-list 104 permit tcp host 172.16.1.2 host 192.168.30.3 eq domain
access-list 104 permit tcp host 172.16.1.4 host 192.168.30.3 eq domain

And finally we configure the private interface to let traffic on the DMZ into the LAN reply to request from the LAN
access-list 105 permit tcp 192.168.30.0 0.0.0.255 192.168.32.0 0.0.0.255 established
access-list 105 permit icmp 192.168.30.0 0.0.0.255 192.168.32.0 0.0.0.255 echo-reply
access-list 105 permit tcp host 192.168.30.1 eq ftp-data 192.168.32.0 0.0.0.255 gt 1023
access-list 105 permit tcp host 192.168.30.4 192.168.32.0 0.0.0.255 eq smtp

now that all the access list have been written we need to apply them to the interface like so.
interface serial0/0
access-group 100 in
access-group 103 out

interface ethernet0/0
access-group 101 in
access-group 104 out

interface ethernet0/1
access-group 102 in
access-group 105 out 

PIX/ASA Site-to-Site (L2L) VPN with Duplicate/Same Subnets - Howto

PIX/ASA Site-to-Site (L2L) VPN with Duplicate/Same Subnets - Howto

PIX/ASA Site-to-Site (L2L) VPN with Duplicate/Same Subnets is the how to for this lab Image:

PIX/ASA Site-to-Site (L2L) VPN with Duplicate/Same Subnets Lab is Start follow the following Steps:

Cisco ASA, PIX, and FWSM Firewall Handbook (2nd Edition) 

Cisco ASA, PIX, and FWSM Firewall Handbook (2nd Edition)Basic Setup:
Firewall 1
!
interface Ethernet0
nameif outside
security-level 0
ip address 142.100.123.1 255.255.255.0
!
interface Ethernet1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
!For Testing Allow pings/ICMP through
access-list WAN_IN extended permit icmp any any
access-group WAN_IN in interface outside
!
!NAT
global (outside) 2 interface
nat (inside) 2 0.0.0.0 0.0.0.0
!
!Default Route
route outside 0.0.0.0 0.0.0.0 142.100.123.99
!
Firewall 2
!
interface Ethernet0
nameif outside
security-level 0
ip address 208.69.34.2 255.255.255.0
!
interface Ethernet1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
access-list WAN_IN extended permit icmp any any
access-group WAN_IN in interface outside
!
global (outside) 2 interface
nat (inside) 2 0.0.0.0 0.0.0.0
!
route outside 0.0.0.0 0.0.0.0 208.69.34.99 1
!

Now the interesting part, we want a user at site 1 to ping 192.168.102.100 and it reach 192.168.1.100 (at site 2) and a user at site 2 to ping 192.168.101.100 and it reach 192.168.1.100 (at site1).

Here is how: PIX/ASA Site-to-Site (L2L) VPN with Duplicate/Same Subnets

Firewall 1
!ACL defining traffic for static nat
access-list site2 extended permit ip 192.168.1.0 255.255.255.0 192.168.102.0 255.255.255.0
!ACL for the IPSec Tunnel
access-list IPSEC-TUN extended permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0
! Static NAT
static (inside,outside) 192.168.101.0 access-list site2

Now the tunnel itselfCisco ASA, PIX, and FWSM Firewall Handbook (2nd Edition)

crypto ipsec transform-set FW1-TRANSFORM esp-3des esp-md5-hmac
crypto map FW1 10 match address IPSEC-TUN
crypto map FW1 10 set peer 208.69.34.2
crypto map FW1 10 set transform-set FW1-TRANSFORM
crypto map FW1 interface outside
crypto isakmp enable outside
crypto isakmp policy 100
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
tunnel-group 208.69.34.2 type ipsec-l2l
tunnel-group 208.69.34.2 ipsec-attributes
pre-shared-key letmein
 Firewall 2
access-list site1 extended permit ip 192.168.1.0 255.255.255.0 192.168.101.0 255.255.255.0
access-list IPSEC-TUN extended permit ip 192.168.102.0 255.255.255.0 192.168.101.0 255.255.255.0
!
static (inside,outside) 192.168.102.0 access-list site1
!
crypto ipsec transform-set FW2-TRANSFORM esp-3des esp-md5-hmac
crypto map FW2 10 match address IPSEC-TUN
crypto map FW2 10 set peer 142.100.123.1
crypto map FW2 10 set transform-set FW2-TRANSFORM
crypto map FW2 interface outside
crypto isakmp enable outside
crypto isakmp policy 100
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
!
tunnel-group 142.100.123.1 type ipsec-l2l
tunnel-group 142.100.123.1 ipsec-attributes
pre-shared-key letmein
!

All done!  

Cisco ASA, PIX, and FWSM Firewall Handbook (2nd Edition)

Dial Peer Configuration on Voice Gateway Routers

Dial Peer Configuration on Voice Gateway Routers
Cisco VG204 Analog Voice Gateway - VoIP phone adapter - Ethernet, Fast Ethernet - external 
Cisco VG204 Analog Voice Gateway - VoIP phone adapter - Ethernet, Fast Ethernet - external
Common Practices
Voice Ports
Assigning Voice Ports
Session Targets
Destination Patterns
Configuring Destination Patterns
Digit Manipulation
Data Dial Peers
Configuring Data Dial Peers
Configuring a Search for Dial Peers by Type
Inbound and Outbound Dial Peers
Matching Inbound Dial Peers
Variable-Length Matching
Configuring the incoming called-number Command
answer-address Command
Configuring the destination-pattern Command
Configuring the port Command
Matching Outbound Dial Peers
Using Default Routes
Additional Features
One Stage and Two Stage Dialing
Direct Inward Dialing
Hunt Groups
Configuring Dial Peer Hunting Options
Modem Pass Through
Configuring Modem Pass Through Capability for Individual Dial Peers
Dual Tone Multifrequency Relay
Configuring DTMF Relay and Payload Type
Connection PLAR
Configuring Connection PLAR
Connection PLAR Design Considerations
Connection Trunk
Configuring Connection Trunk
Class of Restrictions
Configuring Classes of Restrictions
Verifying Classes of Restrictions
Configuring an iLBC Codec
Configuring an iLBC Codec on a Dial Peer
Configuring an iLBC Codec in the Voice Class
Where to Go for Dial Peer Troubleshooting Information

Cisco ASA 5500 Series Content Security Edition for the Enterprise

Cisco ASA 5500 Series Content Security Edition for the Enterprise
Asa 5510 Security Appl CSC10Asa 5510 Security Appl CSC10Viruses and other malicious code can overwhelm your IT resources disrupting business operations and impacting business transactions. The onslaught of spyware and unwanted Internet content can seriously impact employee productivity and expose individuals to identity theft. Providing comprehensive malware protection and content control, the Cisco ASA 5500 Series Content Security Edition allows enterprises to make full use of the Internet without the risk and costs associated with infections and threats impacting client systems. Combining enterprise-grade firewall and high-quality malware protection, the Cisco ASA 5500 Series Content Security Edition delivers a powerful all-in-one solution that provides strong protection and control for business network communications, stops network threats including viruses, worms, spyware, spam and phishing, and controls unwanted mail and Web content while reducing the operational costs and complexity of deploying and managing multiple point solutions.Asa 5510 Security Appl CSC10

70 291 15 Min - Download from rapidshare.com

70 291 15 Min - Download from rapidshare.com


The PrepLogic 15-Minute Complete IT Study Guide builds a solid focus, while revisiting key examination topics. Whether you are just starting to study, cramming at the last second, or simply looking to refresh, this free download could prove to be a lifesaver! It is presented in an easy to read, easy to navigate PDF. Print it out, mark it up, do whatever it takes to vitalize your confidence for the CCNA, A+, Cisco, MCSE, or other IT certification exam.

Clear and Concise Directives
"Must Know" Terms & Subjects
Essential Procedures
Overlooked Topics
No Fluff, Easy Navigation
and Much More…

Windows Vista (70-620)

http://rapidshare.com/files/72794522/70620_15min_guide.zip

Basic Installation Windows Vista (70-622)

http://rapidshare.com/files/103715968/Prep70-622.rar

Install and Upgrade Windows Vista (70-623)

http://rapidshare.com/files/103715969/Prep_70-623.rar

70-270

http://rapidshare.com/files/49343724/70-270_15_Min.rar

70-290

http://rapidshare.com/files/49343725/70-290_15_Min.rar

70-291

http://rapidshare.com/files/49343726/70-291_15_Min.rar

70-293

http://rapidshare.com/files/49343727/70-293_15_Min.rar

A+2006

http://rapidshare.com/files/49343728/A_Plus_2006.rar

Network +

http://rapidshare.com/files/49343731/Network__.rar

Security +

http://rapidshare.com/files/49343733/Security_Plus.rar

CCNA

http://rapidshare.com/files/49343729/CCNA_15_Min.rar

CCNA (640-802)

http://rapidshare.com/files/72794290/640-802_15_Min.rar

PMP

http://rapidshare.com/files/49343732/PMP_15_Min.rar

CEH

http://rapidshare.com/files/49343730/CEH_15_Min.rar

SSCP

http://rapidshare.com/files/49344116/SSCP.rar

Password: electronicsouls

The PrepLogic 15-Minute Complete IT Study Guide builds a solid focus, while revisiting key examination topics. Whether you are just starting to study, cramming at the last second, or simply looking to refresh, this free download could prove to be a lifesaver! It is presented in an easy to read, easy to navigate PDF. Print it out, mark it up, do whatever it takes to vitalize your confidence for the CCNA, A+, Cisco, MCSE, or other IT certification exam.

Clear and Concise Directives
"Must Know" Terms & Subjects
Essential Procedures
Overlooked Topics
No Fluff, Easy Navigation
and Much More…

Windows Vista (70-620)

http://rapidshare.com/files/72794522/70620_15min_guide.zip

Basic Installation Windows Vista (70-622)

http://rapidshare.com/files/103715968/Prep70-622.rar

Install and Upgrade Windows Vista (70-623)

http://rapidshare.com/files/103715969/Prep_70-623.rar

70-270

http://rapidshare.com/files/49343724/70-270_15_Min.rar

70-290

http://rapidshare.com/files/49343725/70-290_15_Min.rar

70-291

http://rapidshare.com/files/49343726/70-291_15_Min.rar

70-293

http://rapidshare.com/files/49343727/70-293_15_Min.rar

A+2006

http://rapidshare.com/files/49343728/A_Plus_2006.rar

Network +

http://rapidshare.com/files/49343731/Network__.rar

Security +

http://rapidshare.com/files/49343733/Security_Plus.rar

CCNA

http://rapidshare.com/files/49343729/CCNA_15_Min.rar

CCNA (640-802)

http://rapidshare.com/files/72794290/640-802_15_Min.rar

PMP

http://rapidshare.com/files/49343732/PMP_15_Min.rar

CEH

http://rapidshare.com/files/49343730/CEH_15_Min.rar

SSCP

http://rapidshare.com/files/49344116/SSCP.rar

Password: electronicsouls

The PrepLogic 15-Minute Complete IT Study Guide builds a solid focus, while revisiting key examination topics. Whether you are just starting to study, cramming at the last second, or simply looking to refresh, this free download could prove to be a lifesaver! It is presented in an easy to read, easy to navigate PDF. Print it out, mark it up, do whatever it takes to vitalize your confidence for the CCNA, A+, Cisco, MCSE, or other IT certification exam.

Clear and Concise Directives
"Must Know" Terms & Subjects
Essential Procedures
Overlooked Topics
No Fluff, Easy Navigation
and Much More…

Windows Vista (70-620)

http://rapidshare.com/files/72794522/70620_15min_guide.zip

Basic Installation Windows Vista (70-622)

http://rapidshare.com/files/103715968/Prep70-622.rar

Install and Upgrade Windows Vista (70-623)

http://rapidshare.com/files/103715969/Prep_70-623.rar

70-270

http://rapidshare.com/files/49343724/70-270_15_Min.rar

70-290

http://rapidshare.com/files/49343725/70-290_15_Min.rar

70-291

http://rapidshare.com/files/49343726/70-291_15_Min.rar

70-293

http://rapidshare.com/files/49343727/70-293_15_Min.rar

A+2006

http://rapidshare.com/files/49343728/A_Plus_2006.rar

Network +

http://rapidshare.com/files/49343731/Network__.rar

Security +

http://rapidshare.com/files/49343733/Security_Plus.rar

CCNA

http://rapidshare.com/files/49343729/CCNA_15_Min.rar

CCNA (640-802)

http://rapidshare.com/files/72794290/640-802_15_Min.rar

PMP

http://rapidshare.com/files/49343732/PMP_15_Min.rar

CEH

http://rapidshare.com/files/49343730/CEH_15_Min.rar

SSCP

http://rapidshare.com/files/49344116/SSCP.rar

Password: electronicsouls

IOS Packet Capture and Auto Upgrade

IOS Packet Capture and Auto Upgrade

IOS Packet Capture

Finally there is a feature that was missing from IOS in the past. This is the ability to easily capture packets travelling through the router, and export the captured data to PCAP format so that you can view it with third party tools (like Wireshark). The packets can also be viewed locally on the router. The configuration example below shows how to enable packet capture (supported in IOS version 12.4(20)T):

Cisco-Router# monitor capture buffer mycapturedata size 128 max-size 128 circular
Cisco-Router# monitor capture point ip cef capturepoint1fastEthernet 1/1 both
Cisco-Router# monitor cap point associate capturepoint1 mycapturedata

The configuration above first creates a capture circular buffer (mycapturedata) and a capture interface point (capturepoint1) on physical interface FastEthernet 1/1. Then you need to associate the capture point and the capture buffer.

Now, in order to view or export the captured data use the following commands:

Cisco-Router# show monitor capture buffer mycapturedata dump
Cisco-Router# monitor capture buffer mycapturedata export [location]

IOS Auto Upgrade

From IOS version 12.4(15)T, there is a new feature for automaticaly upgrading your Cisco IOS images either directly from Cisco (IDA Server – Intelligent Download Application) or from a local TFTP/FTP server, as shown below:

cisco router auto upgrade feature

The new auto upgrade feature provides also a “warm upgrade” option which decompresses the new image and transfers control to it using the reload warm command. To set up auto upgrade, use the following commands:

Router# configure terminal
Router(config)# autoupgrade disk-cleanup crashinfo
Router(config)# autoupgrade ida url [enter the URL of the IDA Server]
Router(config)# autoupgrade status [email address] [smtp-server]

! Now issue the interactive mode command to step you through the upgrade process
Router# upgrade automatic


Configuring a Cisco Catalyst Switch SPAN mirroring port

Configuring a Cisco Catalyst Switch SPAN mirroring port

Configuring a Cisco Catalyst Switch SPAN mirroring port for Network Engineers, the ability to mirror switch traffic and send it to a sniffer for analysis is an essential troubleshooting technique. All Cisco Catalyst switches support the Switched Port Analyzer (SPAN) feature which copies traffic from specified switch source ports or VLANs and mirrors this traffic to a specified destination switch port (SPAN port). Then, you can connect your PC having a sniffer tool (like WireShark) on the destination SPAN port to capture all mirrored traffic. The diagram below shows this:

To utilize the switch SPAN mirroring feature configure the following on the catalyst switch:

Configuration Example – Monitoring an entire VLAN traffic
c3750(config)#monitor session 1 source vlan 5
c3750(config)#monitor session 1 destination interface fastethernet 0/3

The configuration above will capture all traffic of VLAN 5 and send it to SPAN port fastethernet 0/3.

Configuration Example – Monitoring traffic from a specific interface
c3750(config)#monitor session 1 source interface fastethernet 0/1
c3750(config)#monitor session 1 destination interface fastethernet 0/2

The configuration above will capture all traffic from interface 0/1 and send it to SPAN port fastethernet 0/2.

Use the command show monitor session 1 to verify your configuration.


How to configure a Cisco Layer 3 switch-InterVLAN Routing

How to configure a Cisco Layer 3 switch-InterVLAN Routing

Cisco Catalysts switches equipped with the Enhanced Multilayer Image (EMI) can work as Layer 3 devices with full routing capabilities. Example switch models that support layer 3 routing are the 3550, 3750, 3560 etc.

On a Layer3-capable switch, the port interfaces work as Layer 2 access ports by default, but you can also configure them as “Routed Ports” which act as normal router interfaces. That is, you can assign an IP address directly on the routed port. Moreover, you can configure also a Switch Vlan Interface (SVI) with the “interface vlan” command which acts as a virtual layer 3 interface on the Layer3 switch.

On this post I will describe a scenario with a Layer3 switch acting as “Inter Vlan Routing” device together with two Layer2 switches acting as closet access switches. See the diagram below:

Interface Fa0/48 of the Layer3 switch is configured as a Routed Port with IP address 10.0.0.1. Two Vlans are configured on the L3 switch, Vlan10 and Vlan20. For Vlan10 we will create an SVI with IP address 10.10.10.10 and for Vlan20 an SVI with IP address 10.20.20.20. These two IP addresses will be the default gateway addresses for hosts belonging to Vlan10 and Vlan20 on the Layer2 switches respectively. That is, hosts connected on Vlan10 on the closet L2 switches will have as default gateway the IP address 10.10.10.10. Similarly, hosts connected on Vlan20 on the closet switches will have address 10.20.20.20 as their default gateway. Traffic between Vlan10 and Vlan20 will be routed by the L3 Switch (InterVlan Routing). Also, all interfaces connecting the three switches must be configured as Trunk Ports in order to allow Vlan10 and Vlan20 tagged frames to pass between switches. Let’s see a configuration snapshot for all switches below:

Cisco L2 Switch (same configuration for both switches)

! Create VLANs 10 and 20 in the switch database
Layer2-Switch# configure terminal
Layer2-Switch(config)# vlan 10
Layer2-Switch(config-vlan)# end

Layer2-Switch(config)# vlan 20
Layer2-Switch(config-vlan)# end

! Assign Port Fe0/1 in VLAN 10
Layer2-Switch(config)# interface fastethernet0/1
Layer2-Switch(config-if)# switchport mode access
Layer2-Switch(config-if)# switchport access vlan 10
Layer2-Switch(config-if)# end

! Assign Port Fe0/2 in VLAN 20
Layer2-Switch(config)# interface fastethernet0/2
Layer2-Switch(config-if)# switchport mode access
Layer2-Switch(config-if)# switchport access vlan 20
Layer2-Switch(config-if)# end

! Create Trunk Port Fe0/24
Layer2-Switch(config)# interface fastethernet0/24
Layer2-Switch(config-if)# switchport mode trunk
Layer2-Switch(config-if)# switchport trunk encapsulation dot1q
Layer2-Switch(config-if)# end

Cisco Layer 3 Switch

! Enable Layer 3 routing
Layer3-Switch(config) # ip routing

! Create VLANs 10 and 20 in the switch database
Layer3-Switch# configure terminal
Layer3-Switch(config)# vlan 10
Layer3-Switch(config-vlan)# end

Layer3-Switch(config)# vlan 20
Layer3-Switch(config-vlan)# end

! Configure a Routed Port for connecting to the ASA firewall
Layer3-Switch(config)# interface FastEthernet0/48
Layer3-Switch(config-if)# description To Internet Firewall
Layer3-Switch(config-if)# no switchport
Layer3-Switch(config-if)# ip address 10.0.0.1 255.255.255.252

! Create Trunk Ports Fe0/47 Fe0/46
Layer3-Switch(config)# interface fastethernet0/47
Layer3-Switch(config-if)# switchport mode trunk
Layer3-Switch(config-if)# switchport trunk encapsulation dot1q
Layer3-Switch(config-if)# end

Layer3-Switch(config)# interface fastethernet0/46
Layer3-Switch(config-if)# switchport mode trunk
Layer3-Switch(config-if)# switchport trunk encapsulation dot1q
Layer3-Switch(config-if)# end

! Configure Switch Vlan Interfaces (SVI)
Layer3-Switch(config)# interface vlan10
Layer3-Switch(config-if)# ip address 10.10.10.10 255.255.255.0
Layer3-Switch(config-if)# no shut

Layer3-Switch(config)# interface vlan20
Layer3-Switch(config-if)# ip address 10.20.20.20 255.255.255.0
Layer3-Switch(config-if)# no shut

! Configure default route towards ASA firewall
Layer3-Switch(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.2


Saturday, December 26, 2009

Configuring BGP: Basic BGP Configuration Tasks

Table of Contents

Configuring BGP

Cisco's BGP Implementation
    How BGP Selects Paths
      BGP Multipath Support
Basic BGP Configuration Tasks
Advanced BGP Configuration Tasks
Enable BGP Routing
Configure BGP Neighbors
Configure BGP Soft Reconfiguration
Reset BGP Connections
Configure BGP Interactions with IGPs
Configure BGP Administrative Weights
Configure BGP Route Filtering by Neighbor
Configure BGP Path Filtering by Neighbor
Disable Next-Hop Processing on BGP Updates
Configure the BGP Version
Set the Network Weight
Configure the Multi Exit Discriminator Metric
Advanced BGP Configuration Tasks
Use Route Maps to Modify Updates
Reset EBGP Connections Immediately upon Link Failure
Configure Aggregate Addresses
Disable Automatic Summarization of Network Numbers
Configure BGP Community Filtering
Configure a Routing Domain Confederation
Configure a Route Reflector
Configure Neighbor Options
Configure BGP Peer Groups
    Create the Peer Group
    Assign Options to the Peer Group
    Make Neighbors Members of the Peer Group
Indicate Backdoor Routes
Modify Parameters While Updating the IP Routing Table
Set Administrative Distance
Adjust BGP Timers
Change the Local Preference Value
Redistribute Network 0.0.0.0
Select Path Based on MEDs from Other Autonomous Systems
Configure Route Dampening
    Minimize Flapping
    Understand Route Dampening Terms
    Enable Route Dampening
    Monitor and Maintain BGP Route Dampening
Monitor and Maintain BGP
    Clear Caches, Tables, and Databases
    Display System and Network Statistics
    Log Changes in Neighbor Status
BGP Configuration Examples
BGP Route Map Examples
BGP Neighbor Configuration Examples
BGP Synchronization Example
BGP Path Filtering by Neighbor Example
BGP Aggregate Route Examples
BGP Confederation Example
TCP MD5 Authentication for BGP Example
BGP Peer Group Examples
    IBGP Peer Group Example
    EBGP Peer Group Example
BGP Community with Route Maps Examples

Read rest of story

Cisco UCM SIP Profile Configuration

Cisco UCM SIP Profile Configuration

Cisco UCM SIP Profile Configuration is a SIP profile comprises the set of SIP attributes that are associated with SIP trunks and SIP endpoints. SIP profiles include information such as name, description, timing, retry, call pickup URI, and so on. The profiles contain some standard entries that cannot be deleted or changed.

SIP Profile Information

Name

Enter a name to identify the SIP profile; for example, SIP_7962. The value can include 1 to 50 characters, including alphanumeric characters, dot, dash, and underscores.

Description

This field identifies the purpose of the SIP profile; for example, SIP for 7965.

Default MTP Telephony Event Payload Type

This field specifies the default payload type for RFC2833 telephony event. See RFC 2833 for more information. In most cases, the default value specifies the appropriate payload type. Be sure that you have a firm understanding of this parameter before changing it, as changes could result in DTMF tones not being received or generated. The default value specifies 101 with range from 96 to 127.

The value of this parameter affects calls with the following conditions:

  • The call is an outgoing SIP call from Cisco Unified Communications Manager.
  • For the calling SIP trunk, the Media Termination Point Required check box is checked on the SIP Trunk Configuration window.

Resource Priority Namespace List

Select a configured Resource Priority Namespace Network Domain list from the drop-down menu. Configure the lists in the Resource Priority Namespace Network Domain menu that is accessed from the System menu.

Redirect by Application

Checking this check box and configuring this SIP Profile on the SIP trunk allows the Cisco Unified Communications Manager administrator to

  • Apply a specific calling search space to redirected contacts that are received in the 3xx response.
  • Apply digit analysis to the redirected contacts to make sure that the call gets routed correctly.
  • Prevent DOS attack by limiting the number of redirection (recursive redirection) that a service parameter can set.
  • Allow other features to be invoked while the redirection is taking place.

Getting redirected to a restricted phone number (such as an international number) means that handling redirection at the stack level will cause the call to be routed instead of being blocked. This represents the behavior that you will get if the Redirect by Application check box is unchecked.

Disable Early Media on 180

By default, Cisco Unified Communications Manager will signal the calling phone to play local ringback if SDP is not received in the 180 or 183 response. If SDP is included in the 180 or 183 response, instead of playing ringback locally, Cisco Unified Communications Manager will connect media, and the calling phone will play whatever the called device is sending (such as ringback or busy signal). If you do not receive ringback, the device to which you are connecting may be including SDP in the 180 response, but it is not sending any media before the 200OK response. In this case, check this check box to play local ringback on the calling phone and connect the media upon receipt of the 200OK response

Note Even though the phone that is receiving ringback is the calling phone, you need the configuration on the called device profile because it determines the behavior.

Outgoing T.38 INVITE Include Audio mline

The parameter allows the system to accept a signal from Microsoft Exchange that causes it to switch the call from audio to T.38 fax. To use this feature, you must also configure a SIP trunk with this SIP profile.

Note The parameter applies to SIP trunks only, not phones that are running SIP or other endpoints.

Parameters used in Phone

Timer Invite Expires (seconds)

This field specifies the time, in seconds, after which a SIP INVITE expires. The Expires header uses this value. Valid values include any positive number; 180 specifies the default.

Timer Register Delta (seconds)

Use this parameter in conjunction with the Timer Register Expires setting. The phone will reregister Timer Register Delta seconds before the registration period ends. The registration period gets determined by the value of the SIP Station Keepalive Interval service parameter. Valid values range from 32767 to 0. Default specifies 5.

Timer Register Expires (seconds)

This field specifies the value that the phone that is running SIP will send in the Expires header of the REGISTER message. Valid values include any positive number; however, 3600 (1 hour) specifies the default value. In the 200OK response to REGISTER, Cisco Unified Communications Manager will include an Expires header with the configured value of the SIP Station KeepAlive Interval service parameter. This value in the 200OK determines the time, in seconds, after which the registration expires. The phone will refresh the registration Timer Register Delta seconds before the end of this interval.

Timer T1 (msec)

This field specifies the lowest value, in milliseconds, of the retransmission timer for SIP messages. Valid values include any positive number. Default specifies 500.

Timer T2 (msec)

This field specifies the highest value, in milliseconds, of the retransmission timer for SIP messages. Valid values include any positive number. Default specifies 4000.

Retry INVITE

This field specifies the maximum number of times that an INVITE request will be retransmitted. Valid values include any positive number. Default specifies 6.

Retry Non-INVITE

This field specifies the maximum number of times that a SIP message other than an INVITE request will be retransmitted. Valid values include any positive number. Default specifies 10.

Start Media Port

This field designates the start real-time protocol (RTP) port for media. Media port ranges from 16384 to 32766. Default specifies 16384.

Stop Media Port

This field designates the stop real-time protocol (RTP) port for media. Media port ranges from 16384 to 32766. Default specifies 32766.

Call Pickup URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the call pickup feature.

Call Pickup Group Other URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the call pickup group other feature.

Call Pickup Group URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the call pickup group feature.

Meet Me Service URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the meet me conference feature.

User Info

This field configures the user= parameter in the REGISTER message.

Valid values follow:

  • none—No value gets inserted.
  • •phone—The value user=phone gets inserted in the To, From, and Contact Headers for REGISTER.
  • •ip—The value user=ip gets inserted in the To, From, and Contact Headers for REGISTER.

DTMF DB Level

This field specifies in-band DTMF digit tone level. Valid values follow:

  • 1 to 6 dB below nominal
  • 2 to 3 dB below nominal
  • 3 nominal
  • 4 to 3 dB above nominal
  • 5 to 6 dB above nominal

Call Hold Ring Back

If you have a call on hold and are talking on another call, when you hang up the call, this parameter causes the phone to ring to let you know that you still have another party on hold. Valid values follow:

  • Off permanently and cannot be turned on and off locally by using the user interface.
  • On permanently and cannot be turned on and off locally by using the user interface.

Anonymous Call Block

This field configures anonymous call block. Valid values follow:

  • Off—Disabled permanently and cannot be turned on and off locally by using the user interface.
  • On—Enabled permanently and cannot be turned on and off locally by using the user interface.

Caller ID Blocking

This field configures caller ID blocking. When blocking is enabled, the phone blocks its own number or e-mail address from phones that have caller identification enabled. Valid values follow:

  • Off—Disabled permanently and cannot be turned on and off locally by using the user interface.
  • On—Enabled permanently and cannot be turned on and off locally by using the user interface.

Do Not Disturb Control

This field sets the Do Not Disturb (DND) feature. Valid values follow:

  • User—The dndControl parameter for the phone should specify 0.
  • Admin—The dndControl parameter for the phone should specify 2.

Telnet Level for 7940 and 7960

Cisco Unified IP Phones 7940 and 7960 do not support ssh for login access or HTTP that is used to collect logs; however, these phones support Telnet, which lets the user control the phone, collect debugs, and look at configuration settings. This field controls the telnet_level configuration parameter with the following possible values:

  • Disabled (no access)
  • Limited (some access but cannot run privileged commands)
  • Enabled (full access)

Timer Keep Alive Expires (seconds)

Cisco Unified Communications Manager requires a keepalive mechanism to support redundancy. This field specifies the interval between keepalive messages that are sent to the backup Cisco Unified Communications Manager to ensure that it is available in the event that a failover is required.

Timer Subscribe Expires (seconds)

This field specifies the time, in seconds, after which a subscription expires. This value gets inserted into the Expires header field. Valid values include any positive number; however, 120 specifies the default value.

Timer Subscribe Delta (seconds)

Use this parameter in conjunction with the Timer Subscribe Expires setting. The phone will resubscribe Timer Subscribe Delta seconds before the subscription period ends, as governed by Timer Subscribe Expires. Valid values range from 3 to 15. Default specifies 5.

Maximum Redirections

Use this configuration variable to determine the maximum number of times that the phone will allow a call to be redirected before dropping the call. Default specifies 70 redirections.

Off Hook to First Digit Timer (microseconds)

This field specifies the time in microseconds that passes when the phone goes off hook and the first digit timer gets set. The value ranges from 0 - 15,000 microseconds. Default specifies 15,000 microseconds.

Call Forward URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the call forward feature.

Abbreviated Dial URI

This URI provides a unique address that the phone that is running SIP will send to Cisco Unified Communications Manager to invoke the abbreviated dial feature.

Speed dials that are not associated with a line key (abbreviated dial indices) will not download to the phone. The phone will use the feature indication mechanism (INVITE with Call-Info header) to indicate when an abbreviated dial number has been entered. The request URI will contain the abbreviated dial digits (for example, 14), and the Call-Info header will indicate the abbreviated dial feature. Cisco Unified Communications Manager will translate the abbreviated dial digits into the configured digit string and extend the call with that string. If no digit string has been configured for the abbreviated dial digits, a 404 Not Found response gets returned to the phone.

Conference Join Enabled

This check box determines whether the Cisco Unified IP Phones 7940 or 7960, when the conference initiator that is using that phone hangs up, should attempt to join the remaining conference attendees. Check the check box if you want to join the remaining conference attendees; leave it unchecked if you do not want to join the remaining conference attendees.

Note This check box applies to the Cisco Unified IP Phones 7941/61/70/71/11 when they are in SRST mode only.

RFC 2543 Hold

Check this check box to enable setting connection address to 0.0.0.0 per RFC2543 when call hold is signaled to Cisco Unified Communications Manager. This allows backward compatibility with endpoints that do not support RFC3264.

Semi Attended Transfer

This check box determines whether the Cisco Unified IP Phones 7940 and 7960 caller can transfer the second leg of an attended transfer while the call is ringing. Check the check box if you want semi-attended transfer enabled; leave it unchecked if you want semi-attended transfer disabled.

Note This check box applies to the Cisco Unified IP Phones 7941/61/70/71/11 when they are in SRST mode only.

Enable VAD

Check this check box if you want voice activation detection (VAD) enabled; leave it unchecked if you want VAD disabled. When VAD is enabled, no media gets transmitted when voice is detected.

Stutter Message Waiting

Check this check box if you want stutter dial tone when the phone goes off hook and a message is waiting; leave unchecked if you do not want a stutter dial tone when a message is waiting.

This setting supports Cisco Unified IP Phones 7960 and 7940 that run SIP.

Call Stats

Check this check box if you want RTP statistics in BYE requests and responses enabled; leave unchecked if you want RTP statistics in BYE requests and responses disabled.

If this check box is checked, the phone inserts the headers RTP-RxStat and RTP-TxStat as follows:

  • RTP-RxStat:Dur=a,Pkt=b,Oct=c,LatePkt=d,LostPkt=e,AvgJit=f
  • RTP-TxStat: Dur=g,Pkt=h,Oct=i

where:

  • Dur—Total number of seconds since the beginning of reception or transmission.
  • Pkt—Total number of RTP packets that are received or transmitted.
  • Oct—Total number of RTP payload octets that are received or transmitted (not including RTP header).
  • LatePkt—Total number of late RTP packets that are received.
  • LostPkt—Total number of lost RTP packets that are received (not including the late RTP packets).
  • AvgJit—Average jitter, which is an estimate of the statistical variance of the RTP packet interarrival time, measured in timestamp unit and calculated according to RFC 1889.
  • a, b, c, d, e, f, g, h, and i—Integers

Trunk Specific Configuration

Reroute Incoming Request to new Trunk based on

Cisco Unified Communications Manager only accepts calls from the SIP device whose IP address matches the destination address of the configured SIP trunk. In addition, the port on which the SIP message arrives must match the one that is configured on the SIP trunk. After Cisco Unified Communications Manager accepts the call, Cisco Unified Communications Manager uses the configuration for this setting to determine whether the call should get rerouted to another trunk.

From the drop-down list box, choose the method that Cisco Unified Communications Manager uses to identify the SIP trunk where the call gets rerouted:

  • Never—If the SIP trunk matches the IP address of the originating device, choose this option, which equals the default setting. Cisco Unified Communications Manager, which identifies the trunk by using the source IP address of the incoming packet and the signaling port number, does not route the call to a different (new) SIP trunk. The call occurs on the SIP trunk on which the call arrived.
  • Contact Info Header—If the SIP trunk uses a SIP proxy, choose this option. Cisco Unified Communications Manager parses the contact header in the incoming request and uses the IP address or domain name and signaling port number that is specified in the header to reroute the call to the SIP trunk that uses the IP address and port. If no SIP trunk is identified, the call occurs on the trunk on which the call arrived.
  • Call-Info Header with purpose=x-cisco-origIP—If the SIP trunk uses a Customer Voice Portal (CVP) or a Back-to-Back User Agent (B2BUA), choose this option. When the incoming request is received, Cisco Unified Communications Manager parses the Call-Info header, looks for the parameter, purpose=x-cisco-origIP, and uses the IP address or domain name and the signaling port number that is specified in the header to reroute the call to the SIP trunk that uses the IP address and port. If the parameter does not exist in the header or no SIP trunk is identified, the call occurs on the SIP trunk on which the call arrived.

BGP Aggregate Addresses

BGP Aggregate Addresses

With BGP you have two different ways to create aggregate Routes:

  • Aggregate addresses with static routes
  • The command aggregate-address

The whole document will be using the following configuration:

The examples will mainly use the loopback addresses from R1

Route aggregation with static routes

This example shows how an aggregate address can be created with the use of a static route:

view source
print?
1R1
2router bgp 1
3 no synchronization
4 bgp log-neighbor-changes
5 network 172.30.0.0 mask 255.255.254.0
6 neighbor 116.1.12.2 remote-as 2
7 no auto-summary
8 !
9 ip route 172.30.0.0 255.255.254.0 Null0

A static summary route is configured on R1 which includes both loopback interfaces an is then included into BGP with the network command. Since the static summary route itself is no real destination, the next hop for the static route has to be set to the interface null0. If either R2 or R3 got packets which match the aggregate route from R1 it will be sent to R1. R1 itself matches the packet with its more-specific route entries in the routing table and forwards it accordingly or drops it if it doesnt find a match with a more-specific route.
The following output shows R3’s BGP Table:

view source
print?
01R3#sh ip bgpBGP table version is 6, local router ID is 10.0.1.3
02Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
03 r RIB-failure, S Stale
04Origin codes: i - IGP, e - EGP, ? - incomplete
05
06 Network Next Hop Metric LocPrf Weight Path
07*>10.0.0.0/24 0.0.0.0 0 32768 i
08*> 10.0.1.0/24 0.0.0.0 0 32768 i
09*> 172.30.0.0/23 144.1.23.2 0 2 1 i
10*> 192.168.0.0 144.1.23.2 0 0 2 i*
11> 192.168.1.0 144.1.23.2 0 0 2 i

Route Aggregation with the aggregate-address command

R1 will now advertise its summary address to R2 with the aggregate-address command. At least one route from the summary address’ IP block has to be in the BGP table to get BGP to advertise the aggregate-addresses. You can either do this via redistribution from an IGP or with the network statement.

view source
print?
1R1
2router bgp 1
3 no synchronization
4 bgp log-neighbor-changes
5 network 172.30.0.0 mask 255.255.255.0
6 network 172.30.1.0 mask 255.255.255.0
7 aggregate-address 172.30.0.0 255.255.254.0
8 neighbor 116.1.12.2 remote-as 2
9no auto-summary

R1 is now advertising the aggregate-address itself and all more-specific routes which can be found in its BGP table:

R2#sh ip bgp
BGP table version is 10, local router ID is 192.168.1.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
*> 10.0.0.0/24 144.1.23.3 0 0 3 i
*> 10.0.1.0/24 144.1.23.3 0 0 3 i
*> 172.30.0.0/24 116.1.12.1 0 0 1 i
*> 172.30.0.0/23 116.1.12.1 0 0 1 i
*> 172.30.1.0/24 116.1.12.1 0 0 1 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i

The aggregate-address can be filtered out if not every peer should receive the aggregate-address. R2 is now filtering out the aggregate-address towards R3 with a ip prefix-list and a route-map.

R2

router bgp 2

no synchronization

bgp log-neighbor-changes

network 192.168.0.0

network 192.168.1.0

neighbor 116.1.12.1 remote-as 1

neighbor 144.1.23.3 remote-as 3

neighbor 144.1.23.3 route-map To-R3 out

no auto-summary

!

ip prefix-list AGGREGATE seq 5 permit 172.30.0.0/23

!

route-map To-R3 deny 10

match ip address prefix-list AGGREGATE

!

route-map To-R3 permit 20

R3#sh ip bgp
BGP table version is 47, local router ID is 10.0.1.3
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/24 144.1.23.2 0 2 1 i
*> 172.30.1.0/24 144.1.23.2 0 2 1 i
*> 192.168.0.0 144.1.23.2 0 0 2 i
*> 192.168.1.0 144.1.23.2 0 0 2 i

Suppressing more-specific routes

The keyword summary-only filters all more-specific routes which belong to the aggregate-address and only the summary will be advertised.

R1

router bgp 1

no synchronization

bgp log-neighbor-changes

network 172.30.0.0 mask 255.255.255.0

network 172.30.1.0 mask 255.255.255.0

aggregate-address 172.30.0.0 255.255.254.0 summary-only

neighbor 116.1.12.2 remote-as 2

no auto-summary

The more-specific routes are still shown in R1’s BGP table, but they are marked with as suppressed (s>):

R1#sh ip bgp
BGP table version is 12, local router ID is 172.30.1.1
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
*> 10.0.0.0/24 116.1.12.2 0 2 3 i
*> 10.0.1.0/24 116.1.12.2 0 2 3 i
s> 172.30.0.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 0.0.0.0 32768 i
s> 172.30.1.0/24 0.0.0.0 0 32768 i
*> 192.168.0.0 116.1.12.2 0 0 2 i
*> 192.168.1.0 116.1.12.2 0 0 2 i

R3 and also R2 now only have the summary address left:

R3#sh ip bgp
BGP table version is 12, local router ID is 10.0.1.3
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 144.1.23.2 0 2 1 i
*> 192.168.0.0 144.1.23.2 0 0 2 i
*> 192.168.1.0 144.1.23.2 0 0 2 i

Advertising the aggregate-address and more-specific routes

In some cases it might be useful to not only have the aggregate-address but also the more-specific routes. Below R1 is advertising (again) the aggregate-address and both more-specific routes. While the aggregate-address is left by its default, the more-specific routes have set a community attribute:

R1

router bgp 1

no synchronization

bgp log-neighbor-changes

network 172.30.0.0 mask 255.255.255.0

network 172.30.1.0 mask 255.255.255.0

aggregate-address 172.30.0.0 255.255.254.0

neighbor 116.1.12.2 remote-as 2

neighbor 116.1.12.2 send-community

neighbor 116.1.12.2 route-map To-R2 out

no auto-summary

!

access-list 101 permit ip host 172.30.0.0 host 255.255.254.0

!

route-map To-R2 permit 10

match ip address 101

set community none

!

route-map To-R2 permit 20

set community no-export

The summary-only keyword has been deleted so R1 will advertise its more-specific routes again. The route-map To-R2 sequence 10 now matches the aggregate-address and leaves it to its defaults while all other advertised routes (only the two more-specific routes in this case) have the community attribute no-export. The community attribute no-export means that the receiving AS is not allowed to advertise those routes to another eBGP Peer, the routes still will be advertised to iBGP Peers. Something to also have a look into is the ACL 101 with its special use, instead of using a source and destination address, the IP prefix is used as the source host and the prefix mask is used as the destination host. This ACL will only match on the prefix 173.30.0.0/23, while a standard ACL like permit 172.30.0.0 0.0.1.255 would match on the aggregate and on both more-specific prefixes. Remember a 0 in a wildcard mask means match this bit while a 1 means dont care about this bit. So having a wildcard like 0.0.1.255 means that do not care about the last bit in the third octet that also means that bit could be a 0 or a 1 which leads do a decimal 0 or 1 (172.30.0.0 and 172.30.1.0). An ip prefix-list could have been used instead of an ACL to match the aggregate address.

The BGP Tables on R2 and R3 now look like this:

R2#sh ip bgp
BGP table version is 16, local router ID is 192.168.1.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
*> 10.0.0.0/24 144.1.23.3 0 0 3 i
*> 10.0.1.0/24 144.1.23.3 0 0 3 i
*> 172.30.0.0/24 116.1.12.1 0 0 1 i
*> 172.30.0.0/23 116.1.12.1 0 0 1 i
*> 172.30.1.0/24 116.1.12.1 0 0 1 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i

R3#sh ip bgp
BGP table version is 16, local router ID is 10.0.1.3
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 144.1.23.2 0 2 1 i
*> 192.168.0.0 144.1.23.2 0 0 2 i
*> 192.168.1.0 144.1.23.2 0 0 2 i

If we have a look at the more-specific routes on R3, we’ll see that R1 advertises them with a community:

R2#sh ip bgp 172.30.1.0
BGP routing table entry for 172.30.1.0/24, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Not advertised to any peer
1
116.1.12.1 from 116.1.12.1 (172.30.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export

Advertising aggregate an selected more-specific routes

In case your own AS is connected with more than one peer to one or more ISPs, you can select over which peers traffic should be delivered for your different prefixes if you only advertise those prefix over the desired peer. With an additional advertisement of an aggregate-address you can also have a redundancy in case one of those peers loses its session. The selective advertisement of more-specific routes can be defined over a so called suppress-map in which the routes are defined that should not be advertised to the other AS. The following example shows a configuration for one peer on the router to see how the suppress-map works.

R1

router bgp 1

no synchronization

bgp log-neighbor-changes

network 172.30.0.0 mask 255.255.255.0

network 172.30.1.0 mask 255.255.255.0

aggregate-address 172.30.0.0 255.255.254.0 suppress-map SUP

neighbor 116.1.12.2 remote-as 2

no auto-summary

!

ip prefix-list SUP seq 5 permit 172.30.0.0/24

!

route-map SUP permit 10

match ip address prefix-list SUP

R1#sh ip bgp
BGP table version is 15, local router ID is 172.30.1.1
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
*> 10.0.0.0/24 116.1.12.2 0 2 3 i
*> 10.0.1.0/24 116.1.12.2 0 2 3 i
s> 172.30.0.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 0.0.0.0 32768 i
*> 172.30.1.0/24 0.0.0.0 0 32768 i
*> 192.168.0.0 116.1.12.2 0 0 2 i
*> 192.168.1.0 116.1.12.2 0 0 2 i

AS_Set

The as-set keyword within an aggregate-address will set all AS which the more-specific routes have passed to the point where the aggregate-address has been configured. Without this keyword, the aggregate address would only show the passed AS’ from the point where the aggregate-route has been configured. R2 is now creating an aggregate-address for both loopback interfaces of R1 with the summary-only keyword only. The BGP Table of R3 shows the aggregate address as originated from AS2:

R3#sh ip bgp
BGP table version is 24, local router ID is 10.0.1.3
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 144.1.23.2 0 0 2 i
*> 192.168.0.0 144.1.23.2 0 0 2 i
*> 192.168.1.0 144.1.23.2 0 0 2 i

If the keyword as-set is used on R2, the path information in R3 BGP table shows now that its originally coming from R1:

R2

router bgp 2

no synchronization

bgp log-neighbor-changes

network 192.168.0.0

network 192.168.1.0

aggregate-address 172.30.0.0 255.255.254.0 as-set summary-only

neighbor 116.1.12.1 remote-as 1

neighbor 144.1.23.3 remote-as 3

no auto-summary

R3#sh ip bgp
BGP table version is 25, local router ID is 10.0.1.3
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 172.30.0.0/23 144.1.23.2 0 0 2 1 i
*> 192.168.0.0 144.1.23.2 0 0 2 i
*> 192.168.1.0 144.1.23.2 0 0 2 i

Important to know is that if as-set is used the aggregate-route inherits all attributes of its more-specific routes. Furthermore if the paths of the more-specific routes do not match, the unsorted AS List (AS_Set) will be used and shown in the BGP Table instead of the sorted one (AS_Sequence) . R1 will drop this summary route due to the BGP loop prevention mechanism since the aggregate-address now contains all path informations, including AS 1.

Related Posts with Thumbnails