CCIE Playground

BGP Route Server on ASR1000

wojciechowskipiotr — Tue, 24 Jan 2012 20:08:05 +0000

BGP Route Server is feature designated mostly for IX (Internet Exchange) deployment. You can find many deployment around the world mostly using open software like Quagga, but it’s also available on Cisco’s ASR1000 routers. Route server is an advanced route reflector which provide customized policy support for each service provider, which means that standard path selection can be overridden by route policies set per particular provider.

In typical IX design service provider edge routers share common subnet to provide connectivity between each other. Without route reflector full mesh of peerings is required to provide BGP prefix exchange between providers. Each operators set policies for particular neighbors manually. Route reflectors simplifies implementation because edge routers have only maintain session with RR router to receive full prefix table. This reduces CPU and memory requirements on the border routers not to mention OpEX of maintaining of edge routers.
Router servers are advanced route reflectors. There are transparent for traffic path but have ability to override the normal BGP best path with an alternative path based on some policy or suppress all paths for a prefix and therefore not advertise the prefix.
Route server is working within it’s own AS number but is transparent, which means that it’s AS is removed from AS_PATH while advertising to route server client. This feature have to be activated per neighbor in BGP configuration.

router bgp 65100
   neighbor 10.0.0.1 remote-as 100
      address-family ipv4 unicast
      neighbor 10.0.0.1 activate
      neighbor 10.0.0.1 route-server-client

The client routers also have to be prepared to work correctly with route servers. By default router won’t accept eBGP update if first AS number in AS_PATH is different than AS number of router sending the update. This situation occurs while route server is sending it’s transparent updates. Route server client router have to be configured to disable that behavior in order for the client to receive the updates.

router bgp 100
   no bgp enforce-first-as

With this configuration route server is acting as route reflector. Now it’s time to configure policies that will affect standard BGP route selection process. It’s done by using contexts that are applied per neighbor. Route-maps are used to accomplish this task and all standard filtering mechanisms such as as-path access-list or prefix-list can be used.

router bgp 65100
   route-server-context PERMIT_PREFIX_CONTEXT
      address-family ipv4 unicast
         import-map PERMIT_PREFIX
      exit-address-family
   exit-route-server-context
   neighbor 10.0.0.1 remote-as 100
   address-family ipv4 unicast
      neighbor 10.0.0.1 activate
      neighbor 10.0.0.1 route-server-client context PERMIT_PREFIX_CONTEXT
!
ip prefix-list 1 permit 172.16.0.0/16
!
route-map PERMIT_PREFIX permit 10
   match ip address prefix-list 1
!

The import-map references a route-map, where the actual policy is defined by permit statement inside route-map. Prefixes are received from neighbors and standard inbound filtering is applied. The best path from among the subset of matching routes is imported into the virtual table for the contexts. Then standard outbound filtering is applied.

Filed under: Routing Tagged: asr1000, ASR1k, BGP, IOS XE, route reflector, route server

BGP Origin AS Validation – IOS XE 3.5S

wojciechowskipiotr — Tue, 29 Nov 2011 21:35:16 +0000

Just yesterday IOS XE 3.5S for ASR1000 platform has been released. One of the new features introduced for ASR1000 platform is Origin AS Validation for BGP protocol. This feature helps prevent operators from inadvertently advertising routes to networks they do not control using RPKI server to authenticate that certain BGP prefixes.

RPKI (Resource Public Key Infrastructure) server acts as point of authentication that certain prefixes are allowed to originate from particular autonomous systems. Router downloads list of prefixes or prefix ranges from RPKI servers and stores it as SVOC record. When router receive prefix from eBGP neighbor it initially places it in Not Found state and examine it against SVOC table. If prefix does not exist in SVOC table it remains in Not Found state and is installed in the BGP routing table and will only be flagged as a bestpath or considered as a candidate for multipath if there is no Valid alternative. Standard BGP best path selection algorithm still occurs.
Received prefix can also be marked as Valid or Invalid. In first case prefix must be found in SVOC table and Origin AS must match, then prefix is installed in the BGP routing table. If prefix is found in SVOC table but either the corresponding Origin AS received from the eBGP peer is not the AS that appears in the SOVC table or the prefix length does not match then prefix is marked as Invalid and is not advertised to any peer nor be flagged as best path.
Validation state can by optionally be announced to iBGP peers using extended community attribute. This attribute is never send to eBGP peers.

