Showing posts with label LSPs. Show all posts
Showing posts with label LSPs. Show all posts

Thursday, February 6, 2014

NTS: IS-IS

IS-IS




IS-IS (Intermediate System to Intermediate System) is defined in ISO 10589 and in  RFC 1142 and RFC 1195.
IS-IS Multi-Instance is defined in RFC 6822.



IS-IS PDU types
  • LAN Hello
  • Serial (Point-to-Point) Hello
  • Link State PDU (LSP)
  • Complete Sequence Number PDU (CSNP)
  • Partial Sequence Number PDU (PSNP)

IS-IS LSPs are like OSPF LSAs.

CSNPs are generated:
  • by the DIS in order for all routers connected to the LAN to synchronize their databases 
  • by routers on a point-to-point network while setting up their adjacency

PSNPs are generated:
  • by routers that are not synchronized with the DIS and need additional LSPs in their database
  • by routers on a point-to-point network to acknowledge received LSPs



ISIS Hellos
  • Point-to-Point
    • Serial IIH are exchanged
  • Multiacces/Broadcast
    • L2 LAN IIH are exchanged

If you get error messages like "%CLNS-3-BADPACKET: ISIS: P2P hello, bad circuit type 0" on point-to-point (Serial/POS) interfaces on GNS3, then just ignore them.

The default hello interval is 10 seconds for non-DIS interfaces, and 3.333 seconds for DIS interfaces.

The hello timers do not need to agree on the neighbors.

On point-to-point links where a single Hello is used, a single hello timer must be used for both L1 and L2 adjacencies.
 
The fastest neighbor down detection with hello timers tuning is 1 sec, if "isis hello-interval minimal" is used. For faster detection use BFD.

All hellos are padded to the full interface MTU by default. You can disable this behavior with "no isis hello padding" (although Cisco routers always send the first five hellos padded), if you are having time-sensitive application traffic that travels across low-bandwidth interfaces or you want to minimize interface buffer resources when frequent hellos are configured.



ISIS vs CLNS
  • Use "sh clns" commands to view
    • neighbors
    • adjacencies 
    • hellos
    • PDUs
    • interfaces
    • metrics
  • Use "sh isis" commands to view
    • neighbors
    • LSPs
    • topologies
    • SPF logs
    • routes

In IOS-XR, all related show commands are found under the "sh isis" hierarchy.
If you need to change the MTU for ISIS to work, change the CLNS MTU.

ISIS over Frame-Relay requires CLNS broadcast mapping for the particular DLCI.



NET

NET = AREA-ID + SYSTEM-ID + SEL

net = 49.0001.0000.0000.2222.00

AREA-ID = 49.0001 (used for inter-area routing)
SYSTEM-ID = 0000.0000.2222 (used for intra-area routing)
SEL = 00


NET must begin and end with a single octet.

Cisco IS-IS implementation requires a 6-octets System-ID.

In order to ease with area migration, multiple Area-IDs can be configured on each router (System-ID must be kept the same).

IOS
router isis
 max-area-addresses 5
 net 49.0001.0000.0000.0002.00
 net 49.0002.0000.0000.0002.00
 net 49.0003.0000.0000.0002.00
 net 49.0004.0000.0000.0002.00
 net 49.0005.0000.0000.0002.00



In L1 adjacencies, max-area-addresses must match between neighbors.


Dynamic hostname exchange is by default enabled, but you can disable it if required.

IOS
router isis
 no hostname dynamic


IOS-XR
router isis 1
 hostname dynamic disable

before...

IOS
R2#sh isis neighbors

System Id      Type Interface   IP Address      State Holdtime Circuit Id
R1             L2   Fa1/0       10.1.2.1        UP    25       R2.03           


after...

IOS
R2#sh isis neighbors

System Id      Type Interface   IP Address      State Holdtime Circuit Id
0000.0000.0001 L2   Fa1/0       10.1.2.1        UP    23       0000.0000.0002.03


R2#sh isis hostname
Level  System ID      Dynamic Hostname  (notag)
 2     0000.0000.0001 R1
     * 0000.0000.0002 R2




Configuration

IOS
router isis X
 net 49.0001.0000.0000.2222.00
 is-type level-2-only
 passive-interface Loopback0

!
interface X

 ip router isis


IOS-XR
router isis X
 is-type level-2-only
 net 49.0001.0000.0000.1111.00
 interface Loopback0

  passive
  address-family ipv4 unicast
  !
 interface X
  circuit-type level-2-only
  address-family ipv4 unicast



Although it's not required to use an IS-IS process/instance number ("router isis x") in IOS, it's better to use one as a reference in next tasks. IOS-XR requires a process ID.

"isis circuit-type level-2-only" under all interfaces creates an empty local L1 database.
"is-type level-2-only" under the IS-IS process doesn't create a L1 database at all.

"passive-interface X" under the IS-IS process doesn't require "ip router isis" under the interface in IOS, because the interface is automatically advertised. IOS-XR requires the whole config (address-family, circuit-type, passive) under each interface.

