Thursday, June 28, 2018

Introduction to Locator identification/Separator Protocol (LISP)

ılılılı RouteXP ılılılı ılılılı
Locator identification/Separator Protocol (LISP) because the name shows separates the region and
the identifier of the community hosts, hence making it viable for digital machines to move
across subnet limitations whilst maintaining their IP deal with. LISP is composed of a community
architecture and a set of protocols that permit new semantics for IP addressing by way of creating namespaces:

Endpoint Identifiers (EIDs): EIDs are assigned to give up hosts.
Routing Locators (RLOCs) : RLOCs are assigned to routers that make up the worldwide
routing device.

The introduction of those separate namespaces provides several advantages, including the following:
  • Topologically aggregated RLOCs permit improved routing system scalability .
  • IP portability .
  • less complicated IPv6 transition .
  • IP mobility, the host EIDs can pass with out changing the IP cope with of the host or
  • digital gadget; most effective the RLOC changes on a bunch pass.
LISP integrates well into the current network infrastructure and requires no changes to
the end host stack. It fosters a simple, incremental, network-based implementation with
most of the deployment at the network edge devices.

LISP Frame Format
 A LISP frame’s outer encapsulation is a UDP frame where the destination and source IP
addresses are the addresses of the Ingress Tunnel Router (ITR) and Egress Tunnel Router
(ETR), respectively. For Layer 3 LISP, the destination UDP port number is 4341. The LISP
header has the Locator reachability bits and the nonce fields.

Fig 1.1-CCIE Data-Center: LISP ( Locator ID/Separation Protocol)

 LISP Routing
As a bunch transmits a packet, if the destination of the packet is in every other LISP area,
it reaches the LISP ITR. The ITR maps the vacation spot endpoint id (EID) to an RLOC with the aid of looking up the vacation spot in a map server. As shown in figure 2-6 , using this facts he ITR encapsulates the packet with an outer header. The destination RLOC is ETR
at the back of which the destination host exists.  when the destination ETR is understood, the ITR encapsulates the packet, putting the destination deal with to the RLOC of the vacation spot ETR lower back with the aid of the mapping infrastructure.

Fig 1.2-CCIE Data-Center: LISP ( Locator ID/Separation Protocol)

 In addition to LISP routing, the location and EID separation provides flexible and unmatched mobility for IP endpoints without any subnet boundary limitation allowing IP endpoints, regardless of their IP addresses, to be deployed anywhere. These EIDs can freely move within and across data center racks and across geographical and organisational boundaries. The LISP Mobility solution has the following characteristics:
  • Optimal shortest path routing .
  • Both IPv4 and IPv6 addresses are supported .
  • Support for load balancing and multi homing .
  • Provides a solution that is transparent to both EIDs and the core network .
By allowing IP endpoints to change location while maintaining their assigned IP address,
the LISP mobility solution enables the IP endpoints to move between different subnets,

while guaranteeing optimal routing to the IP endpoint.

Introduction to Cisco IOS Zone Based Firewall

ılılılı RouteXP ılılılı ılılılı
Introduction to Cisco IOS Zone Based Firewall

In this article we will consider the topic of Cisco IOS Zone Based Firewall. Cisco IOS Zone Based Firewall allows us to define Security Zones and to give each zone its own policy.

Thanks for such a huge support to our projects 
www.networksbaseline.com
www.routexp.com

Security Zone – interface or group of interfaces, on which particular policy is applied.  By default in the same Security Zone all traffic is permitted, but between security zones all traffic is blocked, except the traffic generated by the router. For permitting traffic between security zones, creating zone-pairs and policies for each zone are required.

Zone-pair – allows us to determine uni-directional firewall policy between zones. To put it simply, a zone-pair determines the direction of interesting traffic. The direction is determined between source and destination zones.

Zone policy – determines what kind of traffic should be denied or permitted between zones. For example: we want to permit HTTP traffic and deny SMTP traffic. Zone policy has three actions: “pass”, “drop” and “inspect”. Pass and drop actions have immediate effect on traffic, but Inspect action tells the router to use pre-defined class map for traffic filtration.

