Showing posts with label cisco. Show all posts
Showing posts with label cisco. Show all posts

Friday, June 10, 2016

BGP Conditional Advertisement

This BGP feature is able to filter a subnet advertisement based on a certain match (AS-PATH, subnet in the routing table...). In our example below, we can image that AS100 is an ISP1 and AS200 is an ISP2. In most of the case, we monitor only the status of the interface which is directly connected. But in our case, we will monitor the presence of the subnet 20.20.20.0/24 which is advertised by the ISP1.
By default, we only advertise the subnet 50.50.50.0/24 to ISP1 and if the subnet 20.20.20.0/24 disappears, we announce it also to ISP2. We can typically use this feature when ISP2 is more expensive than ISP1.



  • Configuration:

R1:
interface Loopback50
 ip address 50.50.50.50 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.1 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.150.1 255.255.255.0
!
router bgp 50
 network 50.50.50.0 mask 255.255.255.0
 neighbor 192.168.50.2 remote-as 100
 neighbor 192.168.150.3 remote-as 200
 neighbor 192.168.150.3 advertise-map NOT_ANNOUNCE_R3 non-exist-map ADVERTISE
!
ip prefix-list LO20 seq 5 permit 20.20.20.0/24
!
ip prefix-list LO50 seq 5 permit 50.50.50.0/24
!
route-map NOT_ANNOUNCE_R3 permit 10
 match ip address prefix-list LO50
!
route-map ADVERTISE permit 10
 match ip address prefix-list LO20
R2:
interface Loopback20
 ip address 20.20.20.20 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.2 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.100.2 255.255.255.0
!
router bgp 100
 network 20.20.20.0 mask 255.255.255.0
 neighbor 192.168.50.1 remote-as 50
 neighbor 192.168.100.3 remote-as 200
R3:
interface Ethernet0/0
 ip address 192.168.100.3 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.200.3 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.150.3 255.255.255.0
!
router bgp 200
 neighbor 192.168.100.2 remote-as 100
 neighbor 192.168.150.1 remote-as 50


  • Initial behavior:

R3 sees subnet 50.50.50.0/24 only from R3
R3#sho ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *   20.20.20.0/24    192.168.150.1                          0 50 100 i
 *>                   192.168.100.2            0             0 100 i
 *>  50.50.50.0/24    192.168.100.2                          0 100 50 i
We can check that R1 is not advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  20.20.20.0/24    192.168.50.2             0             0 100 i
R1#sho ip bgp neighbors 192.168.50.2 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Withdraw

  • Now the subnet 20.20.20.0/24 is removed from the routing table:

R2#int lo20
shut

We can check that R1 is now advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Advertise
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i

R3#sho ip bgp
BGP table version is 18, local router ID is 192.168.200.3
 *>  50.50.50.0/24    192.168.150.1            0             0 50 i
 *                    192.168.100.2                          0 100 50 i

Monday, May 9, 2016

Simple regular expression Cisco CLI (AND)

This small memo explains just how to use a show command pipe command to get a AND regular expression. For example :
show interface status | inculde textA AND textB

In order to perform this action, you can use this expression:
show  interfaces status | in textA.*textB

Example, show all interface Gi1/2/ which are connected:
show  interfaces status | in Gi1/2/.*connected

Monday, March 14, 2016

BGP MED routing decision - Always-compare-med

MED (Multi-Exit Discriminator) is used to influence routing decision. By default, a router which receives MED attribute from neighbors, only compares it if they are coming from the same AS. As you can see in the diagram below:
  • R3 send to R4 a MED of 50 for subnet 172.16.1.0/24
  • R2 send to R5 a MED of 100 for subnet 172.16.1.0/24
  • The lowest MED is the preferred path

In a first step, the configuration below has been applied:
R1:
interface Loopback1
ip address 172.16.1.1 255.255.255.0
router bgp 50
bgp log-neighbor-changes
network 172.16.1.0 mask 255.255.255.0
neighbor 10.1.1.2 remote-as 100
neighbor 10.1.3.3 remote-as 200
R2:
router bgp 100
bgp log-neighbor-changes
neighbor 10.1.1.1 remote-as 50
neighbor 10.1.2.3 remote-as 200
neighbor 10.1.4.4 remote-as 300
neighbor 10.1.4.4 route-map MED out
!
access-list 1 permit 172.16.1.0 0.0.0.255
!
route-map MED permit 10
match ip address 1
set metric 100
!
route-map MED permit 20
R3:
router bgp 200
bgp log-neighbor-changes
neighbor 10.1.2.2 remote-as 100
neighbor 10.1.3.1 remote-as 50
neighbor 10.1.5.4 remote-as 300
neighbor 10.1.5.4 route-map MED out
!
access-list 1 permit 172.16.1.0 0.0.0.255
!
route-map MED permit 10
match ip address 1
set metric 50
!
route-map MED permit 20
R4:
router bgp 300
bgp log-neighbor-changes
neighbor 10.1.4.2 remote-as 100
neighbor 10.1.5.3 remote-as 200