The only configuration required is enabling TCP session to RPKI servers

router bgp 65100
 bgp rpki server tcp 10.0.0.1 port 35000 refresh 600

Filed under: Routing Tagged: asr1000, ASR1k, BGP, IOS XE

EURONOG 1 presentations

wojciechowskipiotr — Mon, 14 Nov 2011 07:42:23 +0000

EURONOG is an international meeting of experts responsible for the design, maintenance and development of ICT networks. It’s first edition took place in Kraków in September. All presentations from this meeting, including mine, are available on conference page.

Filed under: Uncategorized

End of Cisco 7200 Era

wojciechowskipiotr — Wed, 05 Oct 2011 05:41:30 +0000

It was expected since the day ASR1000 has been announced. Now it’s a fact – ASR1000 is a grown up platform so Cisco 7200 is going to finish it’s life. If you want it in your network you have less than a year to order it.
Cisco 7200 EoS/EoL

Filed under: Uncategorized

Identyfying PPPoE transient sessions

wojciechowskipiotr — Tue, 04 Oct 2011 14:24:36 +0000

If PPP negotiations fails (ie. due to problems with authentication or lack of account on RADIUS server) session stays in transient state for some time. You can list those session

bras# show pppoe summary
    PTA  : Locally terminated sessions
    FWDED: Forwarded sessions
    TRANS: All other sessions (in transient state)

                                TOTAL     PTA   FWDED   TRANS
TOTAL                            5678    5673       0       5
GigabitEthernet1/0/0             3863    3862       0       1
GigabitEthernet1/1/0             1815    1811       0       4

It’s possible to identify MAC address for modems that couldn’t establish sessions

bras# sh pppoe ses | i LCP
   3095  28818  000e.5499.722d  Gi1/0/0.525              1  N/A        LCP
   3548  28669  001f.a45c.7a4d  Gi1/1/0.527              1  N/A        LCP
  13370  28817  0013.3319.316d  Gi1/1/0.527              1  N/A        LCP
   6372  28813  0013.3199.751e  Gi1/1/0.527              1  N/A        LCP
   6018  28812  0019.c8a3.3d66  Gi1/1/0.1598             3  N/A        LCP

Filed under: Routing Tagged: BRAS, PPP, PPPoE

PLNOG 7 and EURONOG 1

wojciechowskipiotr — Tue, 27 Sep 2011 18:39:08 +0000

Readers attending PLNOG and EURONOG conference this week (starting tomorrow!) I’d like to invite to my two lectures:

L2 and L3 aspects of QoS (in polish)
Overview of Auditing and Testing Network IPv6 Readiness (in english)

Later, on conferences sites presentations, audio and video recordings will be available for free.
PLNOG
EURONOG

Filed under: Uncategorized

Interface range vlan

wojciechowskipiotr — Thu, 08 Sep 2011 19:38:48 +0000

Interface range command is quite widely used on Cisco switches to configure many physical interfaces at the same time. On 7600 routers it can be also used to configure many SVIs at the same time but you can use it only to configure existing SVIs within range. According to documentation this command cannot be used to create SVIs in that particular range which is not totally true.

Truth is you can’t create new range of SVIs with this command.

c7600-pwo(config)#int range vlan 10-20
                            ^
% Invalid input detected at '^' marker.

There is interface range create vlan command that you have to use to create range of SVIs.

c7600-pwo(config)#int range create vlan 10-20

So you should assume that command interface range vlan 10-22 should not work. Well, you are wrong. Unless you start range within already created range new SVIs will be created.

c7600-pwo(config)#int range vlan 10-22
c7600-pwo(config-if-range)#des test 3
c7600-pwo(config-if-range)#exit
c7600-pwo(config)#do sh run int vlan 22
Building configuration...

Current configuration : 69 bytes
!
interface Vlan22
 description test 3
 no ip address
 shutdown
end

But if specified range does not start within already defined SVIs new SVIs won’t be created

c7600-pwo(config)#int range vlan 9-22
                            ^
% Invalid input detected at '^' marker.

Filed under: Routing Tagged: 7600, SVI

Reserved VLANs on NX-OS 5.2(1)

wojciechowskipiotr — Wed, 31 Aug 2011 12:51:13 +0000

