CISCO ISE - How to change DOMAIN NAME

            TASK - Need to change the Domain for ISE  

Current Domain Name - dsldevice.lan

Changed Domain Name - bignetwork.com

STEP 1 - First check current domain name 

STEP 2 - During bootup if you want to change the domain name you will see below 

When you apply "ip domain bignetwork.com" , ISE will ask you with below Warning 

When you ask to YES then it will start stoping services 

Again it started the Services 

STEP 3- Validation 
now you can validate the domain has been changed

SDWAN tloc-list verses local-tloc-list

CASE STUDY - LOCAL-TLOC-LIST ver TLOC-LIST

LOCAL-TLOC-LIST 

Syntax : set local-tloc color {color} [encap {ipsec|gre}] 

where color is any one of the supported TLOC colors. This action directs packets to be forwarded out of the TLOC that is specified in the color argument. If this TLOC is not available (because it is not configured, the tunnel is down, or so on), then the traffic is forwarded out any valid TLOC, as indicated by the routing table. There is also a configuration command called set local-tloc-list that allows for the selection of one or more colors.

local-tloc action selects the preferred egress TLOC on the local WAN Edge router, while the
TLOC-List action mandates the TLOCs on the receiving WAN Edge that the traffic will be forwarded to

CONFIGURATION DIFFERENCE 

Seqence 11 for youtube traffic follow the traffic path biz-internet and when biz-internet down it take path from avalible color - mpls 

sequence 11

  match
    app-list YouTube
     source-ip 0.0.0.0/0
!
 action accept
set
 local-tloc-list
  color biz-internet
  encap ipsec

Sequence 21 is for fackbook traffic during biz-internet UP will follow biz-internet path but when biz-internet down then fackbook traffic drop

sequence 21

    match

      app-list Facebook

      source-ip 0.0.0.0/0

!

    action accept

    set

       vpn 1

       tloc-list DC_INET_TLOCS

Let see when applying above command during avalibilty of  Color biz-internt and when BFD down for biz-internet so traffic for youtube and fackbook follow different way based on given command - local-tloc-list ver tloc-list 

FLOW EXAMPLE

When BFD related with Color- biz-internet - UP 

local-tloc-list 

Branch-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app youtube all

!

Number of possible next hops: 1

Next Hop: IPsec

Source: 100.64.102.2 12346 Destination: 100.64.21.2 12386 Color:biz-internet 

tloc-list

Branch-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app facebook all

!

Number of possible next hops: 1

Next Hop: IPsec

Source: 100.64.102.2 12346 Destination: 100.64.21.2 12386 Color:biz-internet 

When BFD related with Color- biz-internet - DOWN 

local-tloc-list

BR2-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app youtube all

dest-ip 0.0.0.0 protocol 1 app youtube all

Number of possible next hops: 1

Next Hop: IPsec

Source: 172.16.102.2 12346 Destination: 172.16.21.2 Color: mpls

tloc-list

BR2-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app facebook all

dest-ip 0.0.0.0 protocol 1 app facebook all

Number of possible next hops: 1

Next Hop: Blackhole  <<<<<<<<<Traffic drop

SDWAN - DEFAULT ROUTE ADVERTISE HUB to REMOTE SITE

CONDITION 

We need to advertise default route from HUB as we have Firewall/Internet , So any Unknown Traffic should go to HUB first.

Backhauling moves the traffic to a datacenter where firewalls are deployed and a secure Internet access is available

Lets start 

From SITE - 100 HUB site , We adevertise the Default route in OMP 

Check BGP advertise Default from SITE 100 Router 

Now Check On vEDGE SITE 100 and see the Default route in Adevrtise from vEDGE 

OMP Routes 

Now check on SITE 300 , We have seen the Default route and notice this deafult route advertise by vSMART 

vSMART - System IP - 1.1.1.30

Now Open Route and see the Originator for default route.

Thanks will continue with Next blogs

SDWAN - BGP SERVICE VPN CONFIGURATION - USING TEMPLATE

 CONDITION 

Configure Service VPN with BGP for Remote Site communication 

Configuration Parameter

1. SDWAN Control plan and Data plan already preconfigured for connectivity

2. BGP between vEDGE and Router 

3. BGP AS Number 10 

4.Loopback1 Advertise in BGP 

5.Create BGP Template in Service VPN 

TOPOLOGY LAB

LETS START LAB - 

STEP 1 - To Create Feature Template BGP in SERVICE VPN 

The Below paramater select based on requirement 

BGP -

 Shutdown - No (Enabled BGP)

 AS Number - Device specific - It ask during Template push to Device 

 Router ID - Device specific 

 Other Parameter make Default 

Provide Redistribution OMP in BGP to get the Routes from OMP to BGP 