MED is seen in R4 but R4 set R2 has next-hop. R4 doesn't compare MED because information is coming from 2 different ASs. R2 is used due to the fact that he has the lowest Router-id 10.1.4.2.
R4#sho ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 2
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 1
  100 50
    10.1.4.2 from 10.1.4.2 (10.1.4.2)
      Origin IGP, metric 100, localpref 100, valid, external, best
  Refresh Epoch 1
  200 50
    10.1.5.3 from 10.1.5.3 (10.1.5.3)
      Origin IGP, metric 50, localpref 100, valid, external

Now, we add the command 'bgp always-compare-med' on R4:
R4:
router bgp 300
bgp always-compare-med

As you can, R4 has now choosen R3 for the next-hop. MED is used:
R4#sho ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 2
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     4
  Refresh Epoch 1
  200 50
    10.1.5.3 from 10.1.5.3 (10.1.5.3)
      Origin IGP, metric 50, localpref 100, valid, external, best
  Refresh Epoch 1
  100 50
    10.1.4.2 from 10.1.4.2 (10.1.4.2)
      Origin IGP, metric 100, localpref 100, valid, external

Friday, March 4, 2016

Influence routing decision with BGP Community

You can use community as a flag in order to mark a route. Upstream routers will use these flags to define routing policy. In the schema below, you can image that AS 100 is a customer site and AS 200 is a service provider. We have negotiated with the provider that:

  • Traffic destined to routes with a community 100 have to pass by R3
  • Traffic destined to routes with a community 200 have to pass by R2

In order to realize this, R1 marks routes with a community field, R2 and R3 modify the local_pref to follow the rules aboves.
In our case:
  •  Lo1 will be 'marked' with a community 200:100 by R1
  •  Lo2 will be 'marked' with a community 200:200 by R1
  • Route with a community 200:100 will have a local_pref of 1000 (R3). 
  • Route with a community 200:200 will have a local_pref of 500 (R2).

Configuration

R1:

interface Loopback1
 ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
 ip address 172.16.2.1 255.255.255.0
!
router bgp 100
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.2.0 mask 255.255.255.0
 neighbor 10.1.1.2 remote-as 200
 neighbor 10.1.1.2 send-community
 neighbor 10.1.1.2 route-map Peer-R2 out
 neighbor 10.1.2.3 remote-as 200
 neighbor 10.1.2.3 send-community
 neighbor 10.1.2.3 route-map Peer-R3 out
!
ip access-list standard LO1
 permit 172.16.1.0 0.0.0.255
ip access-list standard LO2
 permit 172.16.2.0 0.0.0.255
!
route-map Peer-R3 permit 10
 match ip address LO2
 set community 200:200
route-map Peer-R3 permit 15
 match ip address LO1
 set community 200:100
!
route-map Peer-R3 permit 20
!
route-map Peer-R2 permit 10
 match ip address LO1
 set community 200:100
!
route-map Peer-R2 permit 15
 match ip address LO2
 set community 200:200
!
route-map Peer-R2 permit 20
R2:
router bgp 200
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 100
 neighbor 10.1.1.1 next-hop-self
 neighbor 10.1.1.1 route-map Peer-R1 in
 neighbor 20.1.1.3 remote-as 200
 neighbor 20.1.1.3 next-hop-self
 neighbor 20.1.2.4 remote-as 200
 neighbor 20.1.2.4 next-hop-self
!
ip bgp-community new-format
ip community-list 1 permit 200:200
!
route-map Peer-R1 permit 10
 match community 1
 set local-preference 500
!
route-map Peer-R1 permit 20
R3:
router bgp 200
 bgp log-neighbor-changes
 neighbor 10.1.2.1 remote-as 100
 neighbor 10.1.2.1 route-map Peer-R1 in
 neighbor 20.1.1.2 remote-as 200
 neighbor 20.1.1.2 next-hop-self
 neighbor 20.1.3.4 remote-as 200
 neighbor 20.1.3.4 next-hop-self
!
ip forward-protocol nd
!
ip bgp-community new-format
ip community-list 1 permit 200:100
!
route-map Peer-R1 permit 10
 match community 1
 set local-preference 1000