"log-adjacency-changes" in IOS or "log adjacency changes" in IOS-XR is not enabled by default under the IS-IS process.

For L1 adjacencies a common area (Area-ID) must be used between neighbors.

It is recommended that routers operating at a single level be configured specifically at that level in order to minimize the number of adjacencies, LSPs, and related SPF/PRC calculations.



Multi-area IS-IS

You can have multiple L1 area processes per router, but only one L2 area process. Interfaces can belong to only one process.

That way you can also have connectivity between different L1 areas that are connected to the same L1/L2 router.


IOS
router isis 1
 net 49.0001.0000.0000.0003.00
!
router isis 11
 net 49.0011.0000.0000.0003.00

 is-type level-1
!

interface FastEthernet0/0.1
 ip router isis 1

!
interface FastEthernet0/0.11

 ip router isis 11


You might hit a bug in some releases with the following message appearing when trying to activate the L1 process under an interface.
%CLNS: Duplicate system ID configured in ip vrf <default> with router isis null



Routing table per router type & route-leaking
  • L1 routers have
    • L1 routes for prefixes originating from L1 routers in the same area (even crossing many L2 routers)
    • L1 route for the default route originating from L1/L2 routers
  • L1/L2 routers have
    • L1 routes for prefixes originating from "attached" L1 routers
    • L2 routes for all other prefixes
  • L2 routers have
    • L2 routes for all prefixes

When using multiple Area-IDs under the same IS-IS process of a L1/L2 router, then L1 routes from one L1 area can pass over to another L1 area.

Use route-leaking in L1/L2 routers in order to change the above. Route-leaking can be accomplished either with distribute-list or with a route-map in IOS.

IOS
router isis
 redistribute isis ip level-2 into level-1 distribute-list 100
!
 address-family ipv6
  redistribute isis level-2 into level-1 distribute-list PREFIXLIST

 exit-address-family
!
access-list 100 permit ip host 1.1.1.1 host 255.255.255.255
!
ipv6 prefix-list PREFIXLIST permit 2001:1::1/128
 

IPv4 distribute-list used in route-leaking should have the above "awkward" format in order to allow only 1.1.1.1/32 to be leaked.

When doing route-leaking in IOS, you must define the ISIS process/instance right after the "redistribute isis" command, although you might not see it in the actual configuration.


IOS-XR
router isis X
 address-family ipv4
  propagate level 2 into level 1 route-policy IPv4-RPL
 address-family ipv6
  propagate level 2 into level 1 route-policy IPv6-RPL


Leaked L2=>L1 routes appear as "ia" (inter-area) in L1 routers.

L1 routes are always preferred over L2.

Level-2 subdomain must not be partitioned in order for routing to work properly.

Always prefer to have a flat L2 network if possible.

Default admin distance of IS-IS is 115.

When a L1/L2 router advertises a route from L2 to L1, it sets the U/D bit, so any other L1/L2 router that receives this L1 LSP with the U/D bit set can ignore it and not advertise it any further.

It's good practice to also enable wide metrics when doing route-leaking in order to get "correct" metrics for the leaked routes.


Links



Default Route & ATT bit

An LSP with the ATT bit set, creates a default route in the L1 router. More specifically, a L1/L2 router sets the ATT bit in a L1 LSP when it has connectivity to another L1 area too.

The ATT bit can be managed in various ways:

IOS
router isis X
 set-attached-bit route-map NODEF-ROUTEMAP
!
route-map NODEF-ROUTEMAP permit 10
 match clns address CLNS-FILTER-SET
!
clns filter-set CLNS-FILTER-SET permit 99.9999


Use a non-existent CLNS area if you want to avoid setting the ATT-bit.


IOS-XR
CRS(config-isis-af)#attached-bit receive ?
  ignore  Ignore the attached bit in received LSPs

CRS(config-isis-af)#attached-bit send ?
  always-set  Always set the attached bit in our LSP
  never-set   Never set the attached bit our LSP



Beware of cases where L1/L2 router connects to multiple L1 areas and somehow loses L2 connectivity. Continuing to advertise a default route to L1 routers might lead to a blackhole.

You can also advertise a default route from a L2 router into a L1 router, by using the following configuration:

IOS
router isis X
 default-information originate route-map DEF-ROUTE-ROUTEMAP
!
route-map DEF-ROUTE-ROUTEMAP permit 10
 set level level-1


The default route will be advertised to the L1 router, so you end up with 2 default routes (the second one is created automatically from the LSP that has the ATT bit set, but has lower preference).

IOS
R2#sh isis rib 0.0.0.0 0.0.0.0

IPv4 local RIB for IS-IS process 1000

IPV4 unicast topology base (TID 0, TOPOID 0x0) =================

0.0.0.0/0
  [115/L1/10] via 10.0.220.20(FastEthernet0/0.220), from 10.0.220.20, tag 0, LSP[12/12]
  [115/L1/10] via 10.0.220.20(FastEthernet0/0.220), from 10.0.220.20, tag 0, LSP[0/28]