Now Lets configure BGP Neigbour - Put all Device Specific - will fill during apply on Device.

Now Feature BGP Template ready to call in Template , I have already below Template apply on Device 

Now Got to section Service VPN and Call BGP Feature Template here

And also got to feature template VPN 1 and enable BGP to OMP redistribution 

Now attached the template on device 

Attached Template with Device Specific Values 

Now Validate the Configuration 

First to Validate the Template enable on Device 

BGP Neigbour Status on VEDGE 

Router BGP status and Prefix learning 

Remote Site - 300 Subnet Recevied on SITE - 100

VEDGE 04 SITE 300 

SITE - 100 To SITE - 300 Communication check 

Will Continue with maniputaion in Next Blogs :)

EAP TYPE EXPLAIN

 EAP (Extensible Authentication Protocol) is an authentication framework used in wireless networks, VPNs, and other network access protocols. It supports various authentication methods to establish secure connections between clients and servers. Here are some commonly used EAP methods:

1. EAP-TLS (Transport Layer Security): EAP-TLS uses digital certificates for both the client and the server. It provides strong mutual authentication and secure key exchange. This method is widely used in enterprise networks where security is a top priority.

2. EAP-TTLS (Tunneled Transport Layer Security): EAP-TTLS is an extension of EAP-TLS that provides a way to securely transmit legacy authentication protocols over TLS. It allows for a variety of inner authentication methods, such as PAP (Password Authentication Protocol) or MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2).

3. PEAP (Protected Extensible Authentication Protocol): PEAP is designed to provide a secure authentication method within an encrypted tunnel. It encapsulates EAP methods, such as EAP-MSCHAPv2 or EAP-GTC (Generic Token Card), within a TLS tunnel. PEAP is widely supported by various operating systems and is commonly used in enterprise wireless networks.

4. EAP-FAST (Flexible Authentication via Secure Tunneling): EAP-FAST is an EAP method that provides a secure tunnel for transmitting credentials. It is designed to be more lightweight and efficient compared to other EAP methods. EAP-FAST uses a pre-shared key or a password to establish a secure tunnel between the client and the server.

5. EAP-SIM (Subscriber Identity Module): EAP-SIM is primarily used in mobile networks and relies on the SIM card in a mobile device for authentication. It leverages the security features of the SIM card to authenticate the user.

6. EAP-AKA (Authentication and Key Agreement): EAP-AKA is another EAP method used in mobile networks. It is based on the AKA algorithm used in the Universal Mobile Telecommunications System (UMTS) network. EAP-AKA provides mutual authentication between the client and the network.

7. EAP-MD5 (Message Digest 5): EAP-MD5 is a legacy EAP method that provides basic authentication using a shared secret key. It is considered less secure compared to other EAP methods and is not recommended for use in secure networks.

These are just a few examples of EAP methods. The choice of EAP method depends on the specific requirements and security considerations of the network deployment. It is important to select an EAP method that provides the desired level of security and compatibility with the client devices and authentication servers.

Large EAP-TLS Packet Problem

 When dealing with large EAP-TLS packets that are not authenticating wireless clients, there could be several potential causes for the issue. Here are some troubleshooting steps you can try:

1. MTU Size: Check if the Maximum Transmission Unit (MTU) size is properly configured on both the client and server sides. Large EAP-TLS packets may exceed the default MTU size, causing fragmentation issues. Ensure that the MTU size is set to accommodate the larger packets.

2. Fragmentation and Reassembly: Verify if fragmentation and reassembly are properly supported and enabled on both the client and server sides. Some devices or network configurations may not handle fragmented EAP-TLS packets correctly, leading to authentication failures.

3. Network Path: Verify that the network path between the client and the authentication server is not causing any packet loss or corruption issues. Use tools like packet captures or network monitoring tools to analyze the traffic and identify any abnormalities.

4. Certificate Issues: Check if the client and server certificates are properly configured and valid. Ensure that the certificates are correctly installed and trusted on both sides. Any certificate-related issues, such as expired or mismatched certificates, can prevent successful authentication.

5. Firewall or ACL Restrictions: Ensure that there are no firewall rules or access control lists (ACLs) blocking the EAP-TLS traffic. Check both the client and server sides for any restrictive policies that might be interfering with the authentication process.

6. EAP-TLS Configuration: Review the EAP-TLS configuration on both the client and server sides to ensure that all necessary parameters, such as certificate names, authentication methods, and cipher suites, are correctly configured and compatible.

7. Debugging and Logging: Enable debugging and logging features on both the client and server sides to gather more detailed information about the authentication process. Look for any error messages or warnings that might provide insight into the cause of the authentication failure.

If the troubleshooting steps above do not resolve the issue, it may be necessary to involve the network and system administrators or consult the documentation and support resources specific to the wireless infrastructure and authentication server being used.

