CCIE GNS3 Topology

This post is dedicated to the best practise for setting up CCIE R&S lab and I want to show you how to set up a practise rack to where you will never ever have to switch a single cable again , no matter what your lab topology looks like , the set up that does it all !
The only difference between this one and the previous topology is that I have changed the symbols so it’s easier to differentiate devices on screen but except for that it is all the same and no other changes have been made. Further down I have added initial configs files for CBT Nuggets CCIE series, INE , IP Expert and Narbik (Super Lab)
CCIE R&S topology I have built and been using on GNS3 for the CCIE journey.
So far I have seen and used topologies with a GNS3 built in Frame Relay switch plus 6 routers (INE spec) so I’ve decided to create one with CLI configurable Frame Switch and connect all devices in a way so that you are able to create any topology without the need of changing the cabling etc … The reason for 17 devices being used is because some of the CCIE preparation series like IP Expert, CCIE Service Provider see image   have topologies with more than 6 routers which is expectable from Cisco in the current v4 Lab exam but the idea is so we can practise not only INE lab scenarios with 6 routers but also IP Expert lab scenarios where Quadruple CCIE Scott Morris uses topology with 9 routers instead and of course for us to become more familiar with the actual frame relay switch configuration.
In case you having some issues with connectivity or the gns3 is crashing just after you start the topology, change the (127.0.0.1 with localhost) or vice versa in the .net file.
Please remember, that you can’t run most of layer 2 technologies command, since GNS3 (and all emulators) just do the software, where switches are mostly ASIC programmed to run the features.
This topology is customizable which means that with a little tweaking (vlans, ip addreses, frame switch config etc…) you will be able to practise any R&S scenario you can possibly find out there.
See intial configs below – INE lab specification VOL1
Frame_switch   BB1   BB2   BB3   R1   R2   R3   R4   R5   R6   SW1   SW2   SW3   SW4

See intial configs below – IP Expert lab specification VOL1
FRAME_SWITCH   BB1   BB2   BB3   SW1   SW2   SW3   SW4   R1   R2   R4   R5   R6   R7   R8   R9

See intial configs below – CBT Nuggets lab specification (CCIE R&S LAB SERIES)
CBT_BB1   FRAME_SWITCH_CBT   CBT_SW1   CBT_SW2   CBT_SW3   CBT_SW4
CBT_R1  CBT_R2   CBT_R3   CBT_R4   CBT_R5   CBT_R6   CBT_R7

See intial configs below – Narbik Super Lab specification (CCIE R&S LAB SERIES)
SW1 – SW2 – SW3 – SW4
vlan data
vlan 111
vlan 112
vlan 113
vlan 3
apply
exit

Read More

Filtering routers from a neighbor using prefix-lists

The this post I’m going to filter routes allow only those from R1 specifically with prefix length between 17 – 19 long into the routing table of R3
The routing table on R3 looks like this at the moment:
17.0.0.0/19 is subnetted, 2 subnets
R       17.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
R       17.2.0.0 [120/1] via 10.1.1.2, 00:00:02, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
12.0.0.0/18 is subnetted, 2 subnets
R       12.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
R       12.2.0.0 [120/1] via 10.1.1.2, 00:00:02, FastEthernet0/0
13.0.0.0/17 is subnetted, 2 subnets
R       13.0.0.0 [120/1] via 10.1.1.1, 00:00:08, FastEthernet0/0
R       13.2.0.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
14.0.0.0/9 is subnetted, 2 subnets
R       14.0.0.0 [120/1] via 10.1.1.1, 00:00:08, FastEthernet0/0
R       14.128.0.0 [120/1] via 10.1.1.2, 00:00:03, FastEthernet0/0
Configuration steps
1) Configure a prefix-list to filter routes

R3(config)#ip prefix-list R1-Filter permit 0.0.0.0/0 ge 17 le 19

2) Configure a prefix-list that identifies the routing source

R3(config)#ip prefix-list R1 seq 5 permit 10.1.1.1/32    

3) Apply the distribute-list prefix

R3(config)#router rip
R3(config-router)#distribute-list prefix R1-Filter gateway R1 in f0/0