Remember to filter it from other L1/L2 adjacencies (if such a need arises).


IOS-XR
router isis X
 address-family ipv4 unicast
  default-information originate route-policy
DEF-ROUTE-RPL




DR/DIS

LSPID "router.XX-00" (with next-to-last octet being non-zero) is being sent by a DIS, while LSPID "router.00-00" is being sent by everyone.

IOS
R2#sh isis database

IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R2.00-00            * 0x00000015   0xE041        1184              0/0/0
R2.01-00            * 0x00000006   0xFA3B        380               0/0/0
R8.00-00              0x0000000B   0x4F55        1177              0/0/0
R8.09-00              0x00000001   0x5E58        1177              0/0/0
R9.00-00              0x0000000E   0x7C35        806               0/0/0



If the Circuit-Id in the "sh isis neighbors" output contains a router name (Circuit-ID+System-ID=LAN-ID), then this router is the DIS in the broadcast connection between the local router and the router shown under the System-Id.

IOS
R2#sh isis neighbors

Tag null:
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R7             L1   Et0/2       2.2.27.7        UP    8        R7.04          
R8             L1   Et0/1       2.2.28.8        UP    7        R8.01          
R9             L1   Et0/0       2.2.29.9        UP    9        R9.03         
 


Each router generates an LSP for all its interfaces.

Each DIS generates a Pseudo-Node LSP for its attached broadcast interfaces.

DR/DIS election
  • highest priority (0-127)
  • highest mac address
Setting priority to 0 doesn't disable DIS election; use point-to-point to disable it.

There can be separate DRs for L1 and L2 adjacencies.

There is no backup DR. If the primary DR fails, a new DR is elected.

DR preemption is enabled by default.



"sh isis rib" in IOS will accept only a network prefix as input, but it will return all routes for the classful network. Always use a network mask to get the output for a specific route.

The "*" in front of a prefix in the "sh isis ipv6 rib" output means that the specific route will be installed in the router RIB also (not including directly connected networks).



Overload-bit

The overload bit is included in an LSP of the router and if it is set, it notifies routers in the area that the router is not available for transit traffic. It may be configured and cleared independently for IPv4 and IPv6 topologies.

IOS
router isis
 set-overload-bit



IOS-XR
router isis 100
 set-overload-bit



When used in combination with "wait-for-bgp", then if BGP sessions come up and BGP keepalives are not received from all the BGP neighbors, IS-IS will disable the overload bit after 10 minutes by default.

The IS-IS overload bit avoidance when activated, allows TE LSPs to continue working, although the router in that path has its overload bit set.

IOS
R1(config)#mpls traffic-eng path-selection overload allow ?
  head    Allow overloaded head node in TE CSPF
  middle  Allow overloaded middle node in TE CSPF
  tail    Allow overloaded tail node in TE CSPF



IOS-XR
mpls traffic-eng path-selection ignore overload

CRS(config)#mpls traffic-eng path-selection ignore overload ?
  head  Ignore overload node during CSPF for role head
  mid   Ignore overload node during CSPF for role mid
  tail  Ignore overload node during CSPF for role tail
  <cr>





Metrics

Default metric is 10 for each interface, 0 for passive interfaces.

IOS
R2(config-if)#isis metric ?
  <1-16777214>  Default metric
  maximum       Maximum metric. All routers will exclude this link from their
                SPF


IOS-XR
GSR(config-isis-if-af)#metric ?
  <1-16777214>  Default metric: <1-63> for narrow, <1-16777214> for wide
  maximum       Maximum wide metric. All routers will exclude this link from the
ir SPF



Wide metrics are used in:
  • MPLS-TE
  • prefix tags
  • multi-topology
  • need for metric > 63

IOS
router isis
 metric-style wide



IOS-XR
router isis 100
 address-family ipv4 unicast
  metric-style wide
 !
 address-family ipv6 unicast
  metric-style wide


If two connected routers have different metric styles, an adjacency will be formed between them and LSPs will be exchanged, but routes will not be installed. You can use "debug isis rib local" to verify if routes are being generated for use by the RIB.

The maximum metric that can be assigned to an IS-IS route is 1023 (without wide metrics enabled).



IS-IS Authentication