Internal VLANs are used for services like MPLS, FCoE, Multicast over GRE, enhancement to SPAN, etc. Some Features have special requirements like which VLAN can be reserved for them. Example of such service are Multicast VLAN which can only start with VLAN id’s that is multiple of 64.

Prior to release 5.2(1) the reserved VLAN range was 3968 to 4048, and 4094, and it was not configurable. After the upgrade user-defined VLANs might fall within the new reserved range which now range from 3968 to 4095 and is configurable. If that occurs, switch fallback to old range but the features that need the additional reserved VLANs won’t work propely. What you have to do is change range of reserved VLANs using command:

switch(config)# system vlan 2000 reserve
This will delete all configs on vlans 2000-2127. Continue anyway? (y/n) [no] y
Note: After switch reload, VLANs 2000-2127 will be reserved for internal use.
      This requires copy running-config to startup-config before
      switch reload. Creating VLANs within this range is not allowed.

Now the disadvantage if this is you have to reboot whole chassis. Simple switchover between supervisors on Nexus 7000 won’t be enough. Also, if you are using vPC if one switch is using new VLAN range and other one is still configured to use old range switches will not forward those VLANs on vPC peer-link. Hence, those VLANs will get suspended on vPC port-channel. But this should not affect any other VLANs in vPC.

Filed under: Switching Tagged: Nexus, Nexus 7000, NX-OS, vPC

Deleting a subinterface that has IPv6 EIGRP running on it and crashing IOS XE

wojciechowskipiotr — Wed, 10 Aug 2011 17:27:00 +0000

In some cases router running IOS XE might crash or produce traceback if we try to delete logical interface (like ie. port-channel) or subinterface that runs IPv6 EIGRP. This can occur mostly on XNE or older releaseses, has been fixed in new ones. Cisco have internal bug CSCtd63242 describing this problem (might be released into public).

For testing purposes I prepared following configuration

interface Port-channel1
 no ip address
 no negotiation auto
!
interface Port-channel1.282
 encapsulation dot1Q 282
 ip address 10.0.0.1 255.255.255.240
 ipv6 address 2A01:3D0:1:212::1/64
 ipv6 enable
 ipv6 eigrp 150
!

Let’s try to remove configuration

test-rtr(config)#no int port-ch 1
test-rtr(config)#

Exception to IOS Thread:
Frame pointer 2C64F498, PC = 116D5838

ASR1000-EXT-SIGNAL: U_SIGSEGV(11), Process = EIGRP-IPv6
-Traceback= 1#da7989e8973511c6ffbd1828e9ed3784  :10000000+16D5838 systime:B4E7000+19D0 :10000000+16D5A94 :10000000+629B9C :10000000+641A28 :10000000+3F1F108 :10000000+3F1F870 :10000000+3F200E4 

Fastpath Thread backtrace:
-Traceback= 1#da7989e8973511c6ffbd1828e9ed3784  c:B20A000+D8678 c:B20A000+D8658 iosd_unix:B38C000+1247C pthread:AFB8000+56EC 

Auxiliary Thread backtrace:
-Traceback= 1#da7989e8973511c6ffbd1828e9ed3784  pthread:AFB8000+B168 pthread:AFB8000+B148 c:B20A000+EDEB4 iosd_unix:B38C000+1BEE4 pthread:AFB8000+56EC 

PC  = 0x116D5838  LR  = 0x116D5A94  MSR = 0x0002D000
CTR = 0x0B4E89C0  XER = 0x00000000
R0  = 0x116D5A94  R1  = 0x2C64F498  R2  = 0x2C0619D0  R3  = 0x0D0D0D0D
R4  = 0x2C64F4C8  R5  = 0x00000004  R6  = 0x10629B98  R7  = 0x00000000
R8  = 0x03BC53F5  R9  = 0x00000000  R10 = 0x00000001  R11 = 0x00000000
R12 = 0x03BC53F4  R13 = 0x15B09550  R14 = 0x13F1FDB4  R15 = 0x00000000
R16 = 0x00000000  R17 = 0x00000000  R18 = 0x00000000  R19 = 0x00000000
R20 = 0x00000000  R21 = 0x13F20000  R22 = 0x2C64F5E8  R23 = 0x15240000
R24 = 0x153E0000  R25 = 0x15E90000  R26 = 0x2C647BE0  R27 = 0x00000000
R28 = 0x2C64F4C8  R29 = 0x10629B98  R30 = 0x00000004  R31 = 0x0D0D0D0D