The result is just those routes in the perfix-list are allowed and only from R1 (10.1.1.1)

R3(config-router)#do sh ip ro rip
17.0.0.0/19 is subnetted, 1 subnets
R       17.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
12.0.0.0/18 is subnetted, 1 subnets
R       12.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0
13.0.0.0/17 is subnetted, 1 subnets
R       13.0.0.0 [120/1] via 10.1.1.1, 00:00:07, FastEthernet0/0

Read More

IPv6 Routing Protocol Redistribution

Though the transition period from IPv4 to IPv6 is going to last for a long time in which both protocols will coexist, we shouldn’t forget that the final goal of IPv6 is to completely replace IPv4.
The best way to gain more experience with the new intricacies and challenges of IPv6 is to test IPv6-based services in the presence of IPv4 as well in a pure IPv6 environment.
The purpose of this lab is to test redistribution between IPv6 routing protocols in an exclusively IPv6 environment.

So I am following exactly the same scenario as the previous post about IPv4 redistribution and I will point out some particularities related to IPv6.
I will start by the problematic design of redistribution from one routing domain into another with lower (better) administrative distance.
If you are not familiar with routing redistribution I strongly recommend you to take a look at the previous post.

Redistribution from one routing domain into another with lower (better) administrative distance:

All the following topologies are subject to the same concept:

As an example, I picked up the case where the source routing domain is EIGRP (internal prefix AD =90 and external prefix AD = 170) and the destination domain is OSPF with a better AD of 110.
Picture 1: Lab High level design

Picture 2: Low level design

Lab content:

1- Redistribution
2- Test connectivity from the BR R1
3- Solutions to overcome suboptimal paths
   3.1- Control paths by controlling the redistribution at the border routers
   3.2- Change the AD per-prefixes
   3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list
   3.4- Prefix summarization
4- Troubleshooting notes5- Conclusion

1- Redistribution

- Redistribute 2001:DB8:123:3333::/64 (external domain/connected) into EIGRP at R3

The network 2001:DB8:123:3333::/64 can be administred with a different IGP than EIGRP or just a directly connected network (a loopback interface in our case).

Because EIGRP differentiates between internal and external prefixes by assigning different Administrative Distances, the prefix 2001:DB8:123:3333::/64 become (D EX) with AD=170.

ipv6 router eigrp 123 router-id 3.3.3.33 no shutdown redistribute ospf 123 metric 1500 1 100 1 1500 route-map to-eigrp include-connected ! ipv6 prefix-list ospf-pfx seq 5 permit 2001:DB8:123:3333::/64 ! ! route-map to-eigrp permit 10 match ipv6 address prefix-list ospf-pfx set tag 3333

Read More

IPv6 multicast over IPv6 IPSec VTI

IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance.

One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes it natively support IPv6 multicast.
In this lab we will be using IPv6 IPSec site-to-site protection using VTI to natively support IPv6 multicast.

The configuration involves three topics: IPv6 routing, IPv6 IPSec and IPv6 multicast. Each process is built on the top the previous one, so before touching IPsec, make sure you have local connectivity for each segment of the network and complete reachability through IPv6 routing.
Next step, you can move to IPv6 IPSec and change routing configuration accordingly (through VTI).
IPv6 multicast relies on a solid foundation of unicast reachability, so once you have routes exchanged between the two sides through the secure connection you can start configuring IPv6 multicast (BSR, RP, client and server simulation).

Picture1: Lab topology

Lab outline

• Routing
  • OSPFv3
  • EIGRP for IPv6
• IPv6 IPSec
  • Using IPv6 IPSec VTI
  • Using OSPFv3 IPSec security feature
• IPv6 Multicast
  • IPv6 PIM BSR
• Offline lab
• Troubleshooting cases
• Performance testing

Routing

Note: IPv6 Routing relies on link-local addresses, so for troubleshooting purpose, link-local IPs are configured to be similar to their respective global addresses, so they are easily recognisable. This will be of a tremendous help during troubleshooting. Otherwise you will find yourself trying to decode the matrix : )