Authentication can be enabled:
  • per domain (old style)
    • "domain-password" under IS-IS process
    • applies to LSPs by default
    • for CSNPs, PSNPs extra command is required
    • for Level-2 only
    • clear text (type-1)
    • adjacency formed but no L2 LSPs exchanged if wrong authentication
  • per area (old style)
    • "area-password" under IS-IS process
    • applies to LSPs by default
    • for CSNPs, PSNPs extra command is required
    • for Level-1 only
    • clear text (type-1)
    • adjacency formed but no L1 LSPs exchanged if wrong authentication
  • per interface (old style)
    • "isis-password" under interface
    • applies to Hellos by default 
    • for Level-1/Level-2 
    • clear text (type-1)
    • no adjacency formed if wrong authentication
  • per interface (new style)
    • "isis authentication" under interface (IOS)
    • "hello-password" under interface under IS-IS process (IOS-XR)
    • applies to Hellos by default
    • for Level-1/Level-2
    • enhanced clear text (type-1) or MD5 (type-54)
    • no adjacency formed if wrong authentication
  • per instance (new style)
    • "authentication" under IS-IS process (IOS)
    • "lsp-password" under IS-IS process (IOS-XR)
    • applies to LSPs, CSNPs, PSNPs by default
    • for Level-1/Level-2
    • enhanced clear text (type-1) or MD5 (type-54)
    • adjacency formed but no LSPs exchanged if wrong authentication
Prefer to use the new way of authentication, when not told otherwise.

You can use "text" in new-style authentication in order to be compatible with old-style authentication.
For old-style area authentication you have to use "level-1" in new-style, while for old-style domain authentication you have to use "level-2" in new-style.

On point-to-point links where a single Hello is used, a common password must be used for both L1 and L2 adjacencies.


IOS
interface FastEthernet0/0
 isis authentication mode md5
 isis authentication key-chain KEYCHAIN
!

key chain KEYCHAIN
 key 1
  key-string TESTPASS


IOS-XR
router isis 26
 interface X
  hello-password hmac-md5 TESTPASS



In IOS-XR, a key-chain can also be used instead of hmac-md5.

The only way to verify authentication in current releases is by using debug commands ("debug isis update-packets" and "debug isis authentication information").



IS-IS Topologies

  • IOS
    • default is single-topology
    • configure "multi-topology" under ipv6 address-family to change
  • IOS-XR
    • default is multi-topology
    • configure "single-topology" under ipv6 address-family to change
In order to allow adjacency to be formed in mismatched address-families in single-topology, the "no adjacency-check" command must be configured under the IPv6 address family. The same command is enabled by default in multi-topology.

Only one IPv6 process is allowed in IOS.

IS-IS Single-Topology requirements
  • Both IPv4 IS-IS and IPv6 IS-IS routing protocols must share a common network topology
  • Any interface configured for IPv4 IS-IS must also be configured for IPv6 IS-IS, and vice versa
  • All routers in the IS-IS area (for Level 1 routing) or the domain (for Level 2 routing) must support an identical set of address families (IPv4 only, IPv6 only, or both IPv4 and IPv6) on all interfaces
  • Wide metrics are not necessary in single-topology

Links



ISIS as PE-CE


PE

IOS
router isis X
 vrf VPN
 net 49.0001.0000.0000.0001.00

!
interface FastEthernet0/0
 vrf forwarding VPN
 ip router isis X


IOS-XR
not supported


CE

IOS
router isis X
 net 49.0001.0000.0000.0002.00


IOS-XR
router isis X
 net 49.0001.0000.0000.0002.00



IS-IS for IPv6 is not supported as a PE-CE protocol in IOS.

IOS-XR doesn't support IS-IS as a PE-CE protocol at the role of PE.




Multi-Instance


IOS-XR
router isis 1
 is-type level-2
 net 47.0002.0000.0000.0008.00
 address-family ipv4 unicast
  metric-style wide
 !
 address-family ipv6 unicast
  metric-style wide
 !
 interface GigabitEthernet0/2/2/0
  address-family ipv4 unicast
  address-family ipv6 unicast
!
router isis 2
 is-type level-2

 net 49.0002.0000.0000.0008.00
 address-family ipv4 unicast
  metric-style wide
 !
 address-family ipv6 unicast
  metric-style wide
 !
 interface GigabitEthernet0/2/1/0
  address-family ipv4 unicast
  address-family ipv6 unicast



You can configure up to five IS-IS instances (processes).

MPLS can run on multiple IS-IS processes as long as the processes run on different sets of interfaces. Each interface may be associated with only a single IS-IS instance.

Because RIB treats each of the IS-IS instances as equal routing clients, you must be careful when redistributing routes between IS-IS instances.

The RIB does not know to prefer Level 1 routes over Level 2 routes from different instances, so if you are running Level 1 and Level 2 instances, you must enforce the preference by configuring different administrative distances for these two instances.


multi-instance vs multi-area
  • multi-instance
    • supported in IOS-XR
    • multiple L2 areas
    • multiple L1 areas
    • redistribution allowed between different processes
    • multiple IPv6 processes allowed
    • use when: run multiple IS-IS processes
  • multi-area
    • supported in IOS
    • only one L2 area
    • multiple L1 areas
    • redistribution not allowed between different processes
    • only one IPv6 process allowed
    • use when: connect multiple L1 areas on the same router



Fast Convergence

  • BFD
  • tunning of hellos
  • ip event dampening
  • point-to-point adjacencies
  • tuning of SPF/PRC/LSP timers
  • tag specific prefixes and give them high priority