IOS-DHCP - EXPLAINED WITH LAB RESULTS

 CONDITION

Windows DHCP Server not responding and we need to give quick solution for wireless client to use the Services , We need to configure DHCP server for some wireless clients. 

Lets Start 

Topolgy for DHCP SERVER 

Configure a DHCP pool on router DHCP_SERVER called “MYPOOL” with the following configuration:

Clients should use the DNS server with IP address 1.1.1.1.

Clients should use network 192.168.10.0 /24.

Clients should not use the 192.168.10.10 – 20 range.

Cliends should renew their IP address after 2 minutes for testing (U can use 2 days)

Configure router DHCP_Server  so it stores DHCP bindings in flash.

Router Name DHCP_Client Configure as Client :)

ROUTER DHCP_SERVER CONFIGURATION 

Now Lets start Configure Router for DHCP_Client 

Now lets open Interface f0/0 to Get the IP address from DHCP Server 

During DHCP Client Taking IP Discovery/Offer/Request/Acknowledgement 

*Mar  1 00:27:18.127: DHCP: DHCP client process started: 10

*Mar  1 00:27:18.139: RAC: Starting DHCP discover on FastEthernet0/0

*Mar  1 00:27:18.139: DHCP: Try 1 to acquire address for FastEthernet0/0

*Mar  1 00:27:18.155: DHCP: allocate request

*Mar  1 00:27:18.155: DHCP: new entry. add to queue, interface FastEthernet0/0

*Mar  1 00:27:18.155: DHCP: SDiscover attempt # 1 for entry:

*Mar  1 00:27:18.155: Temp IP addr: 0.0.0.0  for peer on Interface: FastEthernet0/0

*Mar  1 00:27:18.155: Temp  sub net mask: 0.0.0.0

*Mar  1 00:27:18.155:    DHCP Lease server: 0.0.0.0, state: 1 Selecting

*Mar  1 00:27:18.159:    DHCP transaction id: 2191

*Mar  1 00:27:18.159:    Lease: 0 secs,  Renewal: 0 secs,  Rebind: 0 secs

*Mar  1 00:27:18.159:    Next timer fires after: 00:00:04

*Mar  1 00:27:18.159:    Retry count: 1   Client-ID: cisco-cc01.2004.0000-Fa0/0

*Mar  1 00:27:18.163:    Client-ID hex dump: 636973636F2D636330312E323030342E

*Mar  1 00:27:18.167:                        303030302D4661302F30

*Mar  1 00:27:18.171:    Hostname: DHCP_Client

*Mar  1 00:27:18.171: DHCP: SDiscover: sending 300 byte length DHCP packet

*Mar  1 00:27:18.171: DHCP: SDiscover 300 bytes

*Mar  1 00:27:18.171:             B'cast on FastEthernet0/0 interface from 0.0.0.0

*Mar  1 00:27:20.119: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Mar  1 00:27:20.227: DHCP: Received a BOOTREP pkt

*Mar  1 00:27:20.227: DHCP: Scan: Message type: DHCP Offer

*Mar  1 00:27:20.227: DHCP: Scan: Server ID Option: 192.168.10.2 = C0A80A02

*Mar  1 00:27:20.231: DHCP: Scan: Lease Time: 300

*Mar  1 00:27:20.231: DHCP: Scan: Renewal time: 150

*Mar  1 00:27:20.231: DHCP: Scan: Rebind time: 262

*Mar  1 00:27:20.231: DHCP: Scan: Subnet Address Option: 255.255.255.0

*Mar  1 00:27:20.231: DHCP: Scan: DNS Name Server Option: 1.1.1.1

*Mar  1 00:27:20.235: DHCP: rcvd pkt source: 192.168.10.2,  destination:  255.255.255.255

*Mar  1 00:27:20.235:    UDP  sport: 43,  dport: 44,  length: 308

*Mar  1 00:27:20.235:    DHCP op: 2, htype: 1, hlen: 6, hops: 0

*Mar  1 00:27:20.235:    DHCP server identifier: 192.168.10.2

*Mar  1 00:27:20.235:         xid: 2191, secs: 0, flags: 8000

*Mar  1 00:27:20.235:         client: 0.0.0.0, your: 192.168.10.3

*Mar  1 00:27:20.239:         srvr:   0.0.0.0, gw: 0.0.0.0

*Mar  1 00:27:20.239:         options block length: 60

*Mar  1 00:27:20.239: DHCP Offer Message   Offered Address: 192.168.10.3

*Mar  1 00:27:20.239: DHCP: Lease Seconds: 300    Renewal secs:  150    Rebind secs:   262

*Mar  1 00:27:20.243: DHCP: Server ID Option: 192.168.10.2

*Mar  1 00:27:20.243: DHCP: offer received from 192.168.10.2