OSPFv3

Needs an interface configured with IPv4 address for Router-id
OSPFv3 offloads security to IPv6 native IPv6, so you can secure OSPFv3 communications on purpose: per- interface or per-area basis.

Read More

Sending with one key and accepting another

With RIP text based authentication you can send with one key and accept another. The key sent will be the lower key in the key chain and the higher one is used to match the other sides sent key.
R4(config)#key chain RIP-AUTH
R4(config-keychain)#key 1
R4(config-keychain-key)#key-string cisco
R4(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 1993 infinite
R4(config-keychain-key)#key 2
R4(config-keychain-key)#key-string ccie
R4(config-keychain-key)#send-lifetime 00:00:00 Jan 1 1993 infinite
R4(config-keychain-key)#
R4(config-keychain-key)#interface Serial0/1
R4(config-if)# ip rip authentication mode text
R4(config-if)# ip rip authentication key-chain RIP-AUTH
R5(config)#key chain RIP-AUTH
R5(config-keychain)#key 1
R5(config-keychain-key)#key-string ccie
R5(config-keychain-key)#send-lifetime 00:00:00 1 jan 1993 infinite
R5(config-keychain-key)#key 2
R5(config-keychain-key)#key-string cisco
R5(config-keychain-key)#accept-lifetime 00:00:00 1 jan 1993 infinite
R5(config-keychain-key)#ex
R5(config-keychain)#int s0/1
R5(config-if)#ip rip authentication key-chain RIP-AUTH
With this configuration R4 will send “cisco” and R5 “ccie”. Also Note: Text authentication is the default option.

Read More

EIGRP Unequal LoadBalancing and Path Control

Hi All,
I have been Cisco reading and doing labs all weekend and still have about 6hrs before I decide it’s time to stop!
This afternoon I have found this video http://www.youtube.com/watch?v=ErUzMl0a-E8&feature=relmfu made by Mohammad Said and I must tell you that this is the best resource I have ever been able to find which explains exactly how EIGRP calculates its metric and decides which way to route packets.  I have seen and practised many EIGRP labs but without any doubt this one is my favourite !
For the past 3 hrs I have been drawing and carefully looking into EIGRP metric calculation , successors , feasible successors , advertise distance and feasible distance based on Mohammad’s video and finally it’s all clear !
After you’ve watched and understood Mohammad’s video , there is no way Cisco can trick you on your R&S lab exam , well they still can and probably will but not with EIGRP metrics
GNS3 net file : EIGRP Unequal LoadBalancing and Path Control
Basic configs : EIGRPLOADBALAN_CONFIG

Read More

OSPF LSAs and Area Types

I know this is a fairly large set up but believe me it teach you practically everything you need to know about LSAs and different ospf area types. I have to admit this is not something I’ve created myself. I stumbled upon this video on youtube http://www.youtube.com/watch?v=7LzrvCvb-Ro&list=PLC6197249373E47E9 made by one of the best network instructors out there Keith Barker and then thought it would be great to lab it up and configure everything with Keith.


 

  
I also thought of adding another ospf area number 3 and connect it to area 1 where then we would have discontiguous areas ! and for a fix we would have to use either GRE Tunnel or Virtual Link but as you can see I did not do it just to avoid having too many devices to work with and Virtual link and GRE Tunnel I will explain in another post.

Please go ahead and download following net file and build your topology
OSPF LSAs and Area Types
Please download following basic config , copy and paste them into relevant devices
basic_config_files
As a side note: if you’ve already visited my other post http://ccie4all.wordpress.com/2012/11/03/ccie_gns3_topology_/ and managed to built you topology presented in CCIE GNS TOPOLOGY post  then YOU DO NOT have to use the files provided in this post and build the topology from scratch cause you will easily be able to recreate above set up once you’ve got CCIE GNS TOPOLOGY running on your machine. You will have to use few subinterfaces on your routers , add few vlans on switches but believe me it saves hell lot of time and most importantly it teaches you many important configuration and troubleshooting skills what you will have to face in yur R&S lab exam and the real world also that way you only have one gns3 network on your PC that DOES IT ALL for you
Check out this cisco tutorial about OSPF area types (although it does not explain the Not So Totally Stubby area)
http://www.cisco.com/E-Learning/bulk/public/ccnp/QLM_Configuring_OSPF_Special_Area_Types_BSCI/player.html
Thought it’d be good to add LSA types and various stub configuration.
Type 1 – Represents a router
Type 2 – Represents the pseudonode (designated router) for a multiaccess link
Type 3 – A network link summary (internal route)
Type 4 – Represents an ASBR
Type 5 – A route external to the OSPF domain
Type 7 – Used in stub areas in place of a type 5 LSA
Stub Areas
A stub area allows Type 2 and Type 3 LSAs. Type 5 LSAs are NOT  passed into the area. The ABR injects a type 3 LSA containing a default route into the stub area.Filters the LSA-type 4 and 5.You will just have inter-area routes inside this area (routes with the “IO” code)
ABR(config-router)#area 51 stub
ABR(config-router)#area 51 default-cost 10
Defines the cost of a default route sent into the stub area. Default is 1.
INTERNAL(config-router)#area 51 stub

• Note
  All routers in the stub area must be configured with the area x stub command, including the Area Border Router (ABR).
• Stub= No type 5 LSAs and default route

Totally Stubby Areas
This is Cisco proprietary.Like stub areas, totally stubby areas do not receive type-3 , type-4 or type-5 LSAs from their ABRs . All routing out of the area relies on the single default route injected by the ABR
ABR(config-router)#area 51 stub no-summary
INTERNAL(config-router)#area 51 stub

• Note
  Whereas all internal routers in the area are configured with the area x stub command, the ABR is configured with the area x stub no-summary command
• Totally Stubby – ONLY Type 2 LSAs and default route

Not-So-Stubby Areas (NSSA)
This area is used when you are redistributing external routes. An NSSA makes use of type 7 LSAs, which are essentially type 5 LSAs in disguise. You will see “IO” routes (they are in the routing table because of the type-3 LSAs) also “N1/2″ routes which represents the NSSA area. This allows an ASBR to advertise external links to an ABR, which converts the type 7 LSAs into type 5 before flooding them to the rest of the OSPF domain.Type 3 LSAs will pass into and out of the area. Unlike a normal stub area, the ABR will NOT  inject a default route into an NSSA unless explicitly configured to do so with
ABR(config-router)#area x nssa default-information originate
As traffic cannot be routed to external destinations without a default route, you’ll probably want to include above command.
ABR(config-router)#area 1 nssa
INTERNAL(config-router)#area 1 nssa

• Note
  All routers in the NSSA stub area must be configured with the area x nssa command.
• NSSA – Type 2, 3, and 7 LSAs with default route

Totally stub not-so-stubby area (totally NSSA)
This is Cisco proprietary.Filters type-3 ,type-4 and 5 LSAs, so inside the area you will only have a default route, besides the “N1/2″ routes that are normal on that type of area.
ABR(config-router)#area 11 nssa no-summary
INTERNAL(config-router)#area 11 nssa

• Note
  Whereas all internal routers in the area are configured with the area x nssa command, the ABR is configured with the area x nssa no-summary command.
• Totally NSSA – Only Type 2 and 7 LSAs and default route

Read More

Confusion about voice vlan

The main reason why I decide to create posts like this one despite the fact that there are millions if not more similar posts, explanations and websites out there on the internet is mainly because I simply enjoy gathering all relevant information from various sources then combine it all into a single unit so we do not have to jump from one website to another in order to find whatever we’re after, this relates to Cisco and Cisco only of course
This set up is most definitely how it all looks like in your office environment, go ahead and first check and see how your PC connects with your desk phone then from the phone trace the cable which most likely connects to RJ45 floor port which most likely is located under your desk then it all goes through the walls of your company all the way back to your Company’s Comms Room (Data Centre) where it connects into a patch panel in one of the network cabinets and from there directly to L2 switch which then goes to your business’s L3 Core switches, routers,firewalls etc …


I have spent really long hours on this one, especially the one that involves  802.1p tag
I have been looking into this like a madman and must admit that Voice combined with QOS is not the easiest to understand.
The reason why it takes so long top prepare for the LAB is because you never know what Cisco is going to ask you to configure or troubleshoot and this is because we need to know and understand it all !!
The upstream switch communicates with the Cisco IP phone using CDP to set up an interconnection link that allows the Cisco IP phone to send VoIP packets on its uplink port back to the switch, either in the VoIP VLAN or in the data VLAN
So there are 4 modes to set up a switch port you expect to plug a phone into (Interface Ethernet 4/0 connects to the phone)
===============================================================================
===============================================================================
1. First you can just use a regular access port. In this mode, both the phone traffic and pc data both land on the same access vlan and there is no way to distinguish between the two. Two things to note, because the traffic will use the same vlan then you have a security risk as well as having no ability to provide QOS priority to only the phone. Any QOS is applied to ALL traffic coming in that switch port.
Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport access vlan 79
or
Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport voice vlan none

Read More

MPLS QOS EXPERIMENTAL BITS

After the first unsuccessful CCIE R&S lab attempt in Belgium in my last post I said I was having a little trouble with the MPLS VPN configuration and it most certainly was not because I did not know what ingredients were necessary in order to configure the tunnel between the sites but because the way Cisco asked me to configure it and manipulate the traffic  , it made me think really hard for a long while during the exam (almost 1hr) and it cost me very dearly in the end !




Below topology is from INE SPv3 (Service Provider) video series with Brian McGahan who I’m sure we all know and love to listen to.

This is how it is presented to us in GNS3


GNS3_NET_FILE  : MPLS_QOS_NET_FILE
GNS3 INITIAL CONFIGS : impls_initial_configs
Cisco 12000 series router’s XR_1 and XR_2 are simulated by 3745 routers – these devices are not supported in GNS3 so rack rental is a must. 
Some of you might be asking yourself right now why would I create a post that revolves around MPLS QOS ?? Well , short answer is “be prepare to get stuck in your lab exam ” because even if you get really simple MPLS requirements  , they will definitely confuse you with something else. CCIE lab as we all know is not about best practises and myself having finally experienced it , it is miles away from there , it is about whether you can accomplish given task and meet the requirements or not !
One more thing , make sure you experiment with as many commands as possible (some of the I’ve listed below) and understand how they work and affect the network because even if you manage to get your MPLS VPN Tunnel up and running but you do it not how they asked you to , you will fail the whole section !
mpls ldp router-id Loopback0
mpls ip propagate-ttl
mpls ldp autoconfig
bgp default ipv4-unicast
address-family vpnv4
address-family ipv4 vrf
redistribution within MPLS backbone – especially when you have two different IGPs running inside where you first have to correctly redistribute between them in order to make you BGP/MPLS operational then most likely you will need to do some more redistribution between PE-CE to make it all work !

Read More

Fake DHCPv6 Attack

DHCPv6 relies on stateless UDP communication using UDP 546 and UDP 547 ports. As stated in the RFC 3315 this makes DHCPv6 particularly vulnerable to fake attack, in which SOLICIT messages are generated with random source prefixes.
Using DHCPv6 Rapid-Commit mode, ONLY two messages are exchanged between the client and the server to get an IPv6 prefix.
Picture1: lab topology – IOS 12.4(24)T implemented in GNS3


DHCPv6 server configuration:

ipv6 dhcp pool SLAAC-POOL address prefix 2001:DB8:5AB::/64 lifetime infinite infinite dns-server 2001:DB8:5AB::57 domain-name nouri.com ! interface FastEthernet1/0 ip address 192.168.0.202 255.255.255.0 ipv6 address 2001:DB8::202/64 ipv6 enable ipv6 dhcp server pool0 rapid-commit end

Layer2 Switch configuration:

interface FastEthernet1/0 switchport access vlan 10 ! interface FastEthernet1/1 switchport mode trunk

Below is the Scapy script used for the attack, though awkward, but do the job.
You can enter manually the DHCPv6 sever MAC address from the local neighbor table of through a script by pinging all DHCP agents multicast address FF02::1:2.
SOLCIT messages are sent blindly without even expecting any responses.

Read More

How Multi is MP-BGP in IOS-XR?

This caught me on surprise. I had an impression that IOS-XR as an advanced operating system would support all kinds of multi-protocol transferability over BGP.

As it seems, there is an issue when transferring IPv6 prefixes over an IPv4 peering or IPv4 prefixes over an IPv6 peering. This happens for sure on ASR9k running latest 4.1.0, but i haven't verified it on the CRS yet.

IPv4 prefixes over IPv6 peering
This doesn't seem to be supported based on the available configuration options.
What is even more worrying, is that no other address family is supported too.

RP/0/RSP0/CPU0:ASR#conf t
RP/0/RSP0/CPU0:ASR(config)#router bgp 100
RP/0/RSP0/CPU0:ASR(config-bgp)#neighbor 2001::1:2:3
RP/0/RSP0/CPU0:ASR(config-bgp-nbr)#address-family ?
  ipv6  IPv6 Address Family

IPv6 prefixes over IPv4 peering
This is supported according to the configuration options, but it doesn't work.
Cisco also insists that this is definitely supported.

RP/0/RSP0/CPU0:ASR#conf t
RP/0/RSP0/CPU0:ASR(config)#router bgp 100
RP/0/RSP0/CPU0:ASR(config-bgp)#neighbor 10.11.254.37
RP/0/RSP0/CPU0:ASR(config-bgp-nbr)#address-family ?
  ipv4   IPv4 Address Family
  ipv6   IPv6 Address Family
  l2vpn  L2VPN Address Family
  vpnv4  VPNv4 Address Family
  vpnv6  VPNv6 Address Family

As soon as you enable the IPv6 address family under the IPv4 neighbor, the BGP session is dropped and it never comes up.

RP/0/RSP0/CPU0:ASR#sh bgp sum
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0000000   RD version: 1
BGP main routing table version 1
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               1          1          1          1           1           1

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.11.254.37      0  100        0       0        0    0    0 00:00:00 Idle

Also, debug shows that there are no tries of BGP to establish a session. It's like BGP gets disabled.

The only doc that refers such a limitation (in IOS-XR 3.3 for CRS) is the one in http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.3/conversion/reference/guide/cn33main.html#wp1028960

A given address family is only supported with a neighbor whose address is from that address family. For instance, IPv4 neighbors support IPv4 unicast and multicast address families, and IPv6 neighbors support IPv6 unicast and multicast address families. However, you cannot exchange IPv6 routing information with an IPv4 neighbor and vice versa.

I searched all CCO for more information, but i didn't manage to find something useful. Does anyone have extra information to share? TAC is struggling (as usual) to find an answer...

Update #1
Cisco verified once more that this is a supported configuration. Arie Vayner (and later tac) proposed to add an IPv6 address to the interface being used as an IPv4 next-hop. Indeed, this solved the problem and the BGP session came up. But then it became even more interesting...

Two IPv6 prefixes are learned from the IPv4 neighbor. Next-hop is an IPv6 address.

RP/0/RSP0/CPU0:ASR#sh bgp ipv6 uni 
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0800000   RD version: 5
BGP main routing table version 5
BGP scan interval 60 secs

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
* i2001::1:2:3/128    2003::1:2:3              0    100      0 ?
* i2003::/64          2003::1:2:3              0    100      0 ?

Processed 2 prefixes, 2 paths

If i remove the IPv6 address from the interface that is being used as next-hop (the one i added before), then i automatically get an IPv6 prefix with an IPv4 next-hop!!!

RP/0/RSP0/CPU0:core-distr-kln-02#sh bgp ipv6 uni 
BGP router identifier 10.11.254.38, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0xe0800000   RD version: 6
BGP main routing table version 6
BGP scan interval 60 secs

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
*>i2001::1:2:3/128    10.11.254.41             0    100      0 ?

Processed 1 prefixes, 1 paths

The BGP session stays up, until something happens that will reset it. Then it will stay down forever, as it was happening in the beginning.

I must say that i cannot endorse such an implementation. Using exactly the same configuration, you get different results, depending on the order of (un)configuring things. Also, i cannot understand why the establishment of an IPv4 BGP session that is going to negotiate IPv4/IPv6 address-family capabilities should depend on whether an IPv6 next-hop exists or not. That should be left for the NLRI exchange routine.

Read More

IPv6 multicast over IPv6 IPSec VTI

IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance.
One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes it natively support IPv6 multicast.
In this lab we will be using IPv6 IPSec site-to-site protection using VTI to natively support IPv6 multicast.
The configuration involves three topics: IPv6 routing, IPv6 IPSec and IPv6 multicast. Each process is built on the top the previous one, so before touching IPsec, make sure you have local connectivity for each segment of the network and complete reachability through IPv6 routing.
Next step, you can move to IPv6 IPSec and change routing configuration accordingly (through VTI).
IPv6 multicast relies on a solid foundation of unicast reachability, so once you have routes exchanged between the two sides through the secure connection you can start configuring IPv6 multicast (BSR, RP, client and server simulation).

Picture1: Lab topology

Lab outline

• Routing
  • OSPFv3
  • EIGRP for IPv6
• IPv6 IPSec
  • Using IPv6 IPSec VTI
  • Using OSPFv3 IPSec security feature
• IPv6 Multicast
  • IPv6 PIM BSR
• Offline lab
• Troubleshooting cases
• Performance testing

Routing

Note: IPv6 Routing relies on link-local addresses, so for troubleshooting purpose, link-local IPs are configured to be similar to their respective global addresses, so they are easily recognisable. This will be of a tremendous help during troubleshooting. Otherwise you will find yourself trying to decode the matrix : )