Fig 1.1- Cisco IOS Zone Based Firewall

Let’s consider an example in details. In the following scenario, we will create two zones, inside and outside, and allow only PING (ICMP) for Inside Zone to pass to Outside Zone (not vice-versa).

Before starting configuration of Zone Based Firewall, make sure that everything works and all hosts are connected to each other. We will need to identify interfaces that will belong in the same security zone and group them together.

R1(config)#zone security INSIDE
R1(config)#zone security OUTSIDE
R1(config)#interface fa0/0
R1(config-if)#zone-member security INSIDE
R1(config)#interface fa0/1
R1(config-if)#zone-member security INSIDE
R1(config)#interface fa1/0
R1(config-if)#zone-member security OUTSIDE
R1(config)#class-map type inspect match-any CLASS_INSIDE_2_OUTSIDE
R1(config-cmap)#match protocol icmp

In class-map configuration parameters basically we use two parameters: match-any and match-all. In case of “match-any”, traffic can be matched to any match criteria, but in case of match-all the traffic must match all criteria, which are determined in Class-map. In our case we check only ICMP and we can use any of it.

We’ve already determined what traffic we want to control and now we determine what to do with this traffic.


R1(config)#policy-map type inspect POLICY_INSIDE_2_OUTSIDE
R1(config-pmap)#class type inspect CLASS_INSIDE_2_OUTSIDE
R1(config-pmap-c)#inspect
note: at the end of the policy map there is an implicit “deny all” by default, which looks  like this :
class class-default
drop

Router(config)#zone-pair security PAIR_INSIDE_2_OUTSIDE source INSIDE destination OUTSIDE
Router(config-sec-zone-pair)#service-policy type inspect POLICY_INSIDE_2_OUTSIDE

Let’s do some checking. According to our scenario, hosts in Inside zone must ping hosts located in outside zone, but hosts in outside zone will not be able to ping hosts located in inside zone. Let’s see the result.

host1#ping 192.168.12.1
!!!!
host3#ping 192.168.1.2
…..
host3#ping 192.168.2.2

…..

Wednesday, June 20, 2018

Lan-to-Lan IPSEC VPN between two Cisco Routers

ılılılı RouteXP ılılılı ılılılı
Lan-to-Lan IPSEC VPN between two Cisco Routers

With IPSEC VPNs, businesses can connect together remote office LANs over the Internet with the strong encryption and security offered by the IPSEC protocol. IPSEC is an IETF security standard. It is basically a suit of several protocols that offer secure communication over insecure paths. It is therefore ideal for connecting securely distant LAN networks over the insecure Internet. 

We have two types of IPSEC VPNs: Lan-to-Lan (or site-to-site) encrypted VPN and Remote Access VPN. The first one is extensively used to securely connect distant office networks and the second one for allowing remote users/teleworkers to access resources on a central site network. In this post we will describe briefly a Lan-to-Lan IPSEC VPN and provide a full configuration example with two Cisco IOS Routers using IPSEC.

We could use a private WAN network with Frame Relay or MPLS connections, which however would bring the cost very high. Instead, with IPSEC VPN we can use cheap Internet connectivity (which will be secured by IPSEC) for communication between our remote sites.

We will be using the example diagram above for the configuration scenario. Generally, there are two Phases for IPSEC VPN:
  • Phase 1: In this Phase we configure an ISAKMP policy. This policy establishes an initial secure channel over which further communication will follow. It defines how the ipsec peers will authenticate each other and what security protocols will be used.
  • Phase 2: In this Phase we configure a crypto map and crypto transform sets. In general, Phase 2 deals with traffic management of the actual data communication between sites. The transform sets configured here, define what authentication and encryption protocols will be used on the data traffic.
There is a software VPN Configuration Tool which generates a fully working Router configuration  for site-to-site VPN between Cisco Routers  which can be very handy in many situations requiring the configuration of different Cisco VPN scenarios. 



