About Jon Marshall

Jon Marshall · ‎09-19-2018

Ok that makes sense. Can you post the switch configs so we can see exactly what is setup. Bear in mind with hardware switches that you do not always see hits on the acls so it is not always the best way to verify PBR. Jon

Jon Marshall · ‎09-19-2018

I have just looked at your diagram again and it makes no sense. You have the 192.168.1.0/24 subnet on both sides of a L3 interconnect in vlan 405 which means if you do send the traffic from a PC to the firewall it has a locally connected interface in the 192.168.1.0/24 subnet so it will never route it back to your switch because you don't route within the same IP subnet. Or is that link between the switch and firewall a trunk link ? Jon

Jon Marshall · ‎09-18-2018

Just to clarify so as not to confuse the OP. The destination mac is not the egress interface of the router, that is the source mac. The destination mac is either the next hop device or the destination device. Jon

Jon Marshall · ‎09-18-2018

Paul’s acl suggestion is correct but the masks are wrong. It should be - access-list 115 permit ip 10.10.150 0.0.0.255 192.168.30.0 0.0.0.255 Jon

Jon Marshall · ‎09-18-2018

Those type of routes were not implemented in your IOS version. So there is another reason why it is not working. Jon

Jon Marshall · ‎09-18-2018

IP SLA is the common way to track static routes. Or use a dynamic routing between the devices and then no need for configuring tracking. Jon

Jon Marshall · ‎09-14-2018

Etherchannel uses an algorithm to work out which link to use so if you use src mac only then it is just that address that is used with the algorithm to work out which link to use, whereas src-dst mac would use both addresses as input to the algorithm etc. That is all you are doing, providing variable input to an algorithm to try and spread the traffic as evenly as possible across multiple links. Etherchannel load balancing is not precise so there is no guarantee of an exact split between the links and if even if there were load balancing is done per connection (flow) with no account taken of the amount of traffic in that flow. If you only want to allow internal employees to use one of the links the question really is why use etherchannel ? Not sure I understand the firewall question. Bear in mind etherchannel is as much about redundancy as throughput so it is not always about just increasing bandwidth. Jon

Jon Marshall · ‎09-14-2018

On the 4948 make the etherchannel a L2 trunk and use SVIs, that should work fine. The point Harold made still stands though, it is unclear how the non VRF OSPF is working as you are not running OSPF on the port channel interfaces. Jon

Jon Marshall · ‎09-14-2018

The packet arrives on a interface that is not part of a VRF so the global routing table will be used to forward the packet. Jon

Jon Marshall · ‎09-13-2018

Each vlan would need it's own L3 interface which is either on the firewall or somewhere else but if you want to filter between vlans within a VRF why put them in the same VRF ? Jon

Jon Marshall · ‎09-13-2018

Don't know why you cannot apply an acl outbound but you can apply the acl inbound on your LAN interface. Don't forget "permit ip any any" in your acl for all the other traffic. Jon

Jon Marshall · ‎09-13-2018

If the switches are L3 capable, which they are, you could just not use port channels, move the L3 interfaces for the vlans to the switches and then just connect using L3 links so each stack has a L3 link to each router. Then use static routes or routing protocol between the switches and the routers. That said you may be trying to over engineer this as you already have redundancy in your solution. The chances of router 1/carrier 1 failing at the same time as the entire switch stack 2 is minimal and as long as the ports for po10 are spread across physical switches in the stack again that is what etherchannel is really for ie. redundancy. There comes a point where it is the law of diminishing returns in terms of trying to account for every single failure scenario. Jon

Jon Marshall · ‎09-12-2018

If you are pinging the switch itself then those packets are not hardware switched so if the switch is busy they will be treated with low priority. If you are not seeing performance issues for data through the switch I wouldn’t worry too much. Jon

Jon Marshall · ‎09-06-2018

Just for your info you may want to look at Netmiko (written by the same guy) which uses Paramiko but takes out some of the lower level stuff for managing network devices. So your code in Netmiko would be - from netmiko import ConnectHandler swp = ConnectHandler(device_type='cisco_ios', ip=IP, username=USER, password=PASS, secret=ENABLE) swp.enable() output = swp.send_command('sh run') print output Jon

Jon Marshall · ‎09-03-2018

By default vlan 1 is untagged. If you use the "switchport trunk native vlan 100" command then vlan 1 now becomes tagged and vlan 100 is untagged. The point of the native vlan was primarily to support connections to network devices that did not understand tagging but there are not many of them around in your average network these days. Jon

Date Registered	‎09-22-2003 11:19 PM
Date Last Visited	‎09-24-2018 05:53 AM
Total Messages Posted	25,193
Total Helpful Votes Received	17303

Re: 4500X PBR problem on SVIs

Re: 4500X PBR problem on SVIs

Re: Did the switch receives Packets or ...

Re: 4500X PBR problem on SVIs

Re: no L codes in routing table.

Re: Auto fail over each router with tra...

Re: etherchannel load balancing - quest...

Re: Mixed vrf and non-vrf OSPF processe...

Re: Route prefference

Re: VRF and ACL

Re: ACL on WAN interface

Re: Stack redundancy using 2 routers, H...

Re: HIGH ICMP PING RESPONSE TIME

Re: Powershell Script to backup 2960 St...

Re: i need help understanding native vl...