Writing crashinfo to bootflash:crashinfo_RP_00_00_20110801-230510-UTC
Buffered messages:

000060: *Aug  1 06:34:36.421 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
000061: *Aug  1 06:35:15.252 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down
000062: *Aug  1 06:36:33.701 UTC: %SYS-5-CONFIG_I: Configured from console by console
000063: *Aug  1 06:36:53.770 UTC: %SYS-5-CONFIG_I: Configured from console by console
000064: *Aug  1 06:37:26.149 UTC: %SYS-5-CONFIG_I: Configured from console by console
000065: *Aug  1 06:37:27.859 UTC: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to up
000066: *Aug  1 06:37:28.859 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to up
000067: *Aug  1 06:37:27.932 UTC: %LINK-3-UPDOWN: SIP0/0: Interface GigabitEthernet0/0/0, changed state to up
000068: *Aug  1 06:48:50.464 UTC: %SYS-5-CONFIG_I: Configured from console by console
000069: *Aug  1 06:51:37.651 UTC: %SYS-5-CONFIG_I: Configured from console by console
000070: *Aug  1 07:06:52.608 UTC: %SYS-6-EXEC_EXPIRE_TIMER: (tty 0 (0.0.0.0)) exec-timeout timer expired for user
000071: *Aug  1 22:49:29.616 UTC: %SYS-5-CONFIG_I: Configured from console by console
000072: *Aug  1 23:03:52.064 UTC: %LINK-5-CHANGED: Interface GigabitEthernet0/0/0, changed state to administratively down
000073: *Aug  1 23:03:53.064 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to down
000074: *Aug  1 23:04:02.488 UTC: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to up
000075: *Aug  1 23:04:03.488 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to up
000076: *Aug  1 23:04:02.530 UTC: %LINK-3-UPDOWN: SIP0/0: Interface GigabitEthernet0/0/0, changed state to up
000077: *Aug  1 23:04:08.230 UTC: %SYS-5-CONFIG_I: Configured from console by console
Queued messages:Aug  1 23:06:41.536 R0/0: %PMAN-3-PROCHOLDDOWN: The process ppc_linux_iosd-image has been helddown (rc 139)
Aug  1 23:06:41.742 R0/0: %PMAN-0-PROCFAILCRIT: A critical process ppc_linux_iosd_image has failed (rc 139)
Aug  1 23:06:41.914 R0/0: %PMAN-3-RELOAD_RP_SB_NOT_READY: Reloading: Fault on Active RP bay but Standby RP bay is not ready
Aug  1 23:06:48.762 R0/0: %PMAN-5-EXITACTION: Process manager is exiting: critical process fault, ppc_linux_iosd_image, rp_

What’s interested

There are two things we can do except recommended upgrade:
1) Remove EIGRP configuration from the subinterface with a before deleting the subinterface
2) Activate software redundancy (additional license is required) so software crash would cause only switchover to redundant IOS process.

Filed under: IPv6, Routing Tagged: asr1000, ASR1k, EIGRP, IOS XE, IPv6

Simple line card performance testing configuration (IOS XR)

wojciechowskipiotr — Fri, 15 Jul 2011 18:00:05 +0000

It’s easy trick but I’m going to put it here anyway so anyone can use it and for me so I can easy find code when I need it :) This is “snake” that is made traffic from generator go through all ports on line cards and between two line cards. It’s made for testing purposes in lab environment if you need to verify performance capability of ASR9K router (or any other runnin IOS XR in this case) for customer.

The idea is simple – Ethernet ports are configured as EFP’s for particular VLAN and then we alternate point-to-point cross connects and physical connections between subsequent ports, remembering that first and last port in out chain are connected to traffic generator

l2vpn
 xconnect group snake
  p2p 1
   interface gi 0/0/0/1.50
   interface gi0/0/0/2.50
  !
  p2p 2
   interface gi 0/0/0/3.50
   interface gi0/0/0/4.50
  !
  p2p 3
   interface gi 0/0/0/5.50
   interface gi0/0/0/6.50
  !
 !
!

Filed under: Switching Tagged: ASR 9000, ASR9000, ASR9k, IOS XR, performance