Fig 1.1- LAN to LAN IPSEC communication

For manual site-to-site VPN config check out the following examples.
Let’s see the complete configurations for NBRouter_A and NBRouter_B below:

Configuration for NBRouter_A

NBRouter_A#show run
Building configuration…
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ROUTER-A
!
boot-start-marker
boot-end-marker
!
!
!
ip audit po max-events 100
no ip domain lookup
no ftp-server write-enable
!
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
crypto isakmp key testkey1234 address 200.0.0.1
!
crypto ipsec transform-set aes-sha-transform esp-aes 256 esp-sha-hmac
crypto map aesmap 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set aes-sha-transform
match address acl_vpn
!
interface FastEthernet0/0
ip address 100.0.0.1 255.255.255.0
ip nat outside
crypto map aesmap
!
interface FastEthernet0/1
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip nat inside source list acl_nat interface FastEthernet0/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 100.0.0.2
no ip http server
no ip http secure-server
!
ip access-list extended acl_nat
deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 any
ip access-list extended acl_vpn
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
!
end

Configuration forNBRouter_B

NBRouter_B#show run
Building configuration…
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ROUTER-B
!
boot-start-marker
boot-end-marker
!
ip audit po max-events 100
no ip domain lookup
no ftp-server write-enable
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
crypto isakmp key testkey1234 address 100.0.0.1
!
crypto ipsec transform-set aes-sha-transform esp-aes 256 esp-sha-hmac
crypto map aesmap 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set aes-sha-transform
match address acl_vpn
!
interface FastEthernet0/0
ip address 200.0.0.1 255.255.255.0
ip nat outside
!— Apply crypto map to the outside interface.
crypto map aesmap
!
interface FastEthernet0/1
ip address 192.168.2.254 255.255.255.0
ip nat inside
ip nat inside source list acl_nat interface FastEthernet0/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 200.0.0.2
no ip http server
no ip http secure-server
!
ip access-list extended acl_nat
deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.2.0 0.0.0.255 any
ip access-list extended acl_vpn
permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
!

end

Introduction to Multicast VPN

ılılılı RouteXP ılılılı ılılılı
Introduction to Multicast VPN

The new way refers to the setting up of Multipoint LSP in the MPLS VPN environment to carry multicast traffic in the VPN. Here, all CE routers belong to a single customer at different branches. There is no multicast receiver behind CE3 router. The MPLS core is PIM-free. Only PE routers will run PIM with the CE routers.

A separate function is required to enable IP multicast over a Multiprotocol Label Switching Virtual Private Networks (MPLS VPNs) network, as MPLS has no native ability to support it.

The Service Provider MVPN network forwards the customer IP multicast data to remote customer sites. To achieve this, customer traffic (C-packets) is encapsulated at the Service Provider PE inside P- packets. The encapsulated P-packet is then forwarded to remote PE sites as native multicast inside the P-Network.

During this process, the P-Network has no knowledge of the C-Network traffic. The PE is the device that participates in both networks. Note there may be more than one Customer Network per PE

PE routers configuration

The Loopback 0 interface of PE1 router is configured to be used as the Root Node IP address. The Opaque value for the multipoint LSP is constructed based on the VPN ID value of 1:1. The mdt default mpls mldp command creates the MP2MP LSP known to all PE routers for that particular VRF. This LSP is used to forward all customer multicast traffic by default.

Fig 1.1- Multicast VPN


Configuration on PE1 Router
!
ip vrf CUST1
 rd 1:1 vpn id 1:1                             
 route-target both 1:1 mdt default mpls mldp 1.1.1.1            
!
interface Loopback 0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 0!ip multicast-routing vrf CUST1         
!ip pim vrf CUST1 rp-address 12.1.1.1
!
interface fastethernet 1/1
 ip vrf forwarding CUST1
 ip address 192.168.1.1 255.255.255.0 ip pim sparse-mode