Timers

  • per process/instance
    • LSP refresh interval
      • seconds the router will wait before refreshing (re-creating and re-flooding) its own LSPs
      • recommended: 65535 sec 
    • Max LSP lifetime
      • the lifetime in the LSP header (in order to age out old LSPs)
      • recommended: 65535 sec
    • PRC interval (exponential backoff)
      • seconds between two consecutive PRCs (triggered when changes that do not affect the topology, such as advertised external prefixes or metric changes, are detected)
      • recommended: 5, 1, 20
    • LSP generation interval (exponential backoff)
      • seconds between creating new versions of a given LSP on a per-node basis
      • recommended: 5, 1, 20
    • SPF interval (exponential backoff)
      • seconds between two consecutive SPF calculations
      • recommended: 5, 1, 20
  • per interface
    • LSP interval
      • milliseconds between the transmission of LSPs
    • LSP retransmit interval
      • seconds between the retransmission of an LSP on point-to-point links
    •  LSP retransmit throttle interval
      • milliseconds between all the retransmitted LSPs on point-to-point links

The value set for the lsp-refresh-interval should be less than the value of the max-lsp-lifetime command. Usually the software will automatically reduce the LSP refresh interval to prevent the LSPs from timing out. 

iSFP can be used to limit the SPF recalculations to specific portions of the topology.



Advertise minimum prefixes


IOS
router isis
 advertise passive-only
 set-overload-bit suppress interlevel external
!
interface X
 no isis advertise prefix


IOS-XR
router isis 100
 no set-overload-bit advertise external interlevel
 address-family ipv4 unicast
  advertise passive-only
 !
 interface X
  suppressed





Summarization


IOS
router isis
 summary-address 11.11.11.0 255.255.255.0
 address-family ipv6
  summary-prefix 11:11:11::/64




IOS-XR
router isis 1
 address-family ipv4 unicast
  summary-prefix 11.11.11.0/24
 !
 address-family ipv6 unicast
  summary-prefix 11:11:11::/64



You can also define the level into which you want to advertise the summary.



NTS: Inter-AS MPLS L3VPN

Inter-AS MPLS L3VPN




Inter-AS MPLS L3VPN Options are defined in RFC 4364.



Inter-AS Options
  • Inter-AS Option A (Back-to-Back VRF)
    • one logical/physical interface per VRF in the interconnection
    • one PE-CE eBGP/IGP session per VRF between ASBRs
    • IP traffic between ASBRs
    • no need for common RDs/RTs between ASNs 
    • 2 LSPs and 1 IP path from one PE to the other PE
  • Inter-AS Option B (MP-eBGP between ASBRs)
    • one physical/logical interface for all VRFs in the interconnection
    • eBGP VPNv4 between ASBRs
    • MPLS traffic between ASBRs
    • common RDs/RTs between ASNs (unless RT rewrite is used)
    • next-hop-self on each ASBR for iBGP
      • 3 LSPs from one PE to the other PE
    • redistribute connected/static on each ASBR for the interconnection
      • 2 LSPs from one PE to the other PE
      • filter to redistribute only the peer's address
    • multihop (loopback) peering between ASBRs
      • 2 LSPs from one PE to the other PE
      • static routes for peer's loopback on each ASBR
      • LDP between ASBRs
      • MPLS static label binding for peer's loopback pointing to interconnection on each ASBR
  • Inter-AS Option C (Multihop MP-eBGP between RRs/PEs)
    • one physical/logical interface for all VRFs in the interconnection
    • labeled eBGP session between ASBRs for next-hop exchange
    • multihop eBGP VPNv4 session between RRs
    • MPLS traffic between ASBRs
    • common RDs/RTs between ASNs (unless RT rewrite is used) 
    • change next-hop on each VPNv4 RR for the eBGP session (default)
      • 2 LSPs from one PE to the other PE
    • next-hop-unchanged on each VPNv4 RR for the eBGP session
      • 1 LSP from one PE to the other PE
    • eBGP session between ASBRs with directly connected interfaces
      • next-hop-self on each ASBR for the iBGP sessions
    • multihop (loopback) eBGP session between ASBRs with loopbacks
      • static routes for peer's loopback on each ASBR
      • LDP between ASBRs
      • MPLS static label binding for peer's loopback pointing to interconnection on each ASBR

The transport label changes whenever the next-hop changes.



Inter-AS Option A

ASBR-1

IOS
ip vrf VPN1
 rd 1:100
 route-target 1:100
!
ip vrf VPN2
 rd 1:200
 route-target 1:200
!
interface FastEthernet0/0
 description ** Inter-AS NNI **
!
interface FastEthernet0/0.10
 description ** Customer VPN1 **
 encapsulation dot1q 10
 ip vrf forwarding VPN1
 ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet0/0.20
 description ** Customer VPN2 **
 encapsulation dot1q 20
 ip vrf forwarding VPN2
 ip address 20.20.20.1 255.255.255.0
!
router bgp 1
 neighbor 1.1.1.1 remote-as 1

 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 description iBGP-VPNv4