OSPFv3

Needs an interface configured with IPv4 address for Router-id
OSPFv3 offloads security to IPv6 native IPv6, so you can secure OSPFv3 communications on purpose: per- interface or per-area basis.

Read More

VTY IPv6 ACLs in IOS-XR

One of the first things you have to do before adding IPv6 addresses in a router, is to protect its management plane. A simple way to implement a part of that is to define an ACL (Access List) under the relevant terminal lines (VTYs).

In IOS it's quite simple.
One ACL for IPv4 and one ACL for IPv6, which cannot share the same name.

! IOS
!----
ip access-list extended IPV4-VTY-ACL
 permit ip 10.0.0.0 0.0.0.255 any
 deny   ip any any log
!
ipv6 access-list IPV6-VTY-ACL
 permit ipv6 2001:DB8::/32 any
 deny   ipv6 any any log
!
line vty 0 10
 access-class IPV4-VTY-ACL in
 ipv6 access-class IPV6-VTY-ACL in
!


In IOS-XR it gets a little bit tricky.
One ACL for IPv4 and one ACL for IPv6, which must share the same name.

! IOS-XR
!-------
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny   ipv4 any any log
!
ipv6 access-list VTY-ACL
 10 permit ipv6 2001:DB8::/32 any
 20 deny   ipv6 any any log