!
router bgp 100
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback 0
 neighbor 4.4.4.4 remote-as 100
 neighbor 4.4.4.4 update-source Loopback 0
 !
 address-family vpnv4
 neighbor 3.3.3.3 activate
 neighbor 4.4.4.4 activate
 exit-address-family
 !
 address-family ipv4 vrf CUST1
 redistribute connected
 exit-address-family
!

The configuration of PE2 and PE3 is same as PE1 router.

Configuration on PE2 Router
!
ip vrf CUST1
 rd 1:1
 vpn id 1:1        
 route-target both 1:1
 mdt default mpls mldp 1.1.1.1          
!
interface Loopback 0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0!ip multicast-routing vrf CUST1        
!ip pim vrf CUST1 rp-address 12.1.1.1
!
interface fastethernet 1/1
 ip vrf forwarding CUST1
 ip address 192.168.2.1 255.255.255.0 ip pim sparse-mode
!
router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback 0
 neighbor 4.4.4.4 remote-as 100
 neighbor 4.4.4.4 update-source Loopback 0
 !
 address-family vpnv4
 neighbor 1.1.1.1 activate
 neighbor 4.4.4.4 activate
 exit-address-family
 !
 address-family ipv4 vrf CUST1
 redistribute connected
 exit-address-family
!

Configuration on PE3 Router
!
ip vrf CUST1
 rd 1:1
 vpn id 1:1        
 route-target both 1:1
 mdt default mpls mldp 1.1.1.1          
!
interface Loopback 0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0!ip multicast-routing vrf CUST1        
!ip pim vrf CUST1 rp-address 12.1.1.1
!
interface fastethernet 1/1
 ip vrf forwarding CUST1
 ip address 192.168.3.1 255.255.255.0 ip pim sparse-mode
!
router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback 0
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback 0
 !
 address-family vpnv4
 neighbor 1.1.1.1 activate
 neighbor 3.3.3.3 activate
 exit-address-family
 !
 address-family ipv4 vrf CUST1
 redistribute connected
 exit-address-family
!

No multicast traffic is sent by CE routers at this stage.

Ethernet Over MPLS -EoMPLS

ılılılı RouteXP ılılılı ılılılı

Ethernet Over MPLS -EoMPLS 

Lets talk about the basics and the configurational part of the Ethernet over MPLS. Whenever you think about MPLS, it is a core technology of the service Provider. If you would like to understand more on MPLS and VPLS, you can go through the below mentioned links for more details


I think of EoMPLS as a virtual patch cord. Frames go in a port on a switch, get transported via MPLS labels over an IP routed network, and get spit out a port on another switch. The term "pseudowire" ("PWE") is also used for EoMPLS or  similar "virtual patch cord" functionality. 

Fig 1.1- EoMPLS tunnel between Sites

EoMPLS comes in two flavors: port-based (everything goes on a trunk port, preserving 802.1q VLAN info) or VLAN-based (traffic in an access VLAN gets transported). VLAN-based can transport different VLANs to different endpoints, or mix and match L2 and L3 activities on a port (via subinterfaces). It is configured using dot1q sub interfaces. 

Note that the technology will in principle do that for you. I'm not necessarily recommending you do that, because the cluster may behave oddly if the network between HERE and THERE goes flaky, drops packets for a while, etc. But EoMPLS is a great thing to have in your bag of tricks, for when you need it.

Why EoMPLS? It is downright handy when you have a VLAN that needs to be HERE and THERE, with a routed network in the middle. For example, cluster heartbeat between servers in two data centers. You do need MPLS capable switches that can also do EoMPLS at wire speed. Unlike MPLS VPN, there is no requirement for MBGP.

The other warning about EoMPLS is it might be a bit dangerous to your network's health. It is so easy to set up, that you can easily dig yourself a nice big hole, full or L2 over L3 "spaghetti". Which complicates troubleshooting, defeats structured design, ignores the carefully crafted routed core in your network, and causes warts. Well, 3 out of 4 anyway.