!
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 1.1.1.1 next-hop-self
 exit-address-family
!
 address-family ipv4 vrf VPN1
  neighbor 10.10.10.2 remote-as 2
  neighbor 10.10.10.2 activate
 exit-address-family
!
 address-family ipv4 vrf VPN2
  neighbor 20.20.20.2 remote-as 2
  neighbor 20.20.20.2 activate
 exit-address-family



ASBR-2

IOS
ip vrf test1
 rd 2:100
 route-target 2:100
!
ip vrf test2
 rd 2:200
 route-target 2:200
!
interface FastEthernet0/0
 description ** Inter-AS NNI **
!
interface FastEthernet0/0.10
 description ** Customer VPN1 **
 encapsulation dot1q 10
 ip vrf forwarding VPN1
 ip address 10.10.10.2 255.255.255.0
!
interface FastEthernet0/0.20
 description ** Customer VPN2 **
 encapsulation dot1q 20
 ip vrf forwarding VPN2
 ip address 20.20.20.2 255.255.255.0
!
router bgp 2
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 description iBGP-VPNv4
!
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 next-hop-self
 exit-address-family
!
 address-family ipv4 vrf VPN1
  neighbor 10.10.10.1 remote-as 1
  neighbor 10.10.10.1 activate
 exit-address-family
!
 address-family ipv4 vrf VPN2
  neighbor 20.20.20.1 remote-as 1
  neighbor 20.20.20.1 activate
 exit-address-family



You can also use a different router-id per VRF, using the "bgp router-id" under each vrf address-family.



Inter-AS Option B

ASBR-1

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address
x.x.x.x
 mpls bgp forwarding
!
router bgp 1
 no bgp default route-target filter
 neighbor
PE-1 remote-as 1
 neighbor
PE-1 update-source Loopback0
 neighbor
PE-1 description MP-iBGP with PE-1
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 description MP-eBGP with ASBR-2
 no auto-summary
!
 address-family vpnv4
  neighbor PE-1 activate
  neighbor
PE-1 send-community extended
  neighbor
PE-1 next-hop-self
  neighbor
ASBR-2 activate
  neighbor
ASBR-2 send-community extended
 exit-address-family



ASBR-2

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address
x.x.x.x
 mpls bgp forwarding
!
router bgp 2
 no bgp default route-target filter
 neighbor PE-2 remote-as 2
 neighbor
PE-2 update-source Loopback0
 neighbor
PE-2 description MP-iBGP with PE-2
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 description MP-eBGP with ASBR-1
!
 address-family vpnv4
  neighbor PE-2 activate
  neighbor
PE-2 send-community extended
  neighbor
PE-2 next-hop-self
  neighbor
ASBR-1 activate
  neighbor
ASBR-1 send-community extended
 exit-address-family





Inter-AS Option C

RR-1

IOS
router bgp 1
 no synchronization
 neighbor PE-1 remote-as 1
 neighbor
PE-1 update-source Loopback0
 neighbor
PE-1 description MP-iBGP with PE-1
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 update-source Loopback0
 neighbor
ASBR-1 description MP-iBGP with ASBR-1
 neighbor RR-2 remote-as 2
 neighbor RR-2 ebgp-multihop 255
 neighbor RR-2 update-source Loopback0
 neighbor RR-2 description MP-eBGP with RR-2
 no auto-summary
!
 address-family vpnv4
  neighbor
PE-1 activate
  neighbor
PE-1 send-community extended
  neighbor
PE-1 route-reflector-client
  neighbor ASBR-1 activate
  neighbor
ASBR-1 send-community extended
  neighbor
ASBR-1 route-reflector-client
  neighbor RR-2 activate
  neighbor RR-2 send-community extended
  neighbor RR-2 next-hop-unchanged
  exit-address-family



ASBR-1

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address x.x.x.x
 mpls bgp forwarding
!

route-map PE2-TO-IGP permit 10
 match ip address
PE-2

!
router IGP 100
 redistribute bgp 1 route-map PE2-TO-IGP
!
router bgp 1
 no synchronization
 network PE-1 mask 255.255.255.255
!
 neighbor RR-1 remote-as 1
 neighbor
RR-1 update-source Loopback0
 neighbor
RR-1 description MP-iBGP to RR-1
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 send-label
 Î½eighbor
ASBR-2 description MP-eBGP to ASBR-2
 no auto-summary
!
 address-family vpnv4
  neighbor
RR-1 activate
  neighbor
RR-1 send-community extended
 exit-address-family




ASBR-2

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address x.x.x.x
 mpls bgp forwarding
!

route-map PE1-TO-IGP permit 10
 match ip address PE-1

!
router IGP 200
 redistribute bgp 2 route-map PE1-TO-IGP
!
router bgp 2
 network PE-2 mask 255.255.255.255
!
 neighbor RR-2 remote-as 2
 neighbor
RR-2 update-source Loopback0
 neighbor