!
vty-pool default 0 10
line default
 access-class ingress VTY-ACL
!


Ok, then you think that this is good because it saves you typing.
So you expect to meet the same behavior when viewing the ACLs. Bad Luck. You still have to use the "ipv6" keyword in order to view the ipv6 ACL.



RP/0/RSP0/CPU0:ASR#sh access-lists VTY-ACL
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny ipv4 any any log

RP/0/RSP0/CPU0:ASR#sh access-lists ipv4 VTY-ACL
ipv4 access-list VTY-ACL
 10 permit ipv4 10.0.0.0 0.0.0.255 any
 20 deny ipv4 any any log

RP/0/RSP0/CPU0:ASR#sh access-lists ipv6 VTY-ACL
ipv6 access-list VTY-ACL
 10 permit ipv6 2001:DB8::/32 any
 20 deny ipv6 any any log

Read More

Finding Peer IPv6 Address of A PPPoE Subscriber

n the IPv4 world you could very easily do the following on a BRAS/BNG, find the subscriber's IPv4 address and ping it.

bbras#sh users | i test
  Vi4          test PPPoVPDN     00:01:42 10.11.12.13
bbras#p 10.11.12.13

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.11.12.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/24 ms

Although ping wouldn't always work, in many cases (especially under a managed CPE environment), ping was an easy way to verify subscriber's connectivity, something that is useful for the call-center or 1st level support. Besides checking basic connectivity, using just a single command (as the one shown above, or the ones shown below) you could easily (or with a little bit of text searching) find the IPv4 address of a subscriber.