EoMPLS versus VPLS

Like QinQ tunneling (802.1q tunneling of switched traffic), EoMPLS just takes the frame that comes in a port (somehow), transports it across the middle, and spits it out the paired port on the other end. There is no examination of MAC address, no learning of source MAC address, in short, no switching logic applied.
VPLS is Virtual Private LAN Service. It is EoMPLS on steroids. In VPLS, the switch can have several EoMPLS tunnels and make a switching decision, as to which one to use. VPLS in the 6500 (7600) requires extra hardware assistance. It does not work in a "vanilla" 6500 (assuming the 6500 can somehow be considered vanilla is kind of a big assumption, I know).

Traditional VPLS

If you want switching logic, you can cheat a bit. If you cable the port doing EoMPLS to another switch, that other switch does  normal switching. You can even cable the EoMPLS to a non-EoMPLS port on the same switch. This is called a "loopback cable". (I do wish folks used a term that couldn't be confused with a loopback interface. Something like "humdinger" or "frobozz" perhaps?) This is mildly wasteful of ports, but works just fine.
So if you want to transport traffic from any of a bunch of ports on a switch to another switch using EoMPLS, add one more port to the VLAN, cable it physically to the EoMPLS port, and it'll work.

Design Example

Three switches, Switch A, Switch B and Switch C . Switches A and B are connected to C and Switch C is a Core Switch in this scenario

I enabled MPLS globally and on the uplink / downlink interfaces between the Switch A,  Switch B, and Switch C switches. In practice, one would enable them on all infrastructure uplinks, downlinks, and crosslinks in the distribution and core layers, and to selected closets if you need EoMPLS anywhere, anytime. The technique does not work if there is a routed path along which MPLS is not enabled.

Note: to support the MPLS labels, you'll want jumbo support consistently configured throughout as well. This requires per-interface configuration on uplinks, downlinks, and crosslinks. (The same interfaces that will be doing MPLS labels.)

Sample Configuration
!  
mpls ip
!
int Ten1/1
  mtu 9216   mpls ip 
!
int Ten1/2
  mtu 9216 
  mpls ip

!


Make sure you will not configure MPLS on the port that will be connected at L2 via EoMPLS. Just the paths in between the two endpoints.

I created two xconnect pseudowires, one from swA to swC, the other from swB to swC. As noted, the pseudo-wires can either be port-based (all VLANs) or VLAN-based (just one VLAN). I tried it both ways. Due to late hours, I did not test VLAN-based extensively.

Port-Based EoMPLS

The first xconnect went from Gig 4/1 to Gig 2/2, the second from Gig 4/1 to Gig 2/3 (Switch A and Switch B to Switch C). The addresses shown are the loopback address for the switch on the other end. The number is the circuit ID, which allows the two switches to recognize the two ends of one connection.
Here's some captured text from switch B:

Switch A#show run int gig 4/1
interface GigabitEthernet4/1 
mtu 9216 
no ip address 
xconnect 10.159.0.2 201 encapsulation mpls 
spanning-tree portfast trunk

swB#show mpls l2 vc 
Local intf     Local circuit        Dest address    VC ID      Status 
-------------  -------------------- --------------- ---------- ---------- 
Gi4/1          Ethernet             10.159.0.2      201        UP 

Switch B#show mpls l2 bind
Destination Address: 10.159.0.2,  VC ID: 201 
Local Label:  72 
Cbit: 1,    VC Type: Ethernet,    GroupID: 0 
MTU: 9216,   Interface Desc: w-ecc-01 G06-314 U31 ONBD1 
VCCV: CC Type: RA [2] 
CV Type: LSPV [2] 
Remote Label: 76 
Cbit: 1,    VC Type: Ethernet,    GroupID: 0 
MTU: 9216,   Interface Desc: n/a 
VCCV: CC Type: RA [2] 
CV Type: LSPV [2]

And for switch A:
Switch A#show run int gig 4/1
...
interface GigabitEthernet4/1 
mtu 9216 
no ip address 
xconnect 10.159.0.2 200 encapsulation mpls 
spanning-tree portfast trunk 
end 

Switch A#show mpls l2 vc 

Local intf     Local circuit        Dest address    VC ID      Status 
-------------  -------------------- --------------- ---------- ---------- 
Gi4/1          Ethernet             10.159.0.2      200        UP 

And for switch C:
Switch C#show run int gig 2/2
... interface GigabitEthernet2/2 
mtu 9216 
no ip address 
xconnect 10.112.0.128 200 encapsulation mpls 
spanning-tree portfast trunk 
... 
interface GigabitEthernet2/3 
mtu 9216 
no ip address 
xconnect 10.112.0.130 201 encapsulation mpls 
spanning-tree portfast trunk 
Switch C#show mpls l2 vc 

Local intf     Local circuit        Dest address    VC ID      Status 
-------------  -------------------- --------------- ---------- ---------- 
Gi2/2          Ethernet             10.112.0.128    200        UP 

Gi2/3          Ethernet             10.112.0.130    201        UP 


Note the VCID is 200 for one xconnect, 201 for the other. These have to be different for each pseudo-wire, and are used by the endpoints to match up xconnect commands. That is, the two ends of an xconnect must agree on the VCID number.

Troubleshooting EoMPLS

Along the way, I ran into two problems. The first took some time to resolve. The xconnect was not coming up, and debug showed an authorization problem. It turned out the MTU on the physical port (for port-based) has to be set, and to at least 1504, to accommodate VLAN  802.1q tagging. Subsequent experimentation showed that the xconnect verifies that the two end physical ports have the same MTU. (This would be a lovely nasty time-killer for a CCIE lab test, I suspect.)
Caution: not all 6500 blades support jumbos (8000 to 9216 byte MTU). 
The second (minor) problem was that the xconnect does not come up unless the physical port is up (something connected to it, link status). If you're trying to configure it without two devices plugged into the two ends, it's going to be difficult to see that word "up". (I was somewhat expecting it to behave more like a GRE tunnel: configure it and if it is happy, it shows as "up".)
I mention these as possible gotchas when doing xconnect. They could consume time trouble-shooting if you don’t expect this behavior.

Testing EoMPLS

This was testing by plugging in my two test PCs, addressed with 1.1.1.10 and 1.1.1.11. Those were certainly not in the global routing table in the lab.
When I did so, I could ping between the PCs, despite their being connected to two different switches with only routing of 10.0.0.0 networks in between. I varied the PC connection points to test all combinations (pairs of ports). They worked. (Output not captured.)
I also verified that when one PC was on swA and the other on swB, they could not ping each other (nor even ARP each other). There is no local switching of traffic coming out one pseudowire back into another. (For that, SIP or ES hardware is required with VPLS functionality).
However, I patched port 2/2 on swC to 2/5, and 2/3 to 2/6, and did “no shutdown” on the latter two ports. They defaulted to both being in VLAN 1. I was then able to ping between the edge-connected PCs. Neat!
The following capture shows that ports 2/5 and 2/6 were doing normal MAC-based LAN switching, and there was no MAC learning on ports 2/2 and 2/3:

Switch C#show mac-address-table dyn int gig 2/5 
Displaying entries from Line card 2: 

Legend: * - primary entry 
age - seconds since last seen 
n/a - not available 

vlan   mac address     type    learn     age              ports 
------+----------------+--------+-----+----------+-------------------------- 
Module 2: 
*    1  000b.db99.6dec   dynamic  Yes        220   Gi2/5 

Switch C#show mac-address-table dyn int gig 2/6 

Displaying entries from Line card 2: 

Legend: * - primary entry 
age - seconds since last seen 
n/a - not available 

vlan   mac address     type    learn     age              ports 
------+----------------+--------+-----+----------+-------------------------- 
Module 2: 
*    1  0015.c5b5.f3e4   dynamic  Yes        225   Gi2/6 

Switch C#show mac-address-table dyn int gig 2/6 2 
Legend: * - primary entry 
age - seconds since last seen 
n/a - not available 

vlan   mac address     type    learn     age              ports 
------+----------------+--------+-----+----------+-------------------------- 
No entries present. 

Switch C#show mac-address-table dyn int gig 2/2 3 
Legend: * - primary entry 
age - seconds since last seen 
n/a - not available 

vlan   mac address     type    learn     age              ports 

------+----------------+--------+-----+----------+-------------------------- 

No entries present.
Once this was worked, I was pleased with the extreme simplicity of adding xconnects.
Note also that enabling jumbos and MPLS on the infrastructure only needs to be done once, no matter how many xconnects are to be built for various purposes. 

For new deployments and upgrades, we now enable jumbos on the infrastructure since consistently doing it supports all sorts of  later needs. And doing it in ad hoc fashion is an invitation to all sorts of fun, especially with OSPF. (Adjacencies stay up with MTU mismatches, but won't come up after the link bounces -- even months after you changed the configuration.)

Note: redundant xconnects for High Availability require special handling of Spanning Tree. Note however that re-routing and MPLS will keep an xconnect up if there is any routed path fully supporting MPLS between the endpoints, so xconnects should be rather robust.

Sunday, June 10, 2018

Introduction to Subnetting

ılılılı RouteXP ılılılı ılılılı
A subnetwork, or subnet, is a logically visible subdivision of an IP network. The practice of dividing a network into two or more networks is called subnetting.

The process of subnetting involves the separation of the network and subnet portion of an address from the host identifier. This is performed by a bitwise AND operation between the IP address and the (sub)network mask. The result yields the network address or prefix, and the remainder is the host identifier.


Fig 1.1- Sample Class C Subnetting

Determining the network prefix

An IPv4 network mask consists of 32 bits, a sequence of ones (1) followed by a block of 0s. The trailing block of zeros (0) designates that part as being the host identifier.
The following example shows the separation of the network prefix and the host identifier from an address (192.168.5.130) and its associated /24 network mask (255.255.255.0). The operation is visualized in a table using binary address formats.

Determining the network prefix

An IPv4 network mask consists of 32 bits, a sequence of ones (1) followed by a block of 0s. The trailing block of zeros (0) designates that part as being the host identifier.
The following example shows the separation of the network prefix and the host identifier from an address (192.168.5.130) and its associated /24 network mask (255.255.255.0). The operation is visualized in a table using binary address formats.
Binary formDot-decimal notation
IP address11000000.10101000.00000101.10000010192.168.5.130
Subnet mask11111111.11111111.11111111.00000000255.255.255.0
Network prefix11000000.10101000.00000101.00000000192.168.5.0
Host part00000000.00000000.00000000.100000100.0.0.130
The mathematical operation for calculating the network prefix is the bitwise AND of IP address and subnet mask. The result of the operation yields the network prefix 192.168.5.0 and the host number 130.

Subnetting

Subnetting is the process of designating some high-order bits from the host part and grouping them with the network mask to form the subnet mask. This divides a network into smaller subnets. The following diagram modifies the example by moving 2 bits from the host part to the subnet mask to form four smaller subnets one quarter the previous size:
Binary formDot-decimal notation
IP address11000000.10101000.00000101.10000010192.168.5.130
Subnet mask11111111.11111111.11111111.11000000255.255.255.192
Network prefix11000000.10101000.00000101.10000000192.168.5.128
Host part00000000.00000000.00000000.000000100.0.0.2

Prefix sizeNetwork maskAvailable
subnets
Usable hosts
per subnet
Total
usable hosts
/24255.255.255.01254254
/25255.255.255.1282126252
/26255.255.255.192462248
/27255.255.255.224830240
/28255.255.255.2401614224
/29255.255.255.248326192
/30255.255.255.252642128
/31255.255.255.254128*256

Popular Posts