Tag: cisco

Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerabilities

Official document on Cisco Security Advisory website

Summary

Cisco IOS XR Software contains multiple vulnerabilities in the Border Gateway Protocol (BGP) feature. These vulnerabilities include:

Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update.

The vulnerability manifests when a BGP peer announces a prefix with a specific invalid attribute. On receipt of this prefix, the Cisco IOS XR device will restart the peering session by sending a notification. The peering session will flap until the sender stops sending the invalid/corrupt update. This vulnerability was disclosed in revision 1.0 of this advisory.

Cisco IOS XR BGP process will crash when sending a long length BGP update message.

When Cisco IOS XR sends a long length BGP update message, the BGP process may crash. The number of AS numbers required to exceed the total/maximum length of update message and cause the crash are well above normal limits seen within production environments.

Cisco IOS XR BGP process will crash when constructing a BGP update with a large number of AS prepends.

If the Cisco IOS XR BGP process is configured to prepend a very large number of Autonomous System (AS) Numbers to the AS path, the BGP process will crash. The number of AS numbers required to be prepended and cause the crash are well above normal limits seen within production environments.All three vulnerabilities are different vulnerabilities from what was disclosed in the Cisco Security Advisory “Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities” on the 2009 July 29 1600 UTC.

Affected Products

The “Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update” vulnerability affects all Cisco IOS XR Software devices after and including software release 3.4.0 configured with BGP routing.

The other two vulnerabilities affect all Cisco IOS XR Software devices configured with BGP routing.

Workarounds

Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update.
There are no workarounds on the affected device itself. Co-ordination is required with the peering neighbor support staff to filter the invalid update on their outbound path. The following procedure explains how to help mitigate this vulnerability:

Using the peer IP address in the log message that was generated when the Cisco IOS XR Software device received the invalid update; capture the notification message hex dump from the CLI command show bgp neighbor and contact the Cisco TAC, who can assist with a decode. Details on how to contact Cisco TAC are contained within the “Obtaining Fixed Software” section of this advisory.

For illustrative purposes, the following example shows a log message generated by an affected device when it receives an invalid/corrupt update message:

RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path

These details can be captured and provided to Cisco TAC to decode the update message. show bgp neighbors [ip address of neighbor from above log message]:

RP/0/RP0/CPU0:CRS#show bgp neighbors 192.168.0.1        

<capture output and provide to Cisco TAC>

Working with Cisco TAC, the decode of the above will display the AS path in a manner illustrated below.

ATTRIBUTE NAME:  AS_PATH

 AS_PATH: Type 2 is AS_SEQUENCE
 AS_PATH: Segment Length is 4 (0x04) segments long
 AS_PATH: 65533  65532 65531 65531

Working cooperatively with your peering partner, request that they filter outbound prefix advertisements from the identified source AS (in this example 65531) for your peering session. The filters configuration methods will vary depending on the routing device operating system used. For Cisco IOS XR Software the filters will be applied using Routing Policy Language (RPL) policies or with Cisco IOS Software via applying route-maps that deny advertisements matching that AS in their AS-PATH. Once these policies are applied, the peering session will be re-established.

For further information on Cisco IOS XR RPL consult the document “Implementing Routing Policy on Cisco IOS XR Software” at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699.

For further information on Cisco IOS route maps with BGP, consult the document “Cisco IOS BGP Configuration Guide, Release 12.4T” at the following link: http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/tbgp_c.html.

Cisco IOS XR BGP process will crash when sending a long length BGP update message
While the long length BGP update message can be caused by any number of attributes, then most common would be the AS Path. Limiting the number of AS numbers in the AS Path Attribute should mitigate this vulnerability. The following shows an example of filtering on AS paths within Cisco IOS XR Software:

route-policy maxas-limit
# Check number of AS Numbers in AS Path attribute.
# If greater than 100 drop the update.
# If less than 100 pass the update.
  if as-path length ge 100 then
        drop
  else
        pass
  endif
end-policy

router bgp 65533
 neighbor 192.168.0.1
  remote-as 65534
   address-family ipv4 unicast
     policy maxas-limit in
     policy maxas-limit out

For further information on Cisco IOS XR RPL consult the document “Implementing Routing Policy on Cisco IOS XR Software” at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699.

Cisco IOS XR BGP process will crash when constructing a BGP update with a large number of AS prepends
There is no workaround for this vulnerability, other than reducing the number of AS path prepends configured within Cisco IOS XR.

I must admit that after reading the document above, a big question sign appeared in my head about the BGP functionality on IOS XR and if we can rely on this in a working environment. I’m sure that Cisco will mitigate this issues as the currently workarounds are just a temporary solution.

Posted on by Calin 0

CCIE R&S V4.0 Written: Beta Exam Announcement

The beta version of CCIE Routing and  Switching Written Exam v4.0 (351-001) is available for scheduling at all worldwide,  Cisco-authorized Pearson VUE testing centers starting August 7, 2009 and continuing  through September 9, 2009.

Nevertheless the number of beta exams is limited, so as soon as all the seats are taken this beta test period will end, even if this is before September 9, 2009.

Candidates may schedule and take the exam on the same day.  The beta exam will be offered at a discounted price of US$50, with full recertification or lab qualification credit granted to all passing candidates.

Another point to keep in mind is that the results will be received six to eight weeks after the close of the beta period. Therefore, CCIEs in suspended status with an expiration date before November 30, 2009 should recertify using another exam. Candidates may only attempt a beta exam once during the beta period.

More information about the steps to register for exam, you can find on The Cisco Learning Network website.

Posted on by Calin 0

Cisco MDS 9222i Multiservice Modular Switch

Posted on by Calin 0

Cisco: The basics about VRF implementation

