About paul driver

paul driver · ‎04-17-2019

Hello I agree your config does look correct - Can you post the output of those commands. show frame-relay pvc show frame-relay map show frame-relay lmi show interface serial x/x One thing you could try is to default the serial interfaces and then shut them down, recreate FR on the interface which are still in a shutdown state, Disable inverse arp before you enable the interface again, then test. The reason for this sometimes i have noticed on broadcast FR mappings if the interface is up before you disable inverse arp it can already have mapped a dlci.

paul driver · ‎04-17-2019

Hello i have edited previous example please review it

paul driver · ‎04-17-2019

Hello @Georg Pauwen Looks your acl 102 relating to map 20 will deny all traffic on that vlan it needs to be more specific( host-host) lastly no need specifying action forward in the catch all map 30 as the default action is to forward anyway

paul driver · ‎04-17-2019

Hello @marce1000 not so sure i understand why would you require FW rules - this will only be L2 traffic not L3 , its only negating access between hosts WITHIN the same broadcast domain

paul driver · ‎04-17-2019

Hello @charliegray wrote: Does C9000 support Link state tracking? I dont think it does , Object tracking (line-protocol, ipsla, route etc..) as @Reza Sharifi pointed out would be applicable

paul driver · ‎04-17-2019

Hello Vlan access map would be applicable here: Example: access-list 101 permit tcp host 192.168.0.9 host 192.168.0.5 eq 443 access-list 101 permit tcp host 192.168.0.5 host 192.168.0.9 eq 443 access-list 102 permit ip host 192.168.1.5 host 192.168.1.9 access-list 102 permit ip host 192.168.1.9 host 192.168.1.5 vlan acess-map srv2srv 10 match ip address 101 action forward vlan access-map srv2srv 20 match ip address 102 action drop vlan access-map srv2srv 99 vlan filter srv2srv vlan-list 10

paul driver · ‎04-17-2019

Hello May i ask is this for resiliency, meaning do you wish to automatically fail-over from this interface to another active interface when line-protocol failure occurs? If you so you could have some options depending on your setup to be able to monitor a line protocol failure.: Object tracking (can be based on line-protocol,route, ipsla monitoring) Link state tracking ( used for mostly used for server interface resiliency) Flexlink - L2 failover ( no need to have stp active between two uplinks) EEM scripting ( uses a marco script to automatically admin down the port in question) If you can elaborate on your requirements it is possible one of the above could be applicable for you.

paul driver · ‎04-16-2019

Hello Without using any default routes working from left to right - try the following - It should be okay however my dyslexia doesn't help when trying to do anything like this as i need to triple check most times, so apologies in advanced if there is any typos but from the below you should see how i have complied the statics and work from it? R4 ip route 20.0.0.0 255.0.0.0 10.0.0.1 ip route 192.168.0.244 255.255.255.252 10.0.0.1 ip route 192.168.0.248 255.255.255.252 10.0.0.1 ip route 192.168.0.252 255.255.255.252 10.0.0.1 R0 ip route 20.0.0.0 255.0.0.0 192.168.0.254 ip route 192.168.0.244 255.255.255.252 192.168.0.254 ip route 192.168.0.248 255.255.255.252 192.168.0.254 ip route 172.16.0.0 255.255.255.0 10.0.0.2 R1 ip route 20.0.0.0 255.0.0.0 192.168.0.250 ip route 192.168.0.244 255.255.255.252 192.168.0.250 ip route 10.0.0.0 255.0.0.0 192.168.0.253 ip route 172.16.0.0 255.255.255.0 192.168.0.253 R2 ip route 20.0.0.0 255.0.0.0 192.168.0.246 ip route 192.168.0.252 255.255.255.252 192.168.0.249 ip route 10.0.0.0 255.0.0.0 192.168.0.249 ip route 172.16.0.0 255.255.255.0 192.168.0.249 R3 ip route 192.168.0.248 255.255.255.252 192.168.0.245 ip route 192.168.0.252 255.255.255.252 192.168.0.245 ip route 10.0.0.0 255.0.0.0 192.168.0.245 ip route 172.16.0.0 255.255.255.0 192.168.0.245

paul driver · ‎04-16-2019

Hello looking at the config you post i see native vlan 99 is configured between the two switches, may i ask is this vlan is actually created in the vlan database along woth the other vlans 64.65, if it isn't please make sure it is? on both switches conf t vlan 64-65,99 exit

paul driver · ‎04-16-2019

Hello Can you post the running configuration of the Huawei and cisco together please or at least their interface config connecting them together? Does the Huawei have mgt address applied to it? Cisco- sh int trunk sh vlan brief sh ip int brief

paul driver · ‎04-16-2019

Hello Yes if you pass a valid cisco exam(CCNA/Professional/Expert) all your other cisco exams you have already passed and have not yet expired will be extended

paul driver · ‎04-16-2019

Hello @NPO-IT wrote: Thanks Paul. Is SW1 considered a core switch because SW2 is downstream of it (in relation to the router)? Right now, IP routing isn’t enabled on either switch. If I enable it on SW1, should the gateway address I set on SW2 be the address of the router or of SW1? If sw1 is going to be performing the routing for the vlans and is considered as the core sw then yes enable ip routing and give sw2 a D/G of the sw1 mgt svi addresses

paul driver · ‎04-16-2019

Hello You seem to be using the old format of URPF. ip verify unicast reverse-path <--old format ip verify unicast source reachable-via XX < new format Now to allow packets to be forwarded only if the local router has a valid source address of the incoming packet in its route table you can permit this two ways. 1) ip verify unicast source reachable-via any 2) access-list 1 permit any ip verify unicast source reachable-via rx 1

paul driver · ‎04-16-2019

Hello PBR does seem a logical proposal however as you have dynamic routing then conditional path manipulation via this could also be a viable alternative. Can you elaborate on what routes are being advertised between eigrp and bgp regards these three sites ( mutual redistribution, default routes etc...)

paul driver · ‎04-16-2019

Hello Looks like the reason why stp calculated best path to root bridge for sw 3 via that direct path to sw1 was sw1 was already designated root bridge, So the next order of preference in stp calculation would be root path cost (RPC) as sw3 now has a direct link to sw1 this was chosen a designated/root with sw2/4 having their own lower rpc link to the root bridge. Sw3 two links to either switch 2-4 were put into alternate state seems to suggest both of those switches (sw2 having a lower bid, sw4 having a higher bid of sw3).

paul driver · 01-16-2019 09:07 AM

Congratulations Peter Very well deserved indeed.

Date Registered	‎06-12-2007 12:44 AM
Date Last Visited	‎04-18-2019 09:01 AM
Total Messages Posted	5,958
Total Helpful Votes Received	4802

Re: Frame Relay not pinging

Re: block access in same vlan

Re: block access in same vlan

Re: block access in same vlan

Re: Link sTate Tracking - C9300

Re: block access in same vlan

Re: Automatic laser shut on Router/Swit...

Re: Static routing with 5 routers

Re: Can't ping from one 2960X to anothe...

Re: WRP400 and Switch DHCP pool trouble...

Re: MY CCNP router and Trouble shooting...

Re: Can't ping from one 2960X to anothe...

Re: ACL Logging with IP Verify Unicast ...

Re: Policy based routing and preferred ...

Re: Confusion about RSTP convergence

Re: Congratulations Peter Paluch: Our Newest Hall of Fame Member