*Mar  1 00:27:20.243: DHCP: SRequest attempt # 1 for entry:

*Mar  1 00:27:20.243: Temp IP addr: 192.168.10.3  for peer on Interface: FastEthernet0/0

*Mar  1 00:27:20.243: Temp  sub net mask: 255.255.255.0

*Mar  1 00:27:20.247:    DHCP Lease server: 192.168.10.2, state: 2 Requesting

*Mar  1 00:27:20.247:    DHCP transaction id: 2191

*Mar  1 00:27:20.247:    Lease: 300 secs,  Renewal: 0 secs,  Rebind: 0 secs

*Mar  1 00:27:20.247:    Next timer fires after: 00:00:03

*Mar  1 00:27:20.247:    Retry count: 1   Client-ID: cisco-cc01.2004.0000-Fa0/0

*Mar  1 00:27:20.247:    Client-ID hex dump: 636973636F2D636330312E323030342E

*Mar  1 00:27:20.247:                        303030302D4661302F30

*Mar  1 00:27:20.247:    Hostname: DHCP_Client

*Mar  1 00:27:20.247: DHCP: SRequest- Server ID option: 192.168.10.2

*Mar  1 00:27:20.247: DHCP: SRequest- Requested IP addr option: 192.168.10.3

*Mar  1 00:27:20.247: DHCP: SRequest placed lease len option: 300

*Mar  1 00:27:20.247: DHCP: SRequest: 318 bytes

*Mar  1 00:27:20.247: DHCP: SRequest: 318 bytes

*Mar  1 00:27:20.247:             B'cast on FastEthernet0/0 interface from 0.0.0.0

*Mar  1 00:27:20.255: DHCP: Received a BOOTREP pkt

*Mar  1 00:27:20.255: DHCP: Scan: Message type: DHCP Ack

*Mar  1 00:27:20.255: DHCP: Scan: Server ID Option: 192.168.10.2 = C0A80A02

*Mar  1 00:27:20.259: DHCP: Scan: Lease Time: 300

*Mar  1 00:27:20.259: DHCP: Scan: Renewal time: 150

*Mar  1 00:27:20.259: DHCP: Scan: Rebind time: 262

*Mar  1 00:27:20.259: DHCP: Scan: Host Name: DHCP_Client

*Mar  1 00:27:20.259: DHCP: Scan: Subnet Address Option: 255.255.255.0

*Mar  1 00:27:20.259: DHCP: Scan: DNS Name Server Option: 1.1.1.1

*Mar  1 00:27:20.263: DHCP: rcvd pkt source: 192.168.10.2,  destination:  255.255.255.255

*Mar  1 00:27:20.263:    UDP  sport: 43,  dport: 44,  length: 308

*Mar  1 00:27:20.263:    DHCP op: 2, htype: 1, hlen: 6, hops: 0

*Mar  1 00:27:20.263:    DHCP server identifier: 192.168.10.2

*Mar  1 00:27:20.263:         xid: 2191, secs: 0, flags: 8000

*Mar  1 00:27:20.263:         client: 0.0.0.0, your: 192.168.10.3

*Mar  1 00:27:20.263:         srvr:   0.0.0.0, gw: 0.0.0.0

*Mar  1 00:27:20.263:         options block length: 60

*Mar  1 00:27:20.263: DHCP Ack Message

*Mar  1 00:27:20.263: DHCP: Lease Seconds: 300    Renewal secs:  150    Rebind secs:   262

*Mar  1 00:27:20.263: DHCP: Server ID Option: 192.168.10.2

*Mar  1 00:27:20.263: DHCP Host Name Option: DHCP_Client

*Mar  1 00:27:21.119: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

*Mar  1 00:27:23.275: DHCP: Releasing ipl options:

*Mar  1 00:27:23.275: DHCP: Applying DHCP options:

*Mar  1 00:27:23.279:   Adding DNS server address 1.1.1.1

*Mar  1 00:27:23.279: DHCP Client Pooling: ***Allocated IP address: 192.168.10.3

*Mar  1 00:27:23.307: Allocated IP address = 192.168.10.3  255.255.255.0

*Mar  1 00:27:23.307: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.10.3, mask 255.255.255.0, hostname DHCP_Client

CLIENT Getting IP address from DHCP SERVER 

NOW LETS CHECK THE MORE DETAILS FOR CLIENT 

- Lease Server/Lease Time/Renew Time 

Now Check on DHCP SERVER Binding 

NOW lets Client initiated DHCP IP RENEW, SAME IP Getting from DHCP SERVER 

DHCP SERVER ASSIGNMENT SAME IP AGAIN 

And we have configure to stop this Binding information on FLASH on DHCP SERVER We can see the DHCP SERVER writting this information in FLASH:

Now lets validate the File "mybindings"