VRF, meaning Virtual Routing and Forwarding, is a technology implemented in the IP network routers that allows multiple instances of a routing table to exist on the same router in the same time. Since each VRF is independent, the same IP subnet can exist in 2 different VRFs. Basically you can overlap one IP address in 2 VRFs but without conflicting with each other. Even this is possible, I would not suggest doing so, unless you have a very good reason to do it.

Another meaning of VRF is VPN Routing and Forwarding which is a key element in Cisco’s MPLS (Multiprotocol Label Switching) VPN technology. Internet service providers often take advantage of VRF to create separate virtual private networks (VPNs) for customers. Some advantages of  using this technology is than an ISP can provision scalable IP  MPLS VPN services, generate reports (e.g. audit for services), Service Level Agreements (SLA) contracts and more…

To summarize, virtual networks enable administrators to split a physical link into multiple virtual links completely isolated one from the others. Typically, a virtual network will be dedicated to traffic from a specific application or from a specific users / customers.


Now that we clarify the basic of what is and how it works, let’s see where is VRF used the most. As you maybe guess already, this is in the MPLS VPN environment, due to the fact that in today’s business granularity is very important and VRF help network engineers to isolate and provide security for its customers in an ISP environment or to separate services in an Intranet environment. As you probably already know, MPLS functionality is based on P (Provider) routers, PE (Provider edge) routers and CE (Customer edge) routers. Each of these routers must be configured in order for MPLS to work within an enterprise’s architecture. I describe a little bit the MPLS technology, so you can understand better the topology presented below and then following configuration example:

VRF Implementation As you can see from the topology, one PE router can hold and manage multiple virtual routing table, one for each customer that an ISP have. If you are running in a private environment (e.g. Intranet), you can use MPLS VPN to separate services (e.g. office, development…) The  basic functionality is the same and I’ll show you below how to implement VRFs.

The actual configuration of VRFs  is not a complicate task to achieve. There are two main components to a VRF: The route distinguisher(RD) and the route target(RT).

The route distinguisher (RD) is a number which help identify a VPN in a provider’s network and allow for overlapping IP space.

The route target (RT) indicates the VPN membership of a route and allows VPN routes to be imported or exported into or out of your VRFs. The RT functions a little like a routing policy — determining how routes are distributed throughout the particular VPN.

The RD / RT is a 8-byte (64-bits) number which can be written down as follow:

– 16-bit AS number: your 32-bit number
(e.g.) 65000:100

or

–32-bit IP address: your 16-bit number
(e.g) 192.168.0.1:10

Usually the first method is used more often.

For some very basic VRF configuration follow the steps:
1. Enters VRF configuration mode and assigns a VRF name.

Router(config)#ip vrf vrf-name

2. Creates a VPN route distinguisher (RD) following one of the 16bit-ASN:32bit-number or 32bit-IP:16bit-number explained above

Router(config-vrf)#rd route-distinguisher

3. Creates a list of import and/or export route target communities for the specified VRF.

Router(config-vrf)# route-target {import | export | both} route-distinguisher

4. (Optional step) Associates the specified route map with the VRF.

Router(config-vrf)# import map route-map

5. Specifies an interface and enters interface configuration mode.

Router(config)# interface type number

6. Associates a VRF with an interface or subinterface.

Router(config-vrf)# ip vrf forwarding vrf-name

To check your configuration, you can use ping or traceroute tools under Cisco CLI, but remember that you have to use “vrf vrf-name” parameter:

Router# ping vrf vrf-name IP-address

Also you can check the virtual routing table:

Router# show ip route vrf vrf-name

In some of the following posts, I will present a VRF implementation following a real environment topology, but until then I hope you understood the basics of VRF functionality. It’s not hard to implement (from case to case it might be due to local topologies and technology) but it can help you to have a more granular connections and makes troubleshooting more easy, especially in the environments which have a lot of IP addresses under management.

Posted on by Calin 29

Cisco has a new partner for IP-based smart grid buildout initiative

Some months ago Cisco announced it’s plans to provide network infrastructure to utility companies and their customers to manage power supplies and energy consumption.  Now, Cisco found a partner in a Switzerland based company called Landis+Gyr (L+G).

LG_logoLandis+Gyr is the leading global provider of integrated energy management products tailored to energy company needs and unique in its ability to deliver true end-to-end advanced metering solutions. Landis+Gyr operates in more than 30 countries across five continents, and employs over 5,000 people with the sole mission of helping the world manage energy better. For more information please visit www.landisgyr.com.

Together with it’s partner, Cisco is looking to supply utilities with an IP network, from the power generation facilities to the home. The partnership is intended to deliver solutions based on Landis+Gyr’s expertise in advanced metering infrastructure and applications as well as Cisco’s experience in defining the architecture of an end-to-end networking and security solution.

Landis+Gyr’s and Cisco’s collaboration aims to capitalize on the strengths of open standards, such as IP, allowing for greater ease of deployment and scalability, as well as optimized efficiency of communications networks. The two companies plan to work on future architectures in the areas of smart metering, the utility data center, and wireless and fixed last-mile communications with the objective to ensure interoperability across Cisco’s and Landis+Gyr’s smart grid solutions.

According to L+G, their product Gridstream, helps you maximize the effectiveness of your energy management assets through the seamless integration and flow of technology and information. Whether you need the latest smart metering and network technology or personal energy management tools, Gridstream gives you access to a complete range of advanced multi-energy products and systems.

If you take this and associate it with Cisco’s IP based solution, you obtain one excellent product which can communicate remotely based on the most used protocol in the world. For Cisco, and not only, this seems to be a new “gold mine” which will generate a large amount of income since today’s global direction is to reduce functional costs, such as energy in this case.

Source: Landisgyr.com

Posted on by Calin 0