bbras#sh caller user test

  User: test, line Vi4, service PPPoVPDN
        Connected for 1d05h, Idle for 00:01:54
  Timeouts:    Limit     Remaining Timer Type
               01:00:00  00:58:05  PPP idle
  PPP: LCP Open, multilink Closed, PAP (<-), IPCP, IPV6CP
  IP: Local 10.10.10.10, remote 10.11.12.13
      Access list (I/O) is 120/not set
  Counts: 27378 packets input, 534558 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          13703 packets output, 280432 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets

bbras#sh ip int virtual-access 4
Virtual-Access4 is up, line protocol is up
  Interface is unnumbered. Using address of Loopback0 (10.10.10.10)
  Broadcast address is 255.255.255.255
  Peer address is 10.11.12.13

bbras#sh ppp int virtual-Access 4
PPP Serial Context Info
-------------------
Interface        : Vi4
PPP Serial Handle: 0x0
PPP Handle       : 0x0
SSS Handle       : 0x0
AAA ID           : 0
Access IE        : 0x0
SHDB Handle      : 0x0
State            : Down
Last State       : Init
Last Event       : None

PPP Session Info
----------------
Interface        : Vi4
PPP ID           : 0xC600001D
Phase            : UP
Stage            : Local Termination
Peer Name        : test
Peer Address     : 10.11.12.13
Control Protocols: LCP[Open] PAP+ IPCP[Open]
Session ID       : 29
AAA Unique ID    : 59
SSS Manager ID   : 0x3B
SIP ID           : 0x4F00003A
PPP_IN_USE       : 0x11