RR-2 description MP-iBGP to RR-2
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 send-label
 neighbor
ASBR-1 description MP-eBGP to ASBR-1
!
 address-family vpnv4
  neighbor RR-2 activate
  neighbor RR-2 send-community extended
 exit-address-family




RR-2

IOS
router bgp 2
 neighbor PE-2 remote-as 2
 neighbor PE-2 update-source Loopback0
 neighbor PE-2 description MP-iBGP with PE-2
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 update-source Loopback0
 neighbor
ASBR-2 description MP-iBGP with ASBR-2
 neighbor RR-1 remote-as 1
 neighbor
RR-1 ebgp-multihop 255
 neighbor
RR-1 update-source Loopback0
 neighbor
RR-1 description MP-eBGP with RR-1
!
 address-family vpnv4
  neighbor PE-2 activate
  neighbor
PE-2 send-community extended
  neighbor
PE-2 route-reflector-client
  neighbor ASBR-2 activate
  neighbor
ASBR-2 send-community extended
  neighbor
ASBR-2 route-reflector-client
  neighbor RR-1 activate
  neighbor
RR-1 send-community extended
  neighbor
RR-1 next-hop-unchanged
 exit-address-family





In IOS-XR, in order to send IPv4 prefixes with labels over a labeled BGP session, the IOS-XR router must be the originator of the prefixes. On the other hand, an IOS router can send labeled IPv4 prefixes over a labeled BGP session whether it's the originator or not of those prefixes.

If an output route-map is applied on a labeled BGP session, then labels will be added only to those prefixes that have the command "set mpls-label" under the relevant statement in the route-map. Generally, if a router is advertising IPv4 prefixes with labels, then you can use an output route-map (with the "set mpls-label" command) to specify which prefixes will be sent with a label.

You need to disable the default RT filter from the ASBRs, unless they have all the VRFs locally configured or they are VPNv4 RRs.

In most IOS software releases, the command "mpls bgp forwarding" is added automatically under the eBGP peering interface when a VPNv4 or labeled BGP session is configured between directly connected peers. If you use loopbacks for peering, then you must manually configure it. Always verify its existence, together with the interface's mpls operational state.

IOS
R1#sh mpls int
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0.13     Yes (ldp)     No       No  No     Yes
FastEthernet0/0.30     No            No       Yes No     Yes


Generally, Cisco software requires a /32 route for each next-hop that should be label switched. In the Inter-AS B/C options, in IOS-XR you must add manually a /32 static route for the peer address of the interconnection in order to create a label for that. IOS creates automatically a /32 connected route when the relevant VPNv4 or labeled BGP session comes up.

IOS-XR
router static
 address-family ipv4 unicast
  10.10.10.2/32 GigabitEthernet0/2/1/2



IOS
Dec 29 15:45:30.703: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up
Dec 29 15:45:30.707: CONN: add connected route, idb: FastEthernet0/0.30, addr: 10.10.10.2, mask: 255.255.255.255



If you want to achieve load-sharing in a MPLS L3VPN environment with RRs, you can use a different RD per PE in combination with BGP multipath.

Inter-AS scenarios emulated in GNS3 might sometimes cause very large delays in data forwarding. Increase the ping/traceroute timeout in order to verify connectivity.



Static Label Bindings

In some cases you don't have the option of enabling LDP or having a VPNv4 or labeled BGP session between directly connected peers, but you still need to have the label switching functionality on their interconnection.

i.e. if you configure the following static route in order to reach peer's loopback:

IOS
ip route 19.19.19.19 255.255.255.255 12.1.19.19

IOS
R1#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
24         No Label   19.19.19.19/32   0             Fa0/0  12.1.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0417EC0000810000770800
        No output feature configured


then you need to also add a static (outgoing) label binding for that:

IOS
mpls static binding ipv4 19.19.19.19 255.255.255.255 output 12.1.19.19 implicit-null

IOS
R1#sh mpls static binding
19.19.19.19/32: Incoming label: none;
  Outgoing labels:
     12.1.19.19           implicit-null


R1#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
24         Pop Label  19.19.19.19/32   0             Fa0/0  12.1.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0417EC0000810000770800
        No output feature configured


At the same time, you must enable MPLS on this interface without using LDP:

IOS
R1#sh mpls int FastEthernet0/0
Interface              IP            Tunnel   BGP Static Operational

IOS
interface FastEthernet0/0
 mpls bgp forwarding

IOS
R1#sh mpls int FastEthernet0/0
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        No            No       Yes No     Yes



Static Label Bindings per Interface

  • multiaccess interfaces
    • next-hop ip address required
    • label required
  • point-to-point interfaces
    • interface required

The above differentiation per interface is applicable only on specific software releases. The multiaccess interface is the common one.

If you must configure specific static labels, then you must first define the label range (which will sometimes require a reload).

Implicit-null is used in the above example due to PHP (pop label) that must happen for the directly connected peer.



Inter-AS L3VPN