!
route-map Peer-R1 permit 20

Validation

Check that routes are flags on R2:
R2#sho ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 6
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  100
    20.1.1.3 from 20.1.1.3 (20.1.3.3)
      Origin IGP, metric 0, localpref 1000, valid, internal, best
  Refresh Epoch 1
  100
    10.1.1.1 from 10.1.1.1 (172.16.2.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 200:100

R2#sho ip bgp 172.16.2.0
BGP routing table entry for 172.16.2.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 1
  100
    10.1.1.1 from 10.1.1.1 (172.16.2.1)
      Origin IGP, metric 0, localpref 500, valid, external, best
      Community: 200:200

Check policies applied by R2 and R3 on R4:
R4#sho ip bgp
BGP table version is 9, local router ID is 20.1.3.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.1.0/24    20.1.3.3                 0   1000      0 100 i
 *>i 172.16.2.0/24    20.1.2.2                 0    500      0 100 i

Friday, February 5, 2016

Example - How to configure Site-to-site VPN with IOS router



  • Router 1 (Left):

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key CISCO address 10.10.20.3
!
!
crypto ipsec transform-set My-Set esp-aes 192 esp-sha-hmac
!
crypto map MyMap 10 ipsec-isakmp
 set peer 10.10.20.3
 set transform-set My-Set
 match address R1_TO_R3
!
interface FastEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 crypto map MyMap
!
interface FastEthernet0/1
 ip address 172.16.1.1 255.255.255.0
!
router ospf 10
 router-id 1.1.1.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
ip access-list extended R1_TO_R3
 permit ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255
  • Router 3 (Right):

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key CISCO address 10.10.10.1
!
!
crypto ipsec transform-set My-Set esp-aes 192 esp-sha-hmac
!
crypto map MyMap 10 ipsec-isakmp
 set peer 10.10.10.1
 set transform-set My-Set
 match address R3_TO_R1
!
interface FastEthernet0/0
 ip address 172.16.3.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.10.20.3 255.255.255.0
 crypto map MyMap
!
router ospf 10
 router-id 3.3.3.3
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
ip access-list extended R3_TO_R1
 permit ip 172.16.3.0 0.0.0.255 172.16.1.0 0.0.0.255

  • Validation:


Router3#show  crypto ipsec sa

interface: FastEthernet0/1
    Crypto map tag: MyMap, local addr 10.10.20.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.3.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
   current_peer 10.10.10.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 3242, #pkts encrypt: 3242, #pkts digest: 3242
    #pkts decaps: 3242, #pkts decrypt: 3242, #pkts verify: 3242
    #pkts compressed: 0, #pkts decompressed: 0


Router3#show  crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.10.10.1      10.10.20.3      QM_IDLE           1002    0 ACTIVE






Monday, January 11, 2016

Command to see all floatings routes

With the classic 'show ip route static', the backup floating route is not seen in the display:

Router#show  ip route static
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 10.10.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.10.2.1

In order to see both routes, active and non-active route, we have to use the command 'show ip static route'. With this command, both routes and metrics are seen:

Router#show ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
       G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface proces
       B - BootP, S - Service selection gateway
       DN - Default Network, T - Tracking object
       L - TL1, E - OER, I - iEdge
       D1 - Dot1x Vlan Network, K - MWAM Route
       PP - PPP default route, MR - MRIPv6, SS - SSLVPN
       H - IPe Host, ID - IPe Domain Broadcast
       U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
       IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Track

Static local RIB for default

M  0.0.0.0/0 [1/0] via 10.10.2.1 [A]
M            [5/0] via 10.10.25.1 [N]

Friday, December 11, 2015

Capture traffic on Cisco switch with EPC (both directions)

Embedded Packet Capture is a powerful tool implemented on certain Cisco devices. With this technology, it's no more mandatory to SPAN traffic in order to capture it. You can capture traffic at differents points of your network with some limitations described in the Cisco documentation.
In my case, I would like capture traffic between 2 machines (only these 2 machines) has described in diagram below:

In order to do this, you can use the following configuration:
ip access-list extended HOST-TO-FILTER
 permit ip host 10.10.10.1 host 10.10.20.1
 permit ip host 10.10.20.1.1 10.10.10.1
!
monitor capture MY-CAPTURE file location flash:mycapture.pcap  size 10 int GigabitEthernet1/0/1 both access-list HOST-TO-FILTER

After that, you can start the capture with the command:
monitor capture MY-CAPTURE start

And stop it:
monitor capture MY-CAPTURE stop


This capture can be export and read with wireshark for example.
!! Warning!!
EPC can consumes CPU and memory. Take care to apply a good filter in order to not overload your router or switch.

Thursday, December 10, 2015

OSPF - Filter redistribution in a Totally NSSA area

In some cases, we can have the ABR which can also be an ASBR. If we are working with a Totally NSSA area we have unnecessary routes. ABR announces a default route and his redistributed routes which are not necessary. In order to solve this case and only announce a default route, we can use the commande below on the ABR:

 area X nssa no-redistribution no-summary

The schema below is anexample of this implementation:



Wednesday, November 4, 2015

Track an IP on your Network

Who has never received the following question from a colleague:
- Hey, the network guy, could you find where is this laptop for me ? I have only his IP address.

To resolve this, you start to follow the IP address by looking in the arp and mac-address table of your switchs, routers and firewall. I have finished this boring job by using the following open source tool:
http://netdbtracking.sourceforge.net/

Developpers have alreay preconfigured a VM:
http://sourceforge.net/projects/netdbtracking/files/vmware/

After 30 minutes of the VM installation and some hours (depending of the size of your network) of configuration to enter your different equipment, you can provide a webtools reachable from everybody to track an IP.

You will find below some examples of host configuration.


  • HP Procurve (Layer 3)

hostname,devtype=procurvehpv2, arp


  • HP Procurve (Layer 2):

On this example, I skipped uplinks interfaces (45 and 47). I have also limited to 2 mac address by interface.
hostname,devtype=procurvehpv2,skip_port=45,skip_port=47,use_trunks,max_macs=2

Tuesday, July 7, 2015

Configure PIM-sparse mode between Cisco and HP Procurve

This post explains how to configure PIM-sparse mode between a Cisco and HP Procurve environment. In our case, we have the following components:
- Cisco2 (Rendez-vous Point)
- Cisco1 (PIM router)
- HP1 (PIM router and IGMP edge router)




  • Configuration

    • Cisco2 (RP):


ip multicast-routing
ip pim rp-address 10.10.30.1 (we can filter group here with an ACL)
!
interface Gi1/0/1
 description *** TO Cisco1 ***
 ip address 10.10.20.2 255.255.255.0
 ip pim sparse-mode
!
interface Vlan100
 description *** VLAN Source ***
 ip address 10.10.30.1 255.255.255.0
 ip pim sparse-mode

    • Cisco1:

ip multicast-routing
ip pim rp-address 10.10.30.1    
!
interface Gi1/0/1
 description *** TO Cisco2 ***
 ip address 10.10.20.1 255.255.255.0
 ip pim sparse-mode
!
interface Gi1/0/1
 description *** TO HP1 ***
 ip address 10.10.10.1 255.255.255.0
 ip pim sparse-mode

    • HP1:


ip multicast-routing
!
router pim
   enable
   rp-address 10.10.30.1 224.0.0.0 240.0.0.0 (we can filter group here)
   exit
!
vlan 316
   name "To Cisco1"
   untagged A1
   ip address 10.10.10.2 255.255.255.0
   ip pim-sparse
      ip-addr any
      exit
!
vlan 200
   name "200-RECEIVER"
   untagged A1
   tagged A13-A15,B20,Trk1
   ip address 10.10.40.1 255.255.255.0
   ip igmp
   ip pim-sparse
      ip-addr any
      exit

  • Validation

Check PIM neighbors adjacency on HP:

HP1# sho ip pim neighbor

 PIM Neighbors

  IP Address      VLAN Up Time (sec)      Expire Time (sec)
  --------------- ---- ------------------ ------------------
  10.10.10.1      316  2305990            103


The receiver is requesting traffic from the source (IGMP membership report):

HP1# sho ip igmp vlan 200

 IGMP Service Protocol Info

  Total VLANs with IGMP enabled                : 7
  Current count of multicast groups joined     : 1

  IGMP Filter Unknown Multicast: Disabled
  IGMP Filter Unknown Multicast Status: Disabled

  VLAN ID : 200
  VLAN Name : 200-RECEIVER
  IGMP version : 2
  Querier Address [this switch] : 10.10.40.1
  Querier Port :
  Querier UpTime : 129d 3h 48m 43s
  Querier Expiration Time : 0h 0m 58s

  Active Group Addresses Type       Expires         Ports      Reports Queries
  ---------------------- ---------- --------------- ---------- ------- -------
  239.1.1.1              Filter     0h 4m 19s       A1         3       0

HP1# sho ip igmp groups

 IGMP Group Address Information

  VLAN ID Group Address   Expires       UpTime        Last Reporter   | Type
  ------- --------------- ------------- ------------- --------------- + ------
  200     239.1.1.1       0h 3m 27s     0h 2m 4s      10.10.40.2    | Filter

Check mroute on HP and Cisco:

HP1# sho ip pim mroute

 IP Multicast Route Entries

  Total number of entries : 1

  Group Address   Source Address  Neighbor        VLAN
  --------------- --------------- --------------- ----
  239.1.1.1       10.10.30.2      10.10.10.1      316


Cisco2#show  ip mroute
IP Multicast Routing Table
...

(*, 239.1.1.1), 00:02:43/00:02:46, RP 10.10.30.1, flags: S
  Incoming interface: GigaEthernet1/0/2, RPF nbr 10.10.20.2
  Outgoing interface list:
    GigaEthernet1/0/1, Forward/Sparse, 00:02:43/00:02:46

(10.10.30.1, 239.1.1.1), 00:02:43/00:00:16, flags: T
  Incoming interface: GigaEthernet1/0/2, RPF nbr 10.10.20.2
  Outgoing interface list:
    Port-channel3, Forward/Sparse, 00:02:43/00:02:46



Monday, July 6, 2015

Configure Distributed Trunking on HP Procurve and MEC on Cisco VSS

Distributed Trunking is the 'equivalent' of the vPC on the Cisco Nexus Series. It's a link aggregation technique which can be used even if the host is connected on 2 differents switchs. The following design has been built between 2 HP 5400 and 2 Cisco 4500 in VSS mode.



  • Configuration on the Cisco Switch:

interface Port-channel20
 description TO-HP-DT
 switchport
 switchport mode trunk
!
interface TenGigabitEthernet1/5/4
 description TO-HP-DT-1
 switchport mode trunk
 channel-group 20 mode active
!
interface TenGigabitEthernet2/5/4
 description TO-HP-DT-2
 switchport mode trunk
 channel-group 20 mode active


  • Configuration of the HP 1:
    • Configure ISC
trunk B7,E8 trk10 lacp
switch-interconnect trk10
vlan xxx
 tagged trk10
vlan xxx
 tagged trk10
...
    • Configure the keepalive 
interface D20
   name "Keep-Alive"
   exit
vlan 900
   name "VLAN900"
   untagged D20
   ip address 192.168.100.1 255.255.255.0
   exit
distributed-trunking peer-keepalive vlan 900
distributed-trunking peer-keepalive destination 192.168.100.2
    • Configure the dt-lacp between the VSS and the HP:
trunk A1,B1 trk1 dt-lacp

  • Configuration of the HP 2:
    • Configure ISC
trunk B7,E8 trk10 lacp
switch-interconnect trk10
vlan xxx
 tagged trk10
vlan xxx
 tagged trk10
...
    • Configure the keepalive 
interface D20
   name "Keep-Alive"
   exit
vlan 900
   name "VLAN900"
   untagged D20
   ip address 192.168.100.2 255.255.255.0
   exit
distributed-trunking peer-keepalive vlan 900
distributed-trunking peer-keepalive destination 192.168.100.1
    • Configure the dt-lacp between the VSS and the HP:
trunk A1,B1 trk1 dt-lacp
  • Validation:
HP-1# show switch-interconnect
Port         : Trk10
Status       : Up
Active VLANs : 1,100,200,300


HP-1# show distributed-trunking statistics peer-keepalive
DT peer-keepalive Status : Up

HP-1# show  distributed-trunking consistency-parameters trunk trk1

Allowed VLANs on Local : 1,100,200,300
Allowed VLANs on Peer  : 1,100,200,300

HP-1# show  lacp distributed

                             Distributed LACP

Local Port Status:

       LACP    Trunk   Port            LACP    Admin  Oper
  Port Enabled Group   Status  Partner Status  Key    Key
  ---- ------- ------- ------- ------- ------- ------ ------
  A1   Active  Trk1    Up      Yes     Success 0      290


Remote Port Status:

          LACP      Trunk     Port                LACP      Oper
   Port   Enabled   Group     Status    Partner   Status    Key
   ----   -------   -------   -------   -------   -------   ------
   A1     Active    Trk1      Up        Yes       Success   20

C4510-VSS-Core#show  lacp 20 neighbor

Partner's information:

                  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Te1/5/4   SA      0         40a8.f07b.a400   2s    0x0    0x0    0x271F  0x3D
Te2/5/4   SA      0         40a8.f07b.a400   4s    0x0    0x0    0x271A  0x3D


Some remarks:
- ISC is only supported in MST mode