Vi4 LCP: [Open]
Our Negotiated Options
Vi4 LCP:    AuthProto PAP (0x0304C023)
Vi4 LCP:    MagicNumber 0x547CCD04 (0x0506547CCD04)
Vi4 LCP:    EndpointDisc 1 bbras
Vi4 LCP:    (0x13130162627261732D6C6C752D6B6C6E)
Vi4 LCP:    (0x2D3331)
Our Rejected options
  MRRU
Peer's Negotiated Options
Vi4 LCP:    MagicNumber 0x3DB09C3A (0x05063DB09C3A)

Vi4 IPCP: [Open]
Our Negotiated Options
Vi4 IPCP:    Address 10.10.10.10 (0x0306C2DBE763)
Peer's Negotiated Options
Vi4 IPCP:    Address 10.11.12.13 (0x0306C2DB711D)
Vi4 IPCP:    PrimaryDNS 10.1.1.1 (0x8106C15C9603)
Vi4 IPCP:    SecondaryDNS 10.2.2.2 (0x8306C15C030B)

Now, in the IPv6 world, you can have quite a few of IPv6 "addresses" on the CPE (link-local address, SLAAC/DHCPv6 prefix/addresses for the WAN, DHCPv6-PD prefix/addresses for the LAN) and very limited info on the BRAS/BNG, that actually there is no easy way to do something similar.

First of all, there isn't any "show ipv6 users" command. And if there was one, which IPv6 address should it display there?

Secondly, although in 99% of the cases you can set the Framed-Interface-Id per user, this doesn't mean it will be honored. The problem with Framed-Interface-Id is that it is used as a hint to the peer, so you cannot always depend on your own being used at the end. Btw, Broadband Forum TR-187 R-32 proposes to have the BRAS/BNG decline the tentative Interface-Id received from CPE in case a Framed-Interface-Id from Radius is being used.

In any case, a manual concatenation of the prefix + Id would produce the asked IPv6 addresses.

Read More