If you want to follow a Inter-AS L3VPN path (assuming control-plane has been setup correctly), then you can execute the following algorithm:
  • first router (start PE)
    • Find the VPN label for the prefix
    • Find the Transport label(s) for the prefix's next-hop
  • n router
    • Follow the Transport top label swaps until there is a "Pop Label" for next router
  • n+1 router
    • Find the local VPN label for the prefix
      • If VPN label is "nolabel", then
        • router is the end PE
        • VPN is locally attached
      • If VPN label is other, then
        • router is an RR/ASBR
        • find the Transport label(s) for the prefix's new next-hop
        • go to "n router"
      • If VPN label doesn't exist, then 
        • multiple Transport labels exist
        • go to "n router"

If the route is learned from IGP, the Transport label must be allocated through LDP/RSVP.
If the route is learned from BGP, the Transport label must be allocated through BGP.


Example

R6(PE1)=>R4(P1)=>XR1(ASBR1)=>R1(ASBR2)=>R3(P2)=>R2(PE3)

Start PE

IOS
R6#sh bgp vpnv4 unicast all 7.7.7.7/32
BGP routing table entry for 102:202:7.7.7.7/32, version 36
Paths: (1 available, best #1, table VPN_B)
  Not advertised to any peer
  100
    2.2.2.2 (metric 20) from 20.20.20.20 (20.20.20.20)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:102:202 0x8800:32768:0 0x8801:1:130560
        0x8802:65281:25600 0x8803:65281:1500 0x8806:0:0
      mpls labels in/out nolabel/26


VPN label is 26


IOS
R6#sh mpls forwarding-table 2.2.2.2 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       23         2.2.2.2/32       0             Fa0/0.46   20.4.6.4
        MAC/Encaps=18/26, MRU=1496, Label Stack{16 23}
        CA0611100000CA0115B000008100002E8847 0001000000017000
        No output feature configured


Transport label is 16/23, VPN label is 26



IOS
R4#sh mpls forwarding-table labels 16 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  19.19.19.19/32   18896         Fa0/0.419  20.4.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0611100000810001A38847
        No output feature configured


Transport label is 23, VPN label is 26


IOS

XR1#sh mpls forwarding-table labels 23 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
23         20         2.2.2.2/32       22628         Fa0/0.119  12.1.19.1
        MAC/Encaps=18/22, MRU=1500, Label Stack{20}
        CA0417EC0000CA02141C0008810000778847 00014000
        No output feature configured



Transport label is 20, VPN label is 26


IOS

R1#sh mpls forwarding-table labels 20 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
20         19         2.2.2.2/32       24518         Fa0/0.13   10.1.3.3
        MAC/Encaps=18/22, MRU=1500, Label Stack{19}
        CA0711100000CA0417EC00008100000D8847 00013000
        No output feature configured



Transport label is 19, VPN label is 26



IOS

R3#sh mpls forwarding-table labels 19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         Pop Label  2.2.2.2/32       85693         Fa0/0.23   10.2.3.2
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA0517EC0000CA0711100000810000178847
        No output feature configured



VPN label is 26



IOS

R2#sh bgp vpnv4 unicast all 7.7.7.7/32
BGP routing table entry for 102:202:7.7.7.7/32, version 4
Paths: (1 available, best #1, table VPN_B)
  Advertised to update-groups:
     1
  Local
    40.2.7.7 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 156160, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:102:202 Cost:pre-bestpath:128:156160
        0x8800:32768:0 0x8801:1:130560 0x8802:65281:25600 0x8803:65281:1500
        0x8806:0:0
      mpls labels in/out 26/nolabel


End PE found




RT Rewrite

It is used mainly in Inter-AS topologies, when there is a need to keep different RTs between the ASes. It allows the ASBR (or any other router that's involved) to replace the peer ASN's RTs with their own.

Configuration Steps
  • define the RTs to be replaced
  • configure a route-map that matches the above RTs, deletes them and then adds the new RTs
  • apply the route-map to the bgp neighbor session


IOS
ip extcommunity-list 1 permit rt 200:1
ip extcommunity-list 2 permit rt 200:2
!
route-map RT-REWRITE-ROUTEMAP permit 10
 match extcommunity 1
 set extcomm-list 1 delete
 set extcommunity rt 100:1 additive
 continue 20
!
route-map RT-REWRITE-ROUTEMAP permit 20
 match extcommunity 2
 set extcomm-list 2 delete
 set extcommunity rt 100:2 additive
!
route-map RT-REWRITE-ROUTEMAP permit 30
!
router bgp 100
 neighbor 10.10.10.2 remote-as 200
 !
 address family vpnv4
  neighbor 10.10.10.2 activate
  neighbor 10.10.10.2 send-community extended
  neighbor 10.10.10.2 route-map RT-REWRITE-ROUTEMAP in


Use the "additive" keyword when setting the new RT in order to not erase all other extended communities.

Use the "continue" statement (in ingress route-maps) when you need to rewrite more than one RTs